Re: [Talk-ko] Talk-ko Digest, Vol 29, Issue 1
In case of Korean, Droid Sans font is easy to read than Unifont. Droid sans is more simple and make clarify the distinction between line and line. I really thank you for your help. 2014/1/12 talk-ko-requ...@openstreetmap.org Send Talk-ko mailing list submissions to talk-ko@openstreetmap.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.openstreetmap.org/listinfo/talk-ko or, via email, send a message with subject or body 'help' to talk-ko-requ...@openstreetmap.org You can reach the person managing the list at talk-ko-ow...@openstreetmap.org When replying, please edit your Subject line so it is more specific than Re: Contents of Talk-ko digest... Today's Topics: 1. CJK fallback fonts - testing needed (Paul Norman) 2. Re: CJK fallback fonts - testing needed (Robert Helvie) -- 전달된 메시지 -- From: Paul Norman penor...@mac.com To: t...@openstreetmap.org, talk...@openstreetmap.org, talk-ko@openstreetmap.org Cc: Date: Sat, 11 Jan 2014 21:19:10 -0800 Subject: [Talk-ko] CJK fallback fonts - testing needed Right now the main OpenStreetMap.org stylesheet uses Unifont as a fallback font to render Chinese, Japanese and Korean (CJK) characters, as well as any other characters not present in the DejaVu font. Unifont is mainly designed to support all characters, and is not designed to look good. I'm looking at Droid Sans Fallback, a free font developed for Android, and evaluating if it would be a better fallback font than Unifont. Because I don't read Chinese, Japanese or Korean, I could use help. I have prepared a demo at http://tile.paulnorman.ca/demo/fonts.html with three layers: conventional OSM.org, tiles without any fallback font, and tiles using Droid Fallback as a fallback font. What I would like is for people to look at the difference between the conventional OSM.org and Droid Fallback tiles and see which is easier to read for the CJK glyphs. The tiles without any fallback font can be used to find areas where DejaVu doesn't have glyphs and the fallback font is being used. Some examples Japanese cities: http://tile.paulnorman.ca/demo/fonts.html#9/35.443/138.247 Japanese train stations: http://tile.paulnorman.ca/demo/fonts.html#16/36.415/139.325 Korean cities: http://tile.paulnorman.ca/demo/fonts.html#9/37.25/127.22 Chinese tourist attraction: http://tile.paulnorman.ca/demo/fonts.html#15/39.94/116.48 Please keep in mind that - My server is not nearly as powerful as tile.osm.org, so renders slower and has less cached data - Only Asia is loaded on my server - The data is a couple of days old and isn't being updated I would like some feedback on if Unifont or Droid Sans Fallback looks better. Please keep in mind that I don't read the languages being rendered. -- 전달된 메시지 -- From: Robert Helvie alim...@gmail.com To: Paul Norman penor...@mac.com, Talk-ko@openstreetmap.org Cc: Date: Sun, 12 Jan 2014 18:54:49 +0900 Subject: Re: [Talk-ko] CJK fallback fonts - testing needed IMO the Droid font looks better for Hangul (Korea). It is only a slight improvement in that the text is slightly darker than the respective text of Unifont, but it does make things easier to read. And at the smallest size, the Hangul is definitely more readable. Hangul is more open (empty space) than the Chinese, though so I am not sure if that darker value will make Chinese harder to read. Personally I think the Korean (Hangul) text is a bit small and could maybe go up a point, but again, just my opinion. Thanks for looking out for us folks. *We should give meaning to life, not wait for life to give us meaning. * ~ unknown --- On Sun, Jan 12, 2014 at 2:19 PM, Paul Norman penor...@mac.com wrote: Right now the main OpenStreetMap.org stylesheet uses Unifont as a fallback font to render Chinese, Japanese and Korean (CJK) characters, as well as any other characters not present in the DejaVu font. Unifont is mainly designed to support all characters, and is not designed to look good. I'm looking at Droid Sans Fallback, a free font developed for Android, and evaluating if it would be a better fallback font than Unifont. Because I don't read Chinese, Japanese or Korean, I could use help. I have prepared a demo at http://tile.paulnorman.ca/demo/fonts.html with three layers: conventional OSM.org, tiles without any fallback font, and tiles using Droid Fallback as a fallback font. What I would like is for people to look at the difference between the conventional OSM.org and Droid Fallback tiles and see which is easier to read for the CJK glyphs. The tiles without any fallback font can be used to find areas where DejaVu doesn't have glyphs and the fallback font is being used. Some examples Japanese cities: http://tile.paulnorman.ca/demo/fonts.html#9/35.443/138.247 Japanese train stations:
Re: [OSM-legal-talk] Attribution Requirements
On 10/01/14 12:01, Simon Poole wrote: Am 10.01.2014 07:15, schrieb Clifford Snow: I like the Mapbox solution the author mentions of putting a box on the map to take you to another page. I realize that unless the user clicks on the link, they will never discover that OSM contributed to this product. Since OSM may be only one of many contributors this make sense considering that there is only so much screen real estate available. Clifford, to make this very short: this is NOT acceptable. See the last board minutes. The last board minutes say we expect people to follow what is in our Legal FAQ and states that the board will complain if attribution is not given. The FAQ says the credit should typically appear in the corner. And I'm very tired of people trying to weasel around the absolute minimal requirements we pose on reuse of OSM data. It seems a bit strong to say that MapBox are weasels given that the OSM attribution is given equal prominence with their own Terms and their imagery attribution. (By the way, Alex and Eric from MapBox are members of this mailing list.) Surely should be given equal prominence with the map copyright holder's own attribution would be a better principle than put it in the corner. Personally I agree with Clifford - I like MapBox's approach and agree that it would seem appropriate for a map with a longer list of attributions. What would happen if every data source started mandating that our attribution must be in the corner? Jonathan. -- Dr Jonathan Harley :Managing Director: SpiffyMap Ltd m...@spiffymap.com Phone: 0845 313 8457 www.spiffymap.com The Venture Centre, Sir William Lyons Road, Coventry CV4 7EZ, UK ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Attribution Requirements
Jonathan, On 13.01.2014 13:17, Jonathan Harley wrote: What would happen if every data source started mandating that our attribution must be in the corner? The thing is that for us, for OpenStreetMap, the attribution is our main remuneration. We give our data away for free but in return, we expect to get at least a little bit of exposure, a little help in building our brand to borrow some marketing speak. Much has been said about how happy we should be if people use our data, because in the end it's all good for us becasue it increases our mindshare and therefor our contributor numbers etc.; this reasoning falls over if we allow users to bury us as an also-ran in a list of building blocks for their map. This would be different if we were a paid-for data source, in which case our major remuneration would be the money people pay us for our data - in that case, we could afford to be less demanding with regards to the attribution. But we aren't, and don't want to be. If OSM plays an important part in your map, then credit us properly. There are many maps out there which would be useless if you took away the OSM part, and nonetheless they are adorned (on-map) with the names of those who made the tiles and those who bought them for embedding in their web site, with OSM being relegated to one click away - in order not to dilute the brand building of those who rely on our data to make a map in the first place. I don't think that's acceptable. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
[OSM-legal-talk] Corine Land Cover?
Dear all, The Wiki currently states that import of Corine Land Cover data into OSM is ok: http://wiki.openstreetmap.org/wiki/Corine_Land_Cover The source says Unless otherwise indicated, re-use of content on the EEA website for commercial or non-commercial purposes is permitted free of charge, provided that the source is acknowledged. Doesn't the last part (acknowledment) make the data incompatible with OSM? Users of Produced Works from OSM do not acknowledge EEA. Thank you for your opinions, pmsg ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Corine Land Cover?
2014/1/13 pmsg pmsg2...@yahoo.com Thank you for your opinions, pmsg legal issues aside my concern is that Corine Data is not suitable technically for OSM: the resolution is too low and not compatible with the rest of our data. cheers, Martin ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Attribution Requirements
On 13.01.2014 18:06, Frederik Ramm wrote: Jonathan, On 13.01.2014 13:17, Jonathan Harley wrote: What would happen if every data source started mandating that our attribution must be in the corner? The thing is that for us, for OpenStreetMap, the attribution is our main remuneration. We give our data away for free but in return, we expect to get at least a little bit of exposure, a little help in building our brand to borrow some marketing speak. Our own legal FAQ published at http://wiki.osmfoundation.org/wiki/License says: In other words, you should expect to credit OpenStreetMap in the same way and with the same prominence as would be expected by any other map supplier. I'm reading it as it's fine to put OSM credits on a credits page if all credits are there. As long as other map suppliers like Google and Bing are happy by being only credited on a separate page, we're happy as well to be on the same page. What's not OK would be showing the Google credits in the corner and hide OSM somewhere behind a link. If this is not what this paragraph intended to state, please write it in a way which is easier to understand by non native speakers. As there is a similar looking page in out wiki which is linked from the very prominently placed copyright link on the main page it might be a good idea to revise that page or replace it completely by the (at least I assume) more authoritative page of the OSMF. http://wiki.openstreetmap.org/wiki/Legal_FAQ I have placed a warning on that page and refer to the OSMF. Stephan ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Attribution Requirements
Hi, On 13.01.2014 22:52, Stephan Knauss wrote: As long as other map suppliers like Google and Bing are happy by being only credited on a separate page, Are they? Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Attribution Requirements
On 13.01.2014 23:41, Frederik Ramm wrote: On 13.01.2014 22:52, Stephan Knauss wrote: As long as other map suppliers like Google and Bing are happy by being only credited on a separate page, Are they? No idea. Do their terms allow to use the tiles directly without using their own JS-API which enforces the attribution in the corner? BTW: Someone mentioned Mapbox: Mapbox does not display attribution but Terms Feedback. At least if you follow their introduction on how to show a simple map. No word about attribution. https://www.mapbox.com/mapbox.js/example/v1.0.0/ a click leads to a copyright page mentioning OSM, no link to us but to ODbL. https://www.mapbox.com/about/maps/ Showcase of Mapbox shows some of their customers. Foursquare: No attribution. A click away they mention OSM but not ODbL Pinterest: can't say without sign up, but based on screenshot attribution is About this map Hipmunk: no attribution. Clearly uses OSM data So having a correct attribution seems to be a quite hard task, even for a company so closely related to OSM as mapbox is. Probably they also did not read the legal page which recommends: If you are producing library code that offers OpenStreetMap data or tiles, you should make sure library users are aware of these terms. We strongly recommend that you display this credit by default when your library is used. ;) Stephan ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-talk] Proposed automated edit: remove railway=* or highway=* tag on relations tagged type=route
Actual numbers would be about 1830 highway=* and about 490 railway=* objects with type=route if you count only relations: http://overpass-turbo.eu/s/22q Martin Taginfo finds type=route combined with 1374 instances of railway=* (0.48%) and 6426 instances of highway=* (2.23%). ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposed automated edit: remove railway=* or highway=* tag on relations tagged type=route
2014/1/13 Guillaume Rischard openstreet...@stereo.lu Hello, Several relations have both type=route and highway=* or railway=* tags; I would like to remove the highway or railway tags from the relations, and leave them on the members. The relation highway tags are redundant with the member ways, make no semantic sense, and can cause rendering issues: - Redundancy: A route typically contains highways or railways that each have a highway=* or railway=* tag. Because the information is already included in the members of the relation, it is redundant to tag the relation with that tag as well — you're tagging in two places when you only need one. - Semantic meaning: These relations are not highways or railways, they are a *group* of them that make up a route. The tag belongs on the members, not on the relation. It causes semantic problems when the value of the tag differs on the relation and on the member: is the street a motorway like the relation's highway tag says, or residential like the way's tag says? tags on relations can be seen as default values for the relation members, so in such a case, the default tag is replaced by the member one. I'm not saying it's right to do it that way, just a way to deal with data in such cases. - Rendering: if both a way and its relation are tagged as highway=* or railway=*, the line will get drawn twice on the map — once for the way, and once on top of that for the line formed by all the ways in the relation. While this is invisible in most cases, it will cause unexpected results if the tags disagree, e.g. a trunk that's part of a highway=motorway relation, or a railway tunnel that's part of a railway=rail relation. This can also be managed at rendering level in several ways: - do not render route=* (that's the option I choose) - render route=* first in case there is one (may not render right in your motorway/residential example, but fine with the railway tunnel) I think it's better to deal with such cases at data consumption level as the case may show up again and again in the future. If this kind of tagging is indeed considered wrong, no problem to fix the data with a mechanical edit but we should at least agree on what's right/wrong first. -- Christian Quest - OpenStreetMap France ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Level of detail, Zoom 19. Has it decreased?
Has the detail level of the default mapnik stylesheet (zoom 19) changed recently? Increasingly I've found that when using the map I can't get the level of detail I want when zoomed to level 19 (I end up firing up josm, or turning on Map Data when all I really wanted was view a map). Here's an example area: http://www.openstreetmap.org/#map=19/37.88117/-122.27424 Where there are at least two stores not shown at maximum zoom, despite what seems like plenty of space. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Level of detail, Zoom 19. Has it decreased?
There's nothing that I see that would be rendered given more space - shop=toys and shop=beauty have never been rendered by osm.xml or openstreetmap-carto. See https://github.com/gravitystorm/openstreetmap-carto/issues/116 for the current discussion about this. From: Bryce Nesbitt [mailto:bry...@obviously.com] Sent: Monday, January 13, 2014 10:43 AM To: talk@openstreetmap.org Subject: [OSM-talk] Level of detail, Zoom 19. Has it decreased? Has the detail level of the default mapnik stylesheet (zoom 19) changed recently? Increasingly I've found that when using the map I can't get the level of detail I want when zoomed to level 19 (I end up firing up josm, or turning on Map Data when all I really wanted was view a map). Here's an example area: http://www.openstreetmap.org/#map=19/37.88117/-122.27424 Where there are at least two stores not shown at maximum zoom, despite what seems like plenty of space. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk-nl] StateOfTheMap-eu in Karlsruhe: in het Engels én Call for Presentations
hallo Mappers, Voor diegenenen die na de geslaagde OSGeoNL+OSM Nieuwjaarsborrel enthousiast zijn geworden voor de State-Of-The-Map die op 13-15 juni in Karlsruhe (4,5 uur treinen vanaf Utrecht Centraal) wordt gehouden, maar op school niet zo goed hebben opgelet bij de Schwere Wörter: ik lees op http://sotm-eu.org/en dat the conference language is English. (grappig: de Duitstalige pagina rept over Die Konferenzsprache ist hauptsächlich Englisch, de Franstalige pagina zegt niets over een voertaal) De call for presentations staat tot 28 feb. open. Misschien iets voor de BAG-importers? (met wellicht een paar weken later op de OSGeonl dag een reprise...) groet, Gert-Jan ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
[Talk-br] desincreissão
Gentileza retirar o meu email deste circulo. Grato. Cardoso Veras ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
[Talk-de] OSM-Straßenlistenauswertung: landesweite Updates zentrale Listen Baden-Württemberg und Thüringen
Hallo, in der OSM-Straßenlistenauswertung [1] habe ich gestern zwei große Datenaktualisierungen vorgenommen und seit heute früh stehen für diese auch neue Auswertungen bereit. Für die Bundesländer Baden-Württemberg und Thüringen stehen zentale Straßenlistendateien zur Auswertung zur Verfügung. Diese habe ich gestern im Straßenlisten-Wiki [2] aktualisiert, wenn die vorherigen Listen nicht zwischenzeitlich durch Wiki-User verändert wurden. Die Listen für Baden-Württemberg sind zum Teil noch von schlechter Qualität, daher bitte die Auswertung für Eure Gemeinden prüfen und ggfs. im Wiki die vorherige reaktivieren, wenn diese offensichtlich besser die Straßen in der jeweiligen Gemeinde abbilden. Für die Bundesländer Mecklenburg-Vorpommern und Rheinland-Pfalz stehen auch zentrale Listen zur Verfügung. Diese werde ich in den nächsten Tagen im Wiki aktualisieren. Zu den beiden Datenupdates hier noch Details: Baden-Württemberg Die Liste wird vom Landesamt für Geoinformation und Landentwicklung LGL [3] bereitgestellt, in diesem Fall ist der Datenstand 2.1.2014. * 1017 Straßenlisten wurden aktualisiert. Darin gab es in 417 Straßenlisten inhaltlich Änderungen, 700 Listen sind also inhaltlich unverändert. Trotzdem wurden auch die 700 aktualisiert, damit der Stand der Listen erkennbar ist. Davon habe ich 9 Listen im nachhinein zurückgesetzt, weil die Listen offenbar qualitativ schlechter waren als die vorhandenen. Dazu habe ich bei den neuen Auswertungen die Listen mit den größten Verlusten [4], nämlich mind. 10 Straßen weniger als vorher, händisch überprüft. * 71 Straßenlisten wurden nicht aktualisiert, weil sie von einem Wiki-User zwischenzeitlich geändert worden waren. Für diese stelle ich in den nächsten Tagen weitere Infos bereit, damit Interessierte den aktuellen Stand im Wiki mit der neuen offiziellen Version abgleichen können * von 19 Gemeinden gab es keine zentale Listen. Thüringen == Die Liste wird vom Landesamt für Vermessung und Geoinformation [5] bereitgestellt, der Datenstand ist 14.10.2013. * 836 Straßenlisten wurden aktualisiert. Darin gab es in 257 Listen inhaltiche Änderungen, 579 Listen waren also unverändert. Alle wurden aktualisiert. * 42 Straßenlisten wurden nicht aktualisiert wg. Änderungen durch Wiki-User. Zum Abgleich durch Interessierte stelle ich weitere Daten in einigen Tagen zur Verfügung. * Die zentrale Liste umfasste alle Gemeinden des Landes. viele Grüße Dietmar aka okilimu [1] http://regio-osm.de/listofstreets/ [2] http://regio-osm.de/listofstreets/wiki/index.php/Hauptseite [3] https://www.lgl-bw.de/lgl-internet/opencms/de/07_Produkte_und_Dienstleistungen/Open_Data_Initiative/index.html [4] http://regio-osm.de:/listofstreets/ticker?eval_old=12.01.2014eval_new=13.01.2014area=*Baden-W%C3%BCrttemberg* [5] http://www.geoportal-th.de/de-de/downloadbereiche/downloadkataloge.aspx ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Grundriss vs Dachfläche
On Sat, Jan 11, 2014 at 08:33:06PM +0100, Norbert Kück wrote: Blindes Übernehmen von Daten lehne ich ab - auch bei ALK. Wenn ich Unstimmigkeiten sehe sage ich nicht alles Sch..., sondern spreche die Quelle an. Das geht hier gut, weil es um Einzelobjekte geht und nicht um flächendeckendes Abmalen. ALK und Luftbilder haben einen gravierenden Unterschied: Vermessungsdaten sind hinreichend genau und richtig, wenn nach dem Stand der Technik gearbeitet wird. Nope - Sorry - Ich habe vor 3 jahren ein altes Haus gekauft. Das war komplett anders im ALK drin. Nach der Einmessung sind jetzt auch (genehmigte) Gebaeudeteile aus den 70er und 90er Jahren mal eingetragen worden, die fehlten bis dahin komplett. Luftbilder haben systematische Nachteile, die durch die Nachbearbeitung nicht oder nur unvollkommen ausgeglichen werden können. Siehe oben. Ich bin ja eher im Aussenbereich unterwegs und da wird so viel um und aus und drangebaut und teilweise auch mal gerne ohne Baugenehmigung oder Bauabnahme - Da steht dann nach 100 Jahren ein komplett andere Bausubstanz. ALK uebernehmen wäre dort einfach nur Müll importieren. Flo -- Florian Lohoff f...@zz.de signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Grundriss vs Dachfläche
Kurz vorweg: Sorry für mögliche doppelte Antwort. Am 12.01.2014 20:29, schrieb Martin Koppenhoefer: ja, da stand ja auch zum Beispiel, mit dem building-key sollte man (m.E.) ausser der Überdachung nichts taggen, sondern ggf. die Dachfläche (bzw. das Dach mit Neigung und Überständen etc.) im 3D-Mapping, und definiert als Teil des Gebäudes (über den key). Grundriss bezeichnet normalerweise den Plan einer Etage und hat hier m.E. nichts in der Diskussion zu suchen. Sorry für die Frage. Ich sehe gerade, dass das im deutschen Wiki auch teilweise beantwortet ist. http://wiki.openstreetmap.org/wiki/DE:Buildings#Umriss Trotzdem bleiben meinerseits Fragen offen: So wie ich das nun verstehe gibt es da in OSM eine Coexistenz zweier Umrisserfassungsmöglichkeiten. Einmal die Erfassung der Außenwand am Boden und dann die Grundrisslinie. Ich würde es für sinnvoll halten zu Gebäuden nach Möglichkeit beide Flächen in der OSM zu haben. Der einfachste Weg wäre wahrscheinlich eine neue Rolle in der building-Relation. Aber welche soll schließlich den Building-Tag tragen? Ich finde, dass das wiki dazu eine Aussage treffen sollte. Zum 3D-Mapping: Es gibt dort derzeit die Rolle outline. Allerdings weiß ich nun nicht, ob damit nicht vielleicht die Gebäudewand am Boden gemeint ist. Beispiele: Die Portale des Bremer Doms schneiden zum Beispiel in den Grundriss, den das LfD bereitstellt, eine Aussparung, die nur am Boden existiert. Das heißt über dieser Fläche, die dort ausgespart ist befindet sich zum Beispiel Mauer oder übrige Gebäudeteile wie teilweise die Türme. Hier die Aussparung, die bei der Erfassung der Mauer am Boden nicht zum Umriss gehören würde. http://www.openstreetmap.org/way/211749964 Hier ein Link zu der Karte beim LfD. http://194.95.254.61/cgi-denk/getdoc.pl?DEF=/home/schwartz/daten/bremenDATEN=/home/schwartz/daten/datenTHE=/home/schwartz/daten/idxDOK_TPL=lfd_bremen_doc2.tplKEY=obj%200314 Es gibt auch Beispiele bei denen nahezu das gesamte Gebäude verschwindet, wenn man die Mauer am Boden als Gebäudeweg erfasst: http://194.95.254.61/denkmalpflege/jpg1/1009a05.jpg Hier der Link zur Seite beim LfD. http://194.95.254.61/cgi-denk/getdoc.pl?DEF=/home/schwartz/daten/bremenDATEN=/home/schwartz/daten/datenTHE=/home/schwartz/daten/idxDOK_TPL=lfd_bremen_doc2.tplKEY=obj%201009 Die freistehenden Gebäudeteile wie Dächer etc sind hier mit einem X durchgestrichen. BTW: Wer sich die Bilder ansieht, wird vielleicht bemerken, dass das so nicht ganz richtig sein kann - abgesehen davon ein valides Beispiel für mein Problem. So wie ich nun die Grundrisslinie verstanden habe, ist in OSM alles soweit nach Grundrisslinie getagt. Nun wäre es aber auch sinnvoll das Gebäude nach Mauer am Boden zu taggen und mappen. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Grundriss vs Dachfläche
Am 13.01.2014 11:43, schrieb cracklinrain: Zum 3D-Mapping: Es gibt dort derzeit die Rolle outline. Allerdings weiß ich nun nicht, ob damit nicht vielleicht die Gebäudewand am Boden gemeint ist. Unser Simple-3D-Modell ist mit dem Konzept building=Grundfläche leider nicht ganz kompatibel. Ich weiß nicht ob die 3D Renderer in letzter Zeit toleranter geworden sind, aber bei einem Turm mit Kopf muss die Umrisslinie des Kopfes als building eingetragen werden (also die breiteste Stelle), und nicht die Aufstandsfläche des Turmfußes. Chris ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Grundriss vs Dachfläche
Ich weiß nicht ob die 3D Renderer in letzter Zeit toleranter geworden sind, aber bei einem Turm mit Kopf muss die Umrisslinie des Kopfes als building eingetragen werden (also die breiteste Stelle), und nicht die Aufstandsfläche des Turmfußes. Auslegungssache. Ich würde sagen, dann muss weiterhin die Aufstandsfläche gemappt werden und ggfs. ein falsches Renderergebnis in Kauf genommen werden, bis der Renderer das vernünftig unterstützt. Oder mit welcher Begründung ist hier ein einzelner Spezialrenderer plötzlich ausschlaggebend für die Auslegung bestehender Taggingpraxis? Gruss, Chaos ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Fwd: [talk-ch] [OKFN-CH] First Meeting of the OpenGLAM CH Working Group
Weitergeleitet von talk-ch Original-Nachricht Dear * Stumbled upon this email once again. Might be interesting for OSM as well. - Keywords: KGS-Nummer (Kulturgüterschutz Nummer, Schweiz. PCP reference number in wikidata) wikidata, wikipedia https://lists.okfn.org/pipermail/okfn-ch/2013-December/15.html But maybe it's to late to participate, no idea. cheeers, hugi PS To give you some feeling: Schweizerische Nationalbibliothek - www.openstreetmap.org/way/40859920 Swiss National Library - https://www.wikidata.org/wiki/Q201787 Klick and look for buildings: http://de.wikipedia.org/wiki/Liste_der_Kulturg%C3%BCter_in_Bern -- Andreas Bürki abue...@anidor.com S/MIME certificate - SHA1 fingerprint: ED:A5:F3:60:70:8B:4C:16:44:18:96:AE:67:B9:CA:77:AE:DA:83:11 GnuPG - GPG fingerprint: 5DA7 5F48 25BD D2D7 E488 05DF 5A99 A321 7E42 0227 ___ talk-ch mailing list talk...@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Erinnerung OSM-Hackweekend Berlin
Hallo, am 25./26.01. findet in Berlin wieder ein OSM-Hackweekend statt. Details (Ort, Zeit, ...) findet ihr im OSM-Wiki [1]. Dort sieht man auch wer sich bereits angemeldet hat und woran gearbeitet werden soll. Es ist auch noch Platz in der Liste. Am Vorabend (Freitag, 24.01) wird es ein Kennenlerntreffen geben. Das Lokal wird auf der Wikiseite ergänzt, sobald es feststeht. Viele Grüße Lars [1] http://wiki.openstreetmap.org/wiki/Berlin_Hack_Weekend_Januar_2014 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Grundriss vs Dachfläche
Am 13.01.2014 12:29, schrieb Ronnie Soak: Ich weiß nicht ob die 3D Renderer in letzter Zeit toleranter geworden sind, aber bei einem Turm mit Kopf muss die Umrisslinie des Kopfes als building eingetragen werden (also die breiteste Stelle), und nicht die Aufstandsfläche des Turmfußes. Auslegungssache. Ich würde sagen, dann muss weiterhin die Aufstandsfläche gemappt werden und ggfs. ein falsches Renderergebnis in Kauf genommen werden, bis der Renderer das vernünftig unterstützt. Wenn ich an Dächer Denke, ist das derzeit aber nicht Praxis. Man müsste dann die Dachstützen statt der Dachfläche mappen. Oder mit welcher Begründung ist hier ein einzelner Spezialrenderer plötzlich ausschlaggebend für die Auslegung bestehender Taggingpraxis? Das hat mit dem Renderer nichts zu tun. Wenn die Frage für mich klar wäre, was erfasst wird, würde ich den Anwender/Renderer darauf hinweisen. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Grundriss vs Dachfläche
Am 13.01.2014 12:29, schrieb Ronnie Soak: Ich würde sagen, dann muss weiterhin die Aufstandsfläche gemappt werden und ggfs. ein falsches Renderergebnis in Kauf genommen werden, bis der Renderer das vernünftig unterstützt. Oder mit welcher Begründung ist hier ein einzelner Spezialrenderer plötzlich ausschlaggebend für die Auslegung bestehender Taggingpraxis? Wir reden nicht von einem einzelnen Renderer, sondern von einer software-übergreifenden Konvention fürs 3D-Mapping und -Rendering. Nach dieser Definition wäre die building-Fläche der Gesamt-Mauerumriss aller Stockwerke, um es mal so auszudrücken. Dass tatsächlich nur der Umriss auf dem Erdboden gemappt würde, ist auch in der Praxis nicht unbedingt der Fall, denn bei Gebäuden auf Pfeilern u.ä. Konstruktionen vermitteln ein paar einsame Punkte ein völlig verzerrtes Bild vom Gebäude. Und ich halte es auch keineswegs für abwegig, dass das 3D-Rendering eine wichtige Rolle bei der Etablierung solcher Definitionen spielt. Schließlich ist das der erste Anwendungsfall, in dessen Rahmen die vertikale Dimension von Gebäuden überhaupt nennenswert berücksichtigt wird. Gruß, Tobias ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Grundriss vs Dachfläche
Am 13.01.2014 14:52, schrieb Tobias Knerr: Dass tatsächlich nur der Umriss auf dem Erdboden gemappt würde, ist auch in der Praxis nicht unbedingt der Fall, denn bei Gebäuden auf Pfeilern u.ä. Konstruktionen vermitteln ein paar einsame Punkte ein völlig verzerrtes Bild vom Gebäude. Wobei man beim 3D-Mapping tendenziell ohnehin alle Infos braucht. Und ich halte es auch keineswegs für abwegig, dass das 3D-Rendering eine wichtige Rolle bei der Etablierung solcher Definitionen spielt. Schließlich ist das der erste Anwendungsfall, in dessen Rahmen die vertikale Dimension von Gebäuden überhaupt nennenswert berücksichtigt wird. +1 Aber beim 3D-Modellieren könnte man zur Not doch auch das Modell so ändern, dass neben der Mauer am Boden auch die größte Fläche, die das Gebäude beschreibt gemapt wird (nicht unbedingt mit dem building-Tag) - das würde ich dort zumindest als wünschenswertes Ziel sehen. Das heißt: Eigentlich motiviert das 3D-Modellieren erstmalig das Mappen der Mauer am Boden. Bisher sehe ich da nur Tags wie tunnel=building_passage oder covered=yes, die suggerieren, dass es nicht um die Mauer am Boden geht. Trotzdem: Aus meiner Sicht gibt es derzeit keine Saubere Definition der building-Fläche im Wiki. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Singen (Hohentwiel): Straßennamen und Busliniennummer
hallo, eigentlich wollte ich nur offensichtlich falsche Straßennamen berichtigen, aber nun artet es in mehr als das aus. Hier http://osm.org/go/0C10td1eE- sind Namen zusammengeschrieben, die bestimmt in zwei Worten geschrieben werden müssen: Pommerschestraße Schlesischestraße Danzigerstraße Breslauerstraße Stettinerstraße Wenn ich nach einer Quelle für die richtige Schreibweise suche, finde ich den Buslinienplan. http://www.stadtwerke-singen.de/pdfs/buslinien_2013.pdf Darin stehen die Straßen Danziger Str. und Breslauer Str. so geschrieben, wie ich es erwartete. Würde das als Quelle reichen oder welche andere Quelle wäre nötig? Und außerdem sehe ich, dass die angebliche Linie 4 http://www.öpnvkarte.de/?lat=47.74785lon=8.85827zoom=16layers=TBTTT wohl Linie 6 ist: http://www.stadtwerke-singen.de/pdfs/linie6_2014.pdf So, mit meinen guten Absichten, hier Fehler zu berichtigen, bin ich nun unsicher: Kann ich einfach die Haltestellen-Einträge mit ändern (Danzigerstraße - Danziger Straße) oder bringe ich damit ungewollt Fahrpläne u.ä. durcheinander? Ist vielleicht jemand näher dran als ich, der sich dort auskennt? Grüße Andreas ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Singen (Hohentwiel): Straßennamen und Busliniennummer
Am 13. Januar 2014 18:41 schrieb Andreas Schmidt schmidt-postf...@freenet.de: Wenn ich nach einer Quelle für die richtige Schreibweise suche, finde ich den Buslinienplan. http://www.stadtwerke-singen.de/pdfs/buslinien_2013.pdf Darin stehen die Straßen Danziger Str. und Breslauer Str. so geschrieben, wie ich es erwartete. Würde das als Quelle reichen oder welche andere Quelle wäre nötig? am besten ist immer hinfahren und nachsehen. Von anderen Quellen darf man Daten nur dann übernehmen, wenn das ausdrücklich gestattet ist, und selbst dann bleibt immer das Problem, dass alle Quellen Fehler haben. Ob man das auch so streng sehen will, wenn es nur um Rechtschreibfehler geht, muss man sehen ;-) wobei Namen eben Namen sind, und sich nicht unbedingt an die Rechtschreibung halten müssen. Die richtige Quelle für Straßennamen ist normalerweise das kommunale Archiv (Rathaus o.ä.), wo man die entsprechende Widmung aus den Protokollen der Gemeinderatssitzungen in mühseliger Kleinarbeit zu finden versuchen kann. Im konkreten Fall von Singen sind die Protokolle (zumindest die letzten) zwar im Internet, aber schön hinter einem login gesichert, damit nicht Hinz und Kunz einfach anonym nachsieht, was die so treiben ;-) https://singen.allris-online.de/ri/logon.asp Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSBs schliessen ohne Kommentar und Username
Am Montag, den 13.01.2014, 00:38 +0100 schrieb Wolfgang Hinsch: Am Sonntag, den 12.01.2014, 18:56 +0100 schrieb Werner Hoch: Du nennst es voreilig. Konstruktive Vorschläge für die schrittweise Abschaltung sind willkommen. Welcher Zeitraum wäre für dich sinnvoll gewesen, in welchen Schritten? Worin bestand eigentlich das Problem, die bisherigen OSB-Einträge in die Notes zu übernehmen und dann OSB abzuschalten? Der Aufwand, die OSBs manuell zu überprüfen und ggf. zu übertragen dürfte in jedem Fall wesentlich größer sein. OSBs sind zu 80% entweder leicht zu beheben oder aber wurden schon behoben. Hätte man alle nach Notes übernommen, dann müsste man die Fehler ja immer noch bearbeiten -- sehr viel unnütze Fehlereinträge in Notes. Die Bearbeitung von OSBs ist ja prinzipiell gleich aufwändig wie in Notes. Die Übertragung von sinnvollen Bugs kann mit einem Mausclick erfolgen. Ein Mehraufwand existiert meiner Meinung nach nicht. s. https://wiki.openstreetmap.org/wiki/OpenStreetBugs/Phase_Out#Tools Grüße Werner ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSBs schliessen ohne Kommentar und Username
Am 13. Januar 2014 20:08 schrieb Werner Hoch werner...@gmx.de: Die Bearbeitung von OSBs ist ja prinzipiell gleich aufwändig wie in Notes. Die Übertragung von sinnvollen Bugs kann mit einem Mausclick erfolgen. Ein Mehraufwand existiert meiner Meinung nach nicht. s. https://wiki.openstreetmap.org/wiki/OpenStreetBugs/Phase_Out#Tools Der Mehraufwand besteht darin, dass ich die OSB erstmal suchen muss (deren Webseite etc.), während die Notes mir über osm.org auf einem Silbertablett daherkommen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSBs schliessen ohne Kommentar und Username
On 12.01.2014 12:31, Florian Lohoff wrote: ich sehe hier seit 3 Tagen das irgendjemand einfach ohne irgendwas zu machen OSB Bugs schliesst. Die Bugs gehen ohne Username und Ohne Kommentar einfach zu. Mittlerweile sind 30 Bugs von mir im Umkreis Guetersloh/Rheda-Wiedenbrück geschlossen worde. ICH MUSS KOTZEN ! Geht mir genau so. Das Vorgehen, die Bugs kommentarlos anonym zu löschen bedeutet planlosen Datenverlust und geht gar nicht. Hier um Paderborn versuche ich gerade, die gerade geschlossenen, mir für wichtig erscheinenden Bugs nach OSM Notes 'rüberzuretten'. Bei der Gelegenheit sind als netter Nebeneffekt ein paar Probleme nach den NRW Atlas Daten auch schon zu klären. Nach dem Motto Not-Tugend oder so ähnlich. Aber rund um Rheda ist/war die Bugdichte auch um ein Vielfaches grösser. Peter ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Grundriss vs Dachfläche
Am 13. Januar 2014 14:52 schrieb Tobias Knerr o...@tobias-knerr.de: Wir reden nicht von einem einzelnen Renderer, sondern von einer software-übergreifenden Konvention fürs 3D-Mapping und -Rendering. Nach dieser Definition wäre die building-Fläche der Gesamt-Mauerumriss aller Stockwerke, um es mal so auszudrücken. was allerdings gravierende Nachteile für alle die hätte, die sich die Welt nur in 2D ansehen, weil für die in manchen Fällen ein völlig verzerrtes Bild der Freiräume auf der Ebene entsteht, die für sie ggf. zugänglich ist (aussen drum herum). Dass tatsächlich nur der Umriss auf dem Erdboden gemappt würde, ist auch in der Praxis nicht unbedingt der Fall, denn bei Gebäuden auf Pfeilern u.ä. Konstruktionen vermitteln ein paar einsame Punkte ein völlig verzerrtes Bild vom Gebäude. wobei dafür die (Aussen-)Räume gut wiedergegeben sind. Und ich halte es auch keineswegs für abwegig, dass das 3D-Rendering eine wichtige Rolle bei der Etablierung solcher Definitionen spielt. Schließlich ist das der erste Anwendungsfall, in dessen Rahmen die vertikale Dimension von Gebäuden überhaupt nennenswert berücksichtigt wird. wobei die Leute, die 3D betreiben, da ein ziemlich isoliertes Süppchen kochen, und (zumindest noch vor einiger Zeit, vielleicht ist das ja jetzt besser geworden) auch verschiedene Konzepte parallel umgesetzt werden. Wer tag-Definitionen etablieren will, sollte sich auch auf [tagging] mit der Kommunity auseinandersetzen und sehen, ob seine Vorstellungen in Teilbereichen evtl. mit anderen Erfordernissen bzw. Setzungen kollidieren, und wie man das am besten unter einen Hut bekommen kann. Ich erinnere mich z.B. an die building:levels (Stockwerksanzahl), wo einfach mal jemand ein Schaubild ins Wiki gestellt hat, dass es sich dabei nur um überirdische Stockwerke handele, dafür aber nichtexistierende Stockwerke mitgezählt werden bei kragenden Bauteilen. Nach einiger Zeit hiess es dann, das sei etabliert und so ist der Stand AFAIK noch heute, wobei ich das für extrem fehlerträchtig und unintuitiv halte. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSBs schliessen ohne Kommentar und Username
On 13.01.2014 19:20, Martin Koppenhoefer wrote: Am 13. Januar 2014 20:08 schrieb Werner Hoch werner...@gmx.de: Die Bearbeitung von OSBs ist ja prinzipiell gleich aufwändig wie in Notes. Die Übertragung von sinnvollen Bugs kann mit einem Mausclick erfolgen. Ein Mehraufwand existiert meiner Meinung nach nicht. s. https://wiki.openstreetmap.org/wiki/OpenStreetBugs/Phase_Out#Tools Der Mehraufwand besteht darin, dass ich die OSB erstmal suchen muss (deren Webseite etc.), während die Notes mir über osm.org auf einem Silbertablett daherkommen. Zugegeben, das JOSM-Plugin würde vielleicht ein bischen früh abgeschaltet, allerdings besteht immernoch die Möglichkeit es manuell vom SVN herunterzuladen und zu installieren. Optimal wäre wohl an Version ohne Möglichkeit neue Bugs zu erstellen. cu fly ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Highway Shields (Strassennummern)
Hallo, in Nordamerika sind sie ganz wild darauf, richtige highway shields zu zeichnen. Bei denen hat ein- und dieselbe Strasse manchmal 8 verschiedene Nummern, die noch dazu jeweils in unterschiedlichen Arten von Kaestchen zu zeichnen sind. http://elrond.aperiodic.net/shields/?zoom=14lat=39.76391lon=-86.02913layers=B0 ist ein schoenes Beispiel, und hier http://vimeopro.com/openstreetmapus/state-of-the-map-us-2013/video/68097487 ein Talk von Phil Gold, in dem er erklaert, wie er mit Hilfe von Python und fiesen Hacks mit planet_osm_rels solche komplizierten Shields bastelt. Bei uns hingegen scheint diese Thematik niemand hinter dem Ofen hervorzulocken. Ich bin da jetzt kein Experte, aber dieses Stueck Autobahn in der Bildmitte hier http://www.openstreetmap.de/karte.html?zoom=13lat=48.7544lon=9.02627layers=B000TT ist z.B. gleichzeitig A81 und A8. Es ist im Stil ueberhaupt nicht benummert, weil bei uns die Nummern nicht nach Relationen, sondern nach ref-Tags gesetzt werden, und das ref fuer diese Autobahn ist offenbar A 8;A 81. Der Stil hat aber keine Shields fuer 8-stellige Nummern, und daher kommt hier gar nix ;) Hat sich jemand schonmal Gedanken gemacht, wie man das loesen sollte - sollen wir einfach auch auf den amerikanischen Zug mit aufspringen, oder waere das fuer D-A-CH-Verhaeltnisse mit Kanonen auf Spatzen geschossen? (Ich poste das hier auch mal ins Forum, weil ich weiss, dass da ein paar Routenspezialisten unterwegs sind.) Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Highway Shields (Strassennummern)
Hi! Am 13. Januar 2014 20:05 schrieb Frederik Ramm frede...@remote.org: Ich bin da jetzt kein Experte, aber dieses Stueck Autobahn in der Bildmitte hier http://www.openstreetmap.de/karte.html?zoom=13lat=48.7544lon=9.02627layers=B000TT ist z.B. gleichzeitig A81 und A8. Es ist im Stil ueberhaupt nicht benummert, weil bei uns die Nummern nicht nach Relationen, sondern nach ref-Tags gesetzt werden, und das ref fuer diese Autobahn ist offenbar A 8;A 81. Der Stil hat aber keine Shields fuer 8-stellige Nummern, und daher kommt hier gar nix ;) Wie ich erst vor kurzem auf tagging schrieb: schön langsam sollte man sich Gedanken darüber machen den verschiedensten Tools und Anwendungen den Umgang mit Strichpunkt-separierten Werten beizubringen. Beste Grüße, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Grundriss vs Dachfläche
Am 13.01.2014 19:35, schrieb Martin Koppenhoefer: Am 13. Januar 2014 14:52 schrieb Tobias Knerr o...@tobias-knerr.de: Wir reden nicht von einem einzelnen Renderer, sondern von einer software-übergreifenden Konvention fürs 3D-Mapping und -Rendering. Nach dieser Definition wäre die building-Fläche der Gesamt-Mauerumriss aller Stockwerke, um es mal so auszudrücken. was allerdings gravierende Nachteile für alle die hätte, die sich die Welt nur in 2D ansehen, weil für die in manchen Fällen ein völlig verzerrtes Bild der Freiräume auf der Ebene entsteht, die für sie ggf. zugänglich ist (aussen drum herum). Ich finde, dass an beiden Positionen etwas dran ist. Aber letztendlich sollte das doch der Renderer entscheiden können. Vor allem sollten die Positionen aber nicht als Gegenposition verstanden werden, weil wie gesagt für die 3D-Modelle alle Daten wichtig sind. Zuletzt liegt es aber auch nicht an den 3D-Tags, dass ein Gebäude, durch das eine Einfahrt verläuft, in OSM als eine durchgehende Fläche gemapt wird. wobei die Leute, die 3D betreiben, da ein ziemlich isoliertes Süppchen kochen, und (zumindest noch vor einiger Zeit, vielleicht ist das ja jetzt besser geworden) auch verschiedene Konzepte parallel umgesetzt werden. Wer tag-Definitionen etablieren will, sollte sich auch auf [tagging] mit der Kommunity auseinandersetzen und sehen, ob seine Vorstellungen in Teilbereichen evtl. mit anderen Erfordernissen bzw. Setzungen kollidieren, und wie man das am besten unter einen Hut bekommen kann. Ich erinnere mich z.B. an die building:levels (Stockwerksanzahl), wo einfach mal jemand ein Schaubild ins Wiki gestellt hat, dass es sich dabei nur um überirdische Stockwerke handele, dafür aber nichtexistierende Stockwerke mitgezählt werden bei kragenden Bauteilen. Nach einiger Zeit hiess es dann, das sei etabliert und so ist der Stand AFAIK noch heute, wobei ich das für extrem fehlerträchtig und unintuitiv halte. +1. Ich benutze das zwar häufig, aber vom intuitiven Verständnis würde jeder vermuten, dass dieser Key die Gesamtstockwerkezahl des Gebäudes beschreibt. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Highway Shields (Strassennummern)
Hi, On 13.01.2014 20:13, Martin Vonwald wrote: Wie ich erst vor kurzem auf tagging schrieb: schön langsam sollte man sich Gedanken darüber machen den verschiedensten Tools und Anwendungen den Umgang mit Strichpunkt-separierten Werten beizubringen. Oder man geht komplett vom ref weg, zumindest bei Autobahnen und Bundesstrassen, und rendert die Nummern nach Mitgliedschaft in einer Routenrelation, das ginge auch. Bei Buslinien taggen wir ja auch nicht an die Strasse dran bus=Bus 171;Bus 59; Bus 28 ;) Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Grundriss vs Dachfläche
Am 13. Januar 2014 20:22 schrieb cracklinrain cra_klinr...@gmx.de: Ich finde, dass an beiden Positionen etwas dran ist. Aber letztendlich sollte das doch der Renderer entscheiden können. Vor allem sollten die Positionen aber nicht als Gegenposition verstanden werden, weil wie gesagt für die 3D-Modelle alle Daten wichtig sind. ja, sicherlich sind alle Daten wichtig. Wobei eine Einigung schon sinnvoll wäre, ob man mit building nun den Teil mappt, der auf dem Boden steht, oder ob es der Umriss aller Bauteile und Stockwerke ist, also auch der schwebenden --- wobei die 3D-Leute wahrscheinlich gern den unterirdischen Teil unterschlagen wollen, zumindest bis jemand eine Anwendung herausbringt, mit der man Geländeschnitte generieren kann ;-) Prinzipiell denke ich, dass die 2. Variante ohne Zusatzinformationen niemandem was bringt (auch wer ein 3D-Modell bauen will, braucht ja die einzelnen Teile und der Gesamtumriss bringt nichts ausser dass man damit abschätzen kann, welche Teile vermutlich zu einem Gebäude gehören, wobei das auch nicht in allen Fällen gut geht). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSBs schliessen ohne Kommentar und Username
On Mon, Jan 13, 2014 at 07:26:38PM +0100, Peter Czaja wrote: Geht mir genau so. Das Vorgehen, die Bugs kommentarlos anonym zu löschen bedeutet planlosen Datenverlust und geht gar nicht. Hier um Paderborn versuche ich gerade, die gerade geschlossenen, mir für wichtig erscheinenden Bugs nach OSM Notes 'rüberzuretten'. Bei der Gelegenheit sind als netter Nebeneffekt ein paar Probleme nach den NRW Atlas Daten auch schon zu klären. Nach dem Motto Not-Tugend oder so ähnlich. Aber rund um Rheda ist/war die Bugdichte auch um ein Vielfaches grösser. Ich habe da selber meine Arbeit mit koordiniert. Alles was ich als unstimmig im Augenwinkel wahrgenommen habe oder wo dinge nicht so offentlich nach meiner erinnerung fehlte. RhWd ist auch Adresstechnisch im Begriff komplettiert zu werden und auch da habe ich bugs gesetzt wo es unstimmigkeiten in den Hausnummern gab. Quasi alles hops gegangen ... Flo -- Florian Lohoff f...@zz.de signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Bamberg = hsb:Babin?
Hi, das hier ist mir neulich aufgefallen - http://www.openstreetmap.org/node/1646638496/history als Obersorbischer name für Bamberg ist hier Babin eingetragen was laut meinem Sprachgefühl und einem Online-Wörterbuch falsch wäre. Babin hat laut Wörterbuch irgendwas mit Hebammen oder alten Weibern zu tun. Bin trotzdem vorsichtig es so einfach ohne Rückfrage zu löschen. Die History ist leider wenig hilfreich weil der hsb:Babin anscheinend vor der Lizenzänderung eingetragen wurde und damit nicht sichtbar ist wie es hingekommen ist:( Kann sich jemand zufällig erinnern oder hat eine Idee? Richard --- Name and OpenPGP keys available from pgp key servers ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Highway Shields (Strassennummern)
Hi, jetzt fängst du aber mit Ausweichtaktiken an. Es fehlt doch offensichtlich ganz generell an der Softwareunterstützung für mehrwertige Tags, da ist ref doch bei weitem kein Einzelfall, oder hat sich das mittlerweile so stark gewandelt? Beispiele bei der Suche nach amenity-Keys, die ein Semikolon enthalten: amenity=parking;fuel (4523, wobei viele davon vom AND-Import kommen) amenity=restaurant;cafe (44) amenity=restaurant; pension amenity=pub;restaurant;bar amenity=hospital; univeristy amenity=fast_food;cafe cuisine=italian;ice_cream amenity=fuel; garage amenity=fuel;compressed_air amenity=pharmacy;post_office;vending_machine amenity=bank;atm amenity=restaurant;bistro amenity=bench;shelter amenity=drinking_water; waste_disposal amenity=bank;post_office amenity=post_office;bank amenity=parcel_box;post_box amenity=cafe;pub;restaurant amenity=post_box; telphone amenity=restaurant;biergarten amenity=vending_machine;waste_basket amenity=hospital; pharmacy amenity=fitness_center;sauna amenity=restaurant;pub amenity=pub;restaurant amenity=restaurant; hotel tourism=guest_house; hotel amenity=nightclub;pub amenity=cafe;post_office amenity=theatre;cinema amenity=theatre; school amenity=cafe;arts_centre shop=kiosk;car_repair amenity=doctors; dentist amenity=recycling;waste_container amenity=language_school;something else (!!! ;) ) amenity=doctors; pharmacy amenity=fuel;compressed_air;car_wash amenity=bar;restaurant (71) amenity=public_building; toilets amenity=waste_basket;bench amenity=waste_basket;recycling (170) amenity=place_of_worship;graveyard amenity=cafe;pub;nightclub amenity=restaurant;guest_house amenity=bench;fountain amenity=public_building; social_facility amenity=college;education_centre cuisine=pizza;kebab amenity=bar;community_centre amenity=restaurant;ice_cream amenity=bar;nightclub amenity=kindergarten;school amenity=bar;casino amenity=charging_station;bicycle_parking amenity=toilets;shower amenity=swimming_pool;sauna;gym amenity=school;place_of_worship (88) amenity=parking;restaurant;fuel (50) highway=residential;unclassified (134x laut taginfo) highway=path;track (68x laut taginfo) highway=traffic_signals;crossing (62x) highway=unclassified;residential (44) highway=residential;track (43) Das sind offensichtlich gar nicht so viele, aber ich will nicht wissen, wie oft eins von beidem weggelassen wird, weil es eben keine Unterstützung für die Kombitags gibt, oder wie oft eine Einrichtung aus demselben Grund doppelt in OSM auftaucht. Hotel/Restaurant ist häufig kombiniert, und oft lässt es sich eigentlich nicht sinnvoll räumlich trennen. Cafe/Restaurant dürfte noch ähnlich oft vorkommen. weitere Kombinationen, die bestimmt häufig sind: Sauna und Schwimmbad Sauna und Fitness-Studio Mülleimer und Straßenlaterne (auch wenn beides oft nicht eingetragen wird) Und ich finde die Situation eigentlich unbefriedigend, dass ich einen Laden, der mittags warme Küche hat, abends als Kneipe läuft und spät abends bzw. am Wochenende zur Disco mutiert, nicht gleichzeitig als alles taggen kann. Sollen wir jetzt zusätzliche Tags für gängige Kombinationen finden? Ich bin mir nicht sicher, ob das wirklich die bessere Lösung wäre Gruß Peter Am 13.01.2014 20:30, schrieb Frederik Ramm: Hi, On 13.01.2014 20:13, Martin Vonwald wrote: Wie ich erst vor kurzem auf tagging schrieb: schön langsam sollte man sich Gedanken darüber machen den verschiedensten Tools und Anwendungen den Umgang mit Strichpunkt-separierten Werten beizubringen. Oder man geht komplett vom ref weg, zumindest bei Autobahnen und Bundesstrassen, und rendert die Nummern nach Mitgliedschaft in einer Routenrelation, das ginge auch. Bei Buslinien taggen wir ja auch nicht an die Strasse dran bus=Bus 171;Bus 59; Bus 28 ;) Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Softwareunterstützung für Semikolon getrennte Tags
On 13.01.2014 22:12, Peter Wendorff wrote: jetzt fängst du aber mit Ausweichtaktiken an. Ich glaube eher Du wechselst gerade das Thema. Ich habe den Betreff dahingehend angepasst. Die ursprüngliche Frage war ja ganz speziell auf Highway Shields ausgerichtet. Beispiele bei der Suche nach amenity-Keys, die ein Semikolon enthalten: highway=residential;unclassified (134x laut taginfo) highway=path;track (68x laut taginfo) highway=traffic_signals;crossing (62x) highway=unclassified;residential (44) highway=residential;track (43) Schon mal mit JOSM Wege oder andere Elemente verbunden? Der Default ist (oder war?) dass im Tag dann alle bisherigen Werte stehen, eben mit einem Semikolon getrennt. Ich denke das allermeiste dieser Stellen sind solche Fälle bei denen der Anwender das nicht gemerkt und korrigiert hat. Jochen Topf hatte vor einiger Zeit eine recht umfangreiche Untersuchung gemacht was die Verwendung von Semikolon angeht. Ganz trivial ist die Lösung des Problems nicht. http://blog.jochentopf.com/2013-09-23-semicolons-in-osm-tags.html Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Softwareunterstützung für Semikolon getrennte Tags
Dass das Problem nicht trivial ist, ist mir klar. Die automatisch erzeugten Werte von JOSM beim verbinden von Wegen sind da ein Problem, ja. Aber die von mir angesprochenen Kombinationen sind eben durchaus auch üblich und tatsächlich ein Grenzfall. Was Jochen unter But of course in this case it only means that somebody couldn’t make up their mind whether to use lake or pond and chose the worst: both. beschreibt. Nur ist das nur das Schlechteste, solange es nicht genutzt und interpretiert wird. Was mache ich denn mit dem erwähnten Restaurant/Cafe oder Hotel/Restaurant, Begriffen, die ja sogar fast in die allgemeine Sprache aufgenommen ist so als Doppelworte? Was mache ich mit einem Autohaus mit Werkstatt (shop=car, shop=car_repair), bei dem beides nicht sinnvoll voneinander trennbar ist? Sicher: Das Semikolon immer als Doppelwert zu interpretieren, und das an jedem Tag einfach so, wird schiefgehen; die Beispiele in Jochens Artikel machen deutlich dass das Semikolon auch anderes meinen kann. Aber es gibt die Doppelwerte, und ref=*, worum es hier ursprünglich ging, ist meines Erachtens auch ein gutes Beispiel. Immer wieder beschweren sich gerade neue Mapper, das Mappen sei so komplex, man könne eigentlich keinen Weg mehr unterteilen, ohne zig Relationen kaputtzumachen bzw. reparieren zu müssen; und das zum Teil zu Recht, wie ich finde. Bisher sind es nur Buslinien und große Rad/Wanderrouten, die großflächig als Relationen eingetragen sind; bei Autobahnen, Bundesstraßen etc. ist das meines Erachtens viel zu häufig, aber das hält sich in Grenzen. Wenn wir jetzt bei Kreisstraßen, Landstraßen etc. weitermachen, alles in Relationen zu verpacken, nur weil es eine zusammenfassende Nummer hat, wächst sich das wieder zu einem Ungetüm aus. Dann können wir demnächst auch nur noch ungetaggte Ways nutzen, und alle Tags auf Relationen übertragen, wie das tendentiell schon bei Multipolygonen passiert. Aber wer sich hinterher über untagged-ways beschwert, ist dann selbst Schuld, wenn jetzt das Gegenteil gefordert wird. Ob ich die A30 als Relation zusammenfasse oder die E27, die Buslinie 7 oder die Goethestraße, das ist im Prinzip alles das gleiche, und wenn wir ref=7;10, ref=B55;E27 etc. nicht haben wollen, wird uns nichts anderes übrigbleiben, als eben wirklich alles in die Relationen zu verschieben. Ob das die bessere Lösung ist, bezweifle ich aber erstmal. Gruß Peter Am 13.01.2014 22:35, schrieb Stephan Knauss: On 13.01.2014 22:12, Peter Wendorff wrote: jetzt fängst du aber mit Ausweichtaktiken an. Ich glaube eher Du wechselst gerade das Thema. Ich habe den Betreff dahingehend angepasst. Die ursprüngliche Frage war ja ganz speziell auf Highway Shields ausgerichtet. Beispiele bei der Suche nach amenity-Keys, die ein Semikolon enthalten: highway=residential;unclassified (134x laut taginfo) highway=path;track (68x laut taginfo) highway=traffic_signals;crossing (62x) highway=unclassified;residential (44) highway=residential;track (43) Schon mal mit JOSM Wege oder andere Elemente verbunden? Der Default ist (oder war?) dass im Tag dann alle bisherigen Werte stehen, eben mit einem Semikolon getrennt. Ich denke das allermeiste dieser Stellen sind solche Fälle bei denen der Anwender das nicht gemerkt und korrigiert hat. Jochen Topf hatte vor einiger Zeit eine recht umfangreiche Untersuchung gemacht was die Verwendung von Semikolon angeht. Ganz trivial ist die Lösung des Problems nicht. http://blog.jochentopf.com/2013-09-23-semicolons-in-osm-tags.html Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Softwareunterstützung für Semikolon getrennte Tags
Hi, On 13.01.2014 23:10, Peter Wendorff wrote: Sicher: Das Semikolon immer als Doppelwert zu interpretieren, und das an jedem Tag einfach so, wird schiefgehen; die Beispiele in Jochens Artikel machen deutlich dass das Semikolon auch anderes meinen kann. Aber es gibt die Doppelwerte, und ref=*, worum es hier ursprünglich ging, ist meines Erachtens auch ein gutes Beispiel. Allerdings eins, bei dem Relationen eine ganz gute oder zumindest funktionierende Loesung sind; bei Hotel-Restaurants hingegen wird man damit nicht weit kommen. Bis zu API 0.3 uebrigens (oder wars sogar 0.4) konnte ein Objekt in OSM uebrigens tatsaechlich mehrere Tags desselben Keys haben. Wir haben das dann abgeschafft, weil fast keine damals gaengige Software das auch unterstuetzt hat - einmal ein Objekt mit so einem Doppeltag mit JOSM bearbeitet, schon wurde zufaellig einer der beiden Tags gewaehlt... Du hast schon recht, es waere wuenschenswert, wenn Software das automatisch richtig machen wuerde, aber puh, das wird ein langer und steiniger Weg. Am Anfang stuende die Frage: Sollen wir * alle Tags ausser die in einer bestimmten Negativliste (note, comment, ...) am Semikolon aufsplitten? * nur Tags aus einer bestimmten Positivliste (amenity, ref, ...) am Semikolon aufsplitten? Wenn ja - wie verteilen wir diese Listen zwischen allen Programmen? * Tags nur dann aufsplitten, wenn sie einer bestimmten Form genuegen (z.B.: wenn der Value mit einem Semikolon *beginnt*)? Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Softwareunterstützung für Semikolon getrennte Tags
On 13.01.2014 23:40, Frederik Ramm wrote: Du hast schon recht, es waere wuenschenswert, wenn Software das automatisch richtig machen wuerde, aber puh, das wird ein langer und steiniger Weg. Am Anfang stuende die Frage: Sollen wir eventuell helfen dann doch weitere Datentypen in der API. Also nicht nur key=value Paare, sondern noch etwas mehr. Eine Idee für Api 0.7 Geordnete Listen: Ein Datentyp bei dem 1..n Values in einer definierten Reihenfolge nacheinander kommen. Doppelte Values sind erlaubt. Sets: Aufzählungen von 1..n Values. Die Reihenfolge spielt keine Rolle, doppelte Values sind verboten. Wäre eine größere Änderung, dürfte aber viele der bisherigen Verwendungen vom Semikolon abdecken. Bisherige Werte in der Datenbank blieben als value erhalten bis es jemand von Hand (oder script) konvertiert. ABER: Das ist eine recht große Änderung die eine Modifikation an jeder Software erfordern würde die die Daten verarbeiten will. Um kompatibel zu bleiben müsste es eventuell einen Konverter geben der den API 0.7 output wieder zusammenmergen kann in einen einzelnen value mit Semikolon für nicht angepasste alte Software. Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Softwareunterstützung für Semikolon getrennte Tags
Am 14.01.2014 00:40, schrieb Stephan Knauss: On 13.01.2014 23:40, Frederik Ramm wrote: Du hast schon recht, es waere wuenschenswert, wenn Software das automatisch richtig machen wuerde, aber puh, das wird ein langer und steiniger Weg. Am Anfang stuende die Frage: Sollen wir eventuell helfen dann doch weitere Datentypen in der API. Also nicht nur key=value Paare, sondern noch etwas mehr. Eine Idee für Api 0.7 Geordnete Listen: Ein Datentyp bei dem 1..n Values in einer definierten Reihenfolge nacheinander kommen. Doppelte Values sind erlaubt. Sets: Aufzählungen von 1..n Values. Die Reihenfolge spielt keine Rolle, doppelte Values sind verboten. Wäre eine größere Änderung, dürfte aber viele der bisherigen Verwendungen vom Semikolon abdecken. Bisherige Werte in der Datenbank blieben als value erhalten bis es jemand von Hand (oder script) konvertiert. ABER: Das ist eine recht große Änderung die eine Modifikation an jeder Software erfordern würde die die Daten verarbeiten will. Um kompatibel zu bleiben müsste es eventuell einen Konverter geben der den API 0.7 output wieder zusammenmergen kann in einen einzelnen value mit Semikolon für nicht angepasste alte Software. Oder die API wird tatsächlich mit der Dokumentation im Wiki verzahnt und dieser Typ kann im Wiki angegeben werden, also z.B. im Wiki für die Bojen-Farben: value-type: List Bei Lanes: List Bei amenity: Set Bei name: String etc. Dann kann der bestehende Wert (amenity=bar;restaurant) der Dokumentation entsprechend behandelt werden (als eine ungeordnete Menge), beim name als ein einzelner Wert, selbst wenn ein Semikolon vorkommen sollte. Das kann natürlich auch Teil der API sein, aber selbst wenn nicht ließe sich das vermutlich umsetzen. Die größte Hürde sehe ich in der Software, die die OSM-Daten anwendet, denn die muss mehrere Werte unterstützen - Renderer, Router, ... Wir mappen zwar nicht für [Anwendungsimplementierung X], aber viele Anwendungen, gerade Mapnik, OSRM etc. sind eben doch treibende Kraft dafür, dass Mapper großflächig Daten beisteuern und vor allem korrigieren; notfalls korrigieren in dem Sinne, dass [Anwendung X] dann wieder funktioniert. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Softwareunterstützung für Semikolon getrennte Tags
Eine Set würde ich in API 0.7 bevorzugen, denn so könnte man bspw. die Unterschiedlichen Öffnungszeiten kenntlich machen. key=name value=Zum Goldenen Löwen / set key=amenity value=restaurant / key=opening_hours value=Mo-Su 11:00-21:00 /set set key=tourism value=hotel / key=opening_hours value=24/7 /set set key=amenity value=cafe / key=opening_hours value=Sa,Su 14:00-17:00 /set Am 14. Januar 2014 08:33 schrieb Peter Wendorff wendo...@uni-paderborn.de: Am 14.01.2014 00:40, schrieb Stephan Knauss: On 13.01.2014 23:40, Frederik Ramm wrote: Du hast schon recht, es waere wuenschenswert, wenn Software das automatisch richtig machen wuerde, aber puh, das wird ein langer und steiniger Weg. Am Anfang stuende die Frage: Sollen wir eventuell helfen dann doch weitere Datentypen in der API. Also nicht nur key=value Paare, sondern noch etwas mehr. Eine Idee für Api 0.7 Geordnete Listen: Ein Datentyp bei dem 1..n Values in einer definierten Reihenfolge nacheinander kommen. Doppelte Values sind erlaubt. Sets: Aufzählungen von 1..n Values. Die Reihenfolge spielt keine Rolle, doppelte Values sind verboten. Wäre eine größere Änderung, dürfte aber viele der bisherigen Verwendungen vom Semikolon abdecken. Bisherige Werte in der Datenbank blieben als value erhalten bis es jemand von Hand (oder script) konvertiert. ABER: Das ist eine recht große Änderung die eine Modifikation an jeder Software erfordern würde die die Daten verarbeiten will. Um kompatibel zu bleiben müsste es eventuell einen Konverter geben der den API 0.7 output wieder zusammenmergen kann in einen einzelnen value mit Semikolon für nicht angepasste alte Software. Oder die API wird tatsächlich mit der Dokumentation im Wiki verzahnt und dieser Typ kann im Wiki angegeben werden, also z.B. im Wiki für die Bojen-Farben: value-type: List Bei Lanes: List Bei amenity: Set Bei name: String etc. Dann kann der bestehende Wert (amenity=bar;restaurant) der Dokumentation entsprechend behandelt werden (als eine ungeordnete Menge), beim name als ein einzelner Wert, selbst wenn ein Semikolon vorkommen sollte. Das kann natürlich auch Teil der API sein, aber selbst wenn nicht ließe sich das vermutlich umsetzen. Die größte Hürde sehe ich in der Software, die die OSM-Daten anwendet, denn die muss mehrere Werte unterstützen - Renderer, Router, ... Wir mappen zwar nicht für [Anwendungsimplementierung X], aber viele Anwendungen, gerade Mapnik, OSRM etc. sind eben doch treibende Kraft dafür, dass Mapper großflächig Daten beisteuern und vor allem korrigieren; notfalls korrigieren in dem Sinne, dass [Anwendung X] dann wieder funktioniert. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-it] Spam nei nomi?
On Sun, Jan 12, 2014 at 10:38 PM, Daniele Forsi dfo...@gmail.com wrote: Nelle pagine di Groppo sono saltati fuori questi nomi: Marche Valore Link Sentiero*Frontignano-Visso*(in*parte*303)*-**WWW.CAMOSCIOSIBILLINI.IT WWW.CAMOSCIOSIBILLINI.IT*-**AQUILA*REALE WWW.CAMOSCIOSIBILLINI.IT*-**CAMOSCI WWW.CAMOSCIOSIBILLINI.IT*-**CAMOSCI WWW.CAMOSCIOSIBILLINI.IT*-**CAMOSCI WWW.CAMOSCIOSIBILLINI.IT*-**CAMOSCI WWW.CAMOSCIOSIBILLINI.IT*-**CAMOSCI*INVERNO WWW.CAMOSCIOSIBILLINI.IT*-**CASCATE*DELLE*CALLARELLE WWW.CAMOSCIOSIBILLINI.IT*-**CERVI WWW.CAMOSCIOSIBILLINI.IT*-**CERVO il primo di questi nomi è sulla way 128180628 e potrebbe anche essere passabile se fosse su una proprietà privata (ma non lo so), ma gli altri... Ho fatto questa query con http://overpass-turbo.eu/ per ottenere tutti i nomi che contengono CAMOSCIOSIBILLINI: osm-script union query type=node area-query ref=3600053060/ has-kv k=name regv=.*CAMOSCIOSIBILLINI.*/ /query query type=way area-query ref=3600053060 / has-kv k=name regv=.*CAMOSCIOSIBILLINI.*/ /query item/ recurse type=down/ /union print mode=meta / /osm-script Da qui ho visto che le modifiche sono tutte state fatte da questo utente che si è registrato 6 giorni fa: http://www.openstreetmap.org/user/Il%20Camoscio%20dei%20Sibillini Anche il tagging che usa è allucinante. Alcuni esempi: Place=hamlet; name=WWW.CAMOSCIOSIBILLINI.IT highway=path; name=WWW.CAMOSCIOSIBILLINI.IT; ref=WWW.CAMOSCIOSIBILLINI.IT C'è qualcuno in zona che lo può contattare? Ciao, Andrea. ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] R: Nomi in sardo reloaded
Il 10/01/2014 20:48, Francesco Pelullo ha scritto: Allora per quale motivo insistere ad usare name=? Eliminiamolo del tutto. Sarei favorevole, ma per ora non si può (sempre per colpa del rendering). Il 11/01/2014 01:01, Luca Meloni ha scritto: Comunque per le statistiche cito wikipedia che cita uno studio della regione: https://it.wikipedia.org/wiki/Lingua_sarda#Distribuzione_geografica http://www.sardegnacultura.it/documenti/7_88_20070514130939.pdf Molto interessante, grazie per il link. Il 12/01/2014 16:25, THC ha scritto: La versione base rispecchia qual'è il toponimo d'uso comune, il toponimo ufficiale, il toponimo impiegato nel territorio dalla popolazione, il toponimo col quale la comunità si fa conoscere altrove: non lo nasconde, non lo mette per secondo, non lo fonde creandone di nuovi. Non mi pare che il toponimo italiano sia nascosto. E nemmeno che sia stato fuso all'altro per crearne uno nuovo. La sbarra è semplicemente un artificio per far visualizzare entrambi i nomi ufficiali. In tutta Italia la gente allora dovrebbe parlare napoletano e lombardo come prima lingua, ma non vedo nessun Napule/Napoli e Milan/Milano, Turin/Torino: ma cos'è questo trionfo della non-neutralità e dell'arbitrio? La questione è molto semplice, il sardo, a differenza di molti altri idiomi locali, è tutelato e riconosciuto da una legge dello stato. E questo, in combinazione con le leggi della regione autonoma, rende possibile questa disparità di trattamento. Per quanto riguarda gli idiomi non riconosciuti dalla legge statale ma tutelati da quella regionale (gallurese, tabarchino etc) la cosa andrebbe discussa. Perché anche altre regioni tutelano i loro idiomi locali non tutelati dallo stato e allora si che si potrebbe lamentare una differenza di trattamento tra la Gallura e la tal zona del continente (fermo restando la questione che una tutela in una regione a statuto autonomo ha un valore legale diverso da quella in una regione ordinaria)... Peccato che sia meno rilevante del toponimo in italiano, quindi non può venire prima. Peccato che in certi casi è talmente irrelevante da non essere nemmeno usato e nemmeno adottato ufficialmente. Quindi cosa si sta ripentendo all'infinito: che è meno rilevante del toponimo ufficiale in italiano ma l'abbiamo messo prima perché sì La convenzione adottata nel Sud Tirolo è quella di mettere per primo il toponimo nell'idioma parlato dalla maggioranza dei residenti del comune. E mi sembra di capire che nel caso sardo si sia seguito questa convenzione per uniformità... Nel caso tirolese però siamo in presenza di tre comunità linguistiche distinte, mentre nel caso sardo la comunità sardofona e quella italofona più o meno coincidono. Dunque a mio avviso ci dovrebbe essere un trattamento diverso, ovvero andrebbe messo per primo il toponimo più conosciuto. Sì, visto che molti non hanno deliberato. Sì, visto che province e frazioni manco hanno deliberato dei toponimi inventati che sono stati inseriti ugualmente. Sì, visto che tutti usano il toponimo italiano come toponimo principale. Anche se le amministrazioni non han deliberato si tratta comunque di toponimi in uso, e vanno comunque riportati (almeno sul tag name:lang=*). Certo si potrebbe discutere sull'opportunità di metterli sul tag name... Ecco, magari si potrebbe dire che può essere messo sul tag name solo quando è ufficiale. ciao Paolo M ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Pedestrian routing, oneway, turnstile
Siamo sicuri che il routing fa accedere macchine in way pedestrian? On lun 13 gen 2014 08:35:27 CET, Fabri erfab...@gmail.com wrote: On lun 13 gen 2014 01:22:39 CET, Martin Koppenhoefer dieterdre...@gmail.com wrote: 2014/1/10 Fabri erfab...@gmail.com Per un footway dovrebbe essere palese che se c'è un oneway=yes si può accedere solo in un senso. forse per un footway si (al meno che non abbia altri tags e quindi il tag non era pensato per i pedoni). Purtroppo per le pedestrian è una cosa abbastanza comune di avere un oneway=yes (per le macchine) che deve essere ignorato per pedoni per avere un routing sensato. ciao, Martin caso particolare in cui macchine autorizzate ad accedere in area pedonale? oneway:motor_vehicle=yes oneway:foot=no ? ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] WMS Piemonte
Ciao a tutti..ho trovato questi WMS forniti dalla Regione Piemonte con licenza CC-BY 2.5 che potrebbero essere molto utili.Posso utilizzarli come base per un ricalco? Tiziano ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] relazione ss27
Ho ricevuto in un contesto diverso una segnaletica sulla relazione della ss27 che passo alla lista perché non conosco la zona: the main SS27 relation (Aosta-Great St Bernard Pass) contains many ways from multiple sections of old_ref=SS27, but does NOT include ways on the recently built SS27 Gignod village bypass variante di Gignod. Instead the old route through the village is maintained in the main SS27 relation. Meanwhile the new SS 27 Gignod bypass (just 2.8 km in length) has its own relation, even though it looks and feels like an integral part of SS27 when you drive it. In effect the main SS 27 relation is an historical document (which is fine, but this probably means it couldn't be used by the mapping and info systems that we have been discussing here) Grazie a Peter Davies per la segnalazione Volker ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] R: Nomi in sardo reloaded
Quote// Certo si potrebbe discutere sull'opportunità di metterli sul tag name... Ecco, magari si potrebbe dire che può essere messo sul tag name solo quando è ufficiale. +1 Francesca Il 13/gen/2014 10:41 Paolo Monegato gato.selvad...@gmail.com ha scritto: Il 10/01/2014 20:48, Francesco Pelullo ha scritto: Allora per quale motivo insistere ad usare name=? Eliminiamolo del tutto. Sarei favorevole, ma per ora non si può (sempre per colpa del rendering). Il 11/01/2014 01:01, Luca Meloni ha scritto: Comunque per le statistiche cito wikipedia che cita uno studio della regione: https://it.wikipedia.org/wiki/Lingua_sarda#Distribuzione_geografica http://www.sardegnacultura.it/documenti/7_88_20070514130939.pdf Molto interessante, grazie per il link. Il 12/01/2014 16:25, THC ha scritto: La versione base rispecchia qual'è il toponimo d'uso comune, il toponimo ufficiale, il toponimo impiegato nel territorio dalla popolazione, il toponimo col quale la comunità si fa conoscere altrove: non lo nasconde, non lo mette per secondo, non lo fonde creandone di nuovi. Non mi pare che il toponimo italiano sia nascosto. E nemmeno che sia stato fuso all'altro per crearne uno nuovo. La sbarra è semplicemente un artificio per far visualizzare entrambi i nomi ufficiali. In tutta Italia la gente allora dovrebbe parlare napoletano e lombardo come prima lingua, ma non vedo nessun Napule/Napoli e Milan/Milano, Turin/Torino: ma cos'è questo trionfo della non-neutralità e dell'arbitrio? La questione è molto semplice, il sardo, a differenza di molti altri idiomi locali, è tutelato e riconosciuto da una legge dello stato. E questo, in combinazione con le leggi della regione autonoma, rende possibile questa disparità di trattamento. Per quanto riguarda gli idiomi non riconosciuti dalla legge statale ma tutelati da quella regionale (gallurese, tabarchino etc) la cosa andrebbe discussa. Perché anche altre regioni tutelano i loro idiomi locali non tutelati dallo stato e allora si che si potrebbe lamentare una differenza di trattamento tra la Gallura e la tal zona del continente (fermo restando la questione che una tutela in una regione a statuto autonomo ha un valore legale diverso da quella in una regione ordinaria)... Peccato che sia meno rilevante del toponimo in italiano, quindi non può venire prima. Peccato che in certi casi è talmente irrelevante da non essere nemmeno usato e nemmeno adottato ufficialmente. Quindi cosa si sta ripentendo all'infinito: che è meno rilevante del toponimo ufficiale in italiano ma l'abbiamo messo prima perché sì La convenzione adottata nel Sud Tirolo è quella di mettere per primo il toponimo nell'idioma parlato dalla maggioranza dei residenti del comune. E mi sembra di capire che nel caso sardo si sia seguito questa convenzione per uniformità... Nel caso tirolese però siamo in presenza di tre comunità linguistiche distinte, mentre nel caso sardo la comunità sardofona e quella italofona più o meno coincidono. Dunque a mio avviso ci dovrebbe essere un trattamento diverso, ovvero andrebbe messo per primo il toponimo più conosciuto. Sì, visto che molti non hanno deliberato. Sì, visto che province e frazioni manco hanno deliberato dei toponimi inventati che sono stati inseriti ugualmente. Sì, visto che tutti usano il toponimo italiano come toponimo principale. Anche se le amministrazioni non han deliberato si tratta comunque di toponimi in uso, e vanno comunque riportati (almeno sul tag name:lang=*). Certo si potrebbe discutere sull'opportunità di metterli sul tag name... Ecco, magari si potrebbe dire che può essere messo sul tag name solo quando è ufficiale. ciao Paolo M ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] WMS Piemonte
Tiziano Gedda ha scritto: ho trovato questi http://www.geoportale.piemonte.it/cms/index.php?option=com_contentview=articleid=55Itemid=73lang=it WMS forniti dalla Regione Piemonte con licenza CC-BY 2.5 che potrebbero essere molto utili. Posso utilizzarli come base per un ricalco? Sono molto molto interessanti (grazie!) e piacerebbe poterli usare anche a me, ma purtroppo continuo a non capirci nulla di licenze... ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] R: Re: WMS Piemonte
questa pagina è in italiano http://creativecommons.org/licenses/by/2.5/it/ Messaggio originale Da: solit...@mail.com Data: 13-gen-2014 15.31 A: talk-it@openstreetmap.org Ogg: Re: [Talk-it] WMS Piemonte Tiziano Gedda ha scritto: ho trovato questi http://www.geoportale.piemonte.it/cms/index.php?option=com_contentamp;view=articleamp;id=55amp;Itemid=73amp;lang=it WMS forniti dalla Regione Piemonte con licenza CC-BY 2.5 che potrebbero essere molto utili. Posso utilizzarli come base per un ricalco? Sono molto molto interessanti (grazie!) e piacerebbe poterli usare anche a me, ma purtroppo continuo a non capirci nulla di licenze... ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] R: Re: WMS Piemonte
Gianluca Boero ha scritto: questa pagina è in italiano http://creativecommons.org/licenses/by/2.5/it/ Come si fa a attribuire la paternità del materiale dopo aver ricalcato un'ortofoto per creare, per esempio, un edificio? Dobbiamo concludere che *non* è possibile utilizzare questi servizi? ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Pedestrian routing, oneway, turnstile
Dipende come è stato programma il software di routing. In teoria se la way ha solo il tag highway=pedestrian dovrebbe permettere solo il routing pedonale. Mentre se è presente il tag motor_vehicle=yes dovrebbe consentire anche il transito delle autovetture, ma ripeto, dipende dal software se sa interpretare il tag motor_vehicle Davide - Davide -- View this message in context: http://gis.19327.n5.nabble.com/Pedestrian-routing-oneway-turnstile-tp5792290p5792867.html Sent from the Italy General mailing list archive at Nabble.com. ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] WMS Piemonte
Puoi usarli. 2014/1/13 Tiziano Gedda dufou...@libero.it: Ciao a tutti.. ho trovato questi WMS forniti dalla Regione Piemonte con licenza CC-BY 2.5 che potrebbero essere molto utili. Posso utilizzarli come base per un ricalco? Tiziano ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it -- Maurizio Napo Napolitano http://de.straba.us ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Spam nei nomi?
2014/1/13 Andrea Musuruane musur...@gmail.com Anche il tagging che usa è allucinante. Alcuni esempi: Place=hamlet; name=WWW.CAMOSCIOSIBILLINI.IT highway=path; name=WWW.CAMOSCIOSIBILLINI.IT; ref=WWW.CAMOSCIOSIBILLINI.IT C'è qualcuno in zona che lo può contattare? ho rivertato le sue edits (tolto a mano lo spam). Pare che l'utente mcheckimport aveva già corretto qualche way e scritto all'utente. Qualcuno ha risposto? ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] WMS Piemonte
Grazie della risposta ”Napo”..sono contento di poterli usare..ci saranno sicuramente utili.. Una domanda: come, cosa e dove metto per indicare la source dei dati? Tiziano ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] WMS Piemonte
2014/1/13 Tiziano Gedda dufou...@libero.it Grazie della risposta ”Napo”..sono contento di poterli usare..ci saranno sicuramente utili.. Una domanda: come, cosa e dove metto per indicare la source dei dati? in realtà non è così chiaro come dice Napo, al solito cerchiamo di chiarire con il proprietario come citare la fonte (cerchiamo di autorizzarci di avere la fonte soltanto nel changeset e/o nel wiki). La cc-by non è chiara nel merito, quindi non è sufficiente. Ad ogni modo qualsiasi dato importato con una licenza con vincoli ci lega di più rispetto ad un possibile cambio di licenza in futuro come previsto dai Contributor Terms. ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Pedestrian routing, oneway, turnstile
2014/1/13 Fabri erfab...@gmail.com Siamo sicuri che il routing fa accedere macchine in way pedestrian? dipende dal programma di routing e dalla situazione (eccezioni mappati, ecc.). Un programma ottimale con una mappatura ottimale dovrebbe farti accedere in certi casi (per esempio delivery, emergency, ecc.) ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Pedestrian routing, oneway, turnstile
Sono d'accordo. Credo infatti che per migliorare il routing in osm ci sia bisogno di interpretare le diverse combinazioni di tag per avere un risultato diverso in base al tipo di veicolo. Sia per accesso veicolo=yes/no ; che per sensi di marcia. Magari farei richiesta di implementare oneway:veicolo=no ps:in futuro anche tener conto degli orari in cui è consentito accedere...del tag conditional...insomma la strada è ancora lunga... On lun 13 gen 2014 16:01:44 CET, Davio davide@gmail.com wrote: Dipende come è stato programma il software di routing. In teoria se la way ha solo il tag highway=pedestrian dovrebbe permettere solo il routing pedonale. Mentre se è presente il tag motor_vehicle=yes dovrebbe consentire anche il transito delle autovetture, ma ripeto, dipende dal software se sa interpretare il tag motor_vehicle Davide - Davide -- View this message in context: http://gis.19327.n5.nabble.com/Pedestrian-routing-oneway-turnstile-tp5792290p5792867.html Sent from the Italy General mailing list archive at Nabble.com. ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] Priorità numeri civici
Oramai abbiamo mappato una buona parte dei civici del paesiello, ma mi sono imbattuto in una interessante meta-informazione (e come tale non credo possa essere soggetta a vincoli proprietari) da tuttocittà.ithttp://xn--tuttocitt-y1a.it: una ricerca qualsiasi produce anche un footer con le strade più cercate; vista la popolarità del sito, credo che possa esser utile per darsi una priorità nell'attività di mappatura dei numeri civici. ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
[Talk-dk] Til orientering - ny JOSM version 6502 og Geodatastyrelsens luftfotos
Hej alle sammen Hvis du installerer den nye nye JOSM version 6502 http://josm.openstreetmap.de/ Så når du redigerer i Danmark, vil du i JOSM under Billedlag nu have muligheden for at vælge Geodatastyrelsen (Denmark) luftfotos direkte. Det er den mapproxy service som Gregers Petersen for et par uger siden satte op som nu optræder som et standardvalg til den nye JOSM version. NB - Hvis du bruger iD Læs guide her til Geodatastyrelsens luftfotos http://www.microformats.dk/2014/01/02/mapproxy-tjenesten-af-geodatastyrelsens-luftfotos-virker-ogsa-til-id-editoren/ eller Potlatch 2 så læs her http://www.microformats.dk/2013/12/24/openstreetmap-potlatch-2-editor-kan-nu-ogsa-kalde-geodatastyrelsens-luftfotos/ vh Søren Johannessen ___ Talk-dk mailing list Talk-dk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-dk
Re: [Talk-dk] Til orientering - ny JOSM version 6502 og Geodatastyrelsens luftfotos
Hejsa Jeg kører altid den nyeste udviklingsversion (som nu er 6673) og synes ikke jeg kan se det. Hvordan kommer jeg til det uden at ødelægge min nuværende konfiguration? Mvh Michael Andersen Mandag den 13. januar 2014 20:51:41 skrev Soren Johannessen: Hej alle sammen Hvis du installerer den nye nye JOSM version 6502 http://josm.openstreetmap.de/ Så når du redigerer i Danmark, vil du i JOSM under Billedlag nu have muligheden for at vælge Geodatastyrelsen (Denmark) luftfotos direkte. Det er den mapproxy service som Gregers Petersen for et par uger siden satte op som nu optræder som et standardvalg til den nye JOSM version. NB - Hvis du bruger iD Læs guide her til Geodatastyrelsens luftfotos http://www.microformats.dk/2014/01/02/mapproxy-tjenesten-af-geodatastyrelsen s-luftfotos-virker-ogsa-til-id-editoren/ eller Potlatch 2 så læs her http://www.microformats.dk/2013/12/24/openstreetmap-potlatch-2-editor-kan-nu -ogsa-kalde-geodatastyrelsens-luftfotos/ vh Søren Johannessen ___ Talk-dk mailing list Talk-dk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-dk ___ Talk-dk mailing list Talk-dk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-dk
Re: [Talk-dk] Til orientering - ny JOSM version 6502 og Geodatastyrelsens luftfotos
Hej Søren Nej, jeg kan stadig ikke se den. Jeg er formentlig nød til at slette min konfig fil for at få den opdateret og derefter bruge lidt tid på mine personlige preferencer igen. Suk. Mandag den 13. januar 2014 22:18:10 skrev Soren Johannessen: Hej Michael Under Rediger Indstillinger WMS/TMS og på standardlisten ser du så det samme som i vedhæftet billede i din JOSM udvikler ? scroll lidt ned og ser om ikke er der under DK og så Geodatastyrelsen (Denmark) - Hvis ja - så skulle den være automatisk på listen under Billedelag når du har vektor indhold fra Danmark inde - /Søren 2014/1/13 Michael Andersen hj...@milvus.dk: Hejsa Jeg kører altid den nyeste udviklingsversion (som nu er 6673) og synes ikke jeg kan se det. Hvordan kommer jeg til det uden at ødelægge min nuværende konfiguration? Mvh Michael Andersen Mandag den 13. januar 2014 20:51:41 skrev Soren Johannessen: Hej alle sammen Hvis du installerer den nye nye JOSM version 6502 http://josm.openstreetmap.de/ Så når du redigerer i Danmark, vil du i JOSM under Billedlag nu have muligheden for at vælge Geodatastyrelsen (Denmark) luftfotos direkte. Det er den mapproxy service som Gregers Petersen for et par uger siden satte op som nu optræder som et standardvalg til den nye JOSM version. NB - Hvis du bruger iD Læs guide her til Geodatastyrelsens luftfotos http://www.microformats.dk/2014/01/02/mapproxy-tjenesten-af-geodatastyrel sen s-luftfotos-virker-ogsa-til-id-editoren/ eller Potlatch 2 så læs her http://www.microformats.dk/2013/12/24/openstreetmap-potlatch-2-editor-kan -nu -ogsa-kalde-geodatastyrelsens-luftfotos/ vh Søren Johannessen ___ Talk-dk mailing list Talk-dk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-dk ___ Talk-dk mailing list Talk-dk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-dk ___ Talk-dk mailing list Talk-dk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-dk
[Talk-dk] Stavefejl i den danske oversættelse på OSMs forside
Hej Nu fik jeg lige øje på det igen (se vedlagte billedfil). Den slags ser ikke lige så professionelt ud (Ikke at vi nødvendigvis skal give indtryk af at være professionelle, men alligevel...), så hvordan bærer man sig ad med at rette det? Mvh Michaelfilen øjebliksbillede1.png: Originale billeder: øjebliksbillede1.png attachment: image/png___ Talk-dk mailing list Talk-dk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-dk
[Talk-ar] (sin asunto)
Finalmente han anunciado a Buenos Aires como sede del SotM 2014 global.[1] Felicitaciones a todo el equipo de organización y a los geoinquietos! Nos vemos en el trello[2] y pronto armamos un hangouts y reunión. [1] http://blog.openstreetmap.org/2014/01/12/buenos-aires-hosts-sotm14 [2] https://trello.com/b/uzTbNlvW/state-of-the-map-2014 ___ Talk-ar mailing list Talk-ar@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ar
Re: [Talk-ar] (sin asunto)
Abrazos y fuerza desde Chile! :) 2014/1/13 cor...@fernando.com.ar Finalmente han anunciado a Buenos Aires como sede del SotM 2014 global.[1] Felicitaciones a todo el equipo de organización y a los geoinquietos! Nos vemos en el trello[2] y pronto armamos un hangouts y reunión. [1] http://blog.openstreetmap.org/2014/01/12/buenos-aires-hosts-sotm14 [2] https://trello.com/b/uzTbNlvW/state-of-the-map-2014 ___ Talk-ar mailing list Talk-ar@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ar -- Ing. Marcelo Aliaga Quezada marc...@aliaga.cl ___ Talk-ar mailing list Talk-ar@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ar
[Talk-at] Relation in Kärnten
Ich habe in Kärnten eine Relation gefunden (http://www.openstreetmap.org/relation/2562011) bei der ich die Hilfe der Talk-Liste brauche. Macht es Sinn so ein grosses Gebiet mit einer Relation zusammenzufassen und erst im zweiten Schritt sämtliche Flächen darin, die nicht Wald sind, herauszunehmen? Ich finde das keine gute Idee, aber lasse mich gerne belehren. ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
[Talk-at] Baumstämme quer über den Weg
Hallo! Bei einer Wanderung heute Nachmittag bin ich an eine Wegstelle gekommen, wo ein Baum (Sturmschaden, abgebrochen) quer über dem Weg war. Die Wanderer haben mittlerweile schon einen Ersatzweg rund herum getrampelt. Irgendwann wird der Baumstamm sicher weg geräumt. Frage: Soll in so einem Fall trotzdem die Wegführung geändert werden und/oder eine Barriere eingezeichnet werden? Wenn Barriere ja, dann welche? LG, Christian ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Baumstämme quer über den Weg
On 13.01.2014 19:33, Christian Aigner wrote: Bei einer Wanderung heute Nachmittag bin ich an eine Wegstelle gekommen, wo ein Baum (Sturmschaden, abgebrochen) quer über dem Weg war. Die Wanderer haben mittlerweile schon einen Ersatzweg rund herum getrampelt. Irgendwann wird der Baumstamm sicher weg geräumt. Kommt darauf an wo. Um manche Wege, besonders im Hochgebirge, kümmern sich Wegemacher. Die räumen Hindernisse (Steine, Bäume) beiseite, beheben Erosionsschäden bzw. verlegen Wege so, dass künftig weniger Schäden auftreten. Es gibt aber auch viele Wege, um die sich keiner kümmert, oder nur ein Markierungswart, dem das Wegräumen von Hindernissen zu mühsam ist. Dort klettert man entweder übern Baumstamm drüber, oder (wenn noch zu viele Äste dran sind) man umgeht ihn. Auf der Hohen Wand kenne ich mindestens 2 Stellen, wo die Umgehungen umgestürzter Bäume sogar markiert wurden. Frage: Soll in so einem Fall trotzdem die Wegführung geändert werden und/oder eine Barriere eingezeichnet werden? Wenn Barriere ja, dann welche? Wenn du glaubst, dass es nur vorübergehend ist, dann tu dir keine Mühe an. Vor allem weil die Mühe eine doppelte ist: Es muss nachher jemand zurückändern. In Fällen, wo der Baum liegen bleibt, mappe ich ihn mitunter als barrier=log und/oder ich mappe den neuen Wegverlauf. Das hängt halt von der konkreten Situation ab und von der Lust auf Micromapping. So ein umgefallener Baum kann in einer Karte durchaus interessant sein, z.B. als Orientierungspunkt. Oder für Leute mit Kinderwagen als Kriterium, doch lieber die Alternativroute zu nehmen. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Baumstämme quer über den Weg
On 13.01.14 19:33, Christian Aigner wrote: Frage: Soll in so einem Fall trotzdem die Wegführung geändert werden und/oder eine Barriere eingezeichnet werden? Wenn Barriere ja, dann welche? Wenn Du die Chance hast, das mitzukriegen, sobald der Baumstamm wieder entfernt wurde, dann würde ich eine barrier=log machen. Servus, Andreas ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
[Talk-ro] Raportul anual OpenStreetMap Romania 2013
97% din totalul de Drumuri Nationale sunt adaugate in OpenStreetMap 89 % din totalul de Drumurile Judetene sunt adaugate in OpenStreetMap 28% din totalul de Drumuri Comunale sunt adaugate in OpenStreetMap 195,000 de kilometri de drumuri sunt adaugate in OSM, dintre care 73,000 au fost adaugati in anul 2013 231,991 - Numarul de cladiri existente in OpenStreetMap. 47 % din ele fiind adaugate in anul 2013 Mai multe statistici se pot gasi pe pagina de facebook OpenStreetMap Romaniahttps://www.facebook.com/OsmRomania https://www.facebook.com/OsmRomania/posts/263084250516429?stream_ref=10 O zi buna, Badita Florin ___ Talk-ro mailing list Talk-ro@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ro
Re: [Talk-ro] Raportul anual OpenStreetMap Romania 2013
Deci anul 2013 a fost cel mai activ din multe puncte de evdere :D Acum, problema drumurilor comunale si a celor judetene este ca, sunt desenate mult mai multe, dar nu sunt marcate ca atare, nu au ref toate... On 13.01.2014 15:53, Badita Florin wrote: 97% din totalul de Drumuri Nationale sunt adaugate in OpenStreetMap 89 % din totalul de Drumurile Judetene sunt adaugate in OpenStreetMap 28% din totalul de Drumuri Comunale sunt adaugate in OpenStreetMap 195,000 de kilometri de drumuri sunt adaugate in OSM, dintre care 73,000 au fost adaugati in anul 2013 231,991 - Numarul de cladiri existente in OpenStreetMap. 47 % din ele fiind adaugate in anul 2013 Mai multe statistici se pot gasi pe pagina de facebook OpenStreetMap Romania https://www.facebook.com/OsmRomania https://www.facebook.com/OsmRomania/posts/263084250516429?stream_ref=10 O zi buna, Badita Florin ___ Talk-ro mailing list Talk-ro@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ro ___ Talk-ro mailing list Talk-ro@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ro
[Talk-cz] Preklad wiki MapFeatures
Ahoj, pustil jsem se do prekladu wiki http://wiki.openstreetmap.org/wiki/Cs:Map_Features Puvodni preklad uz byl proveden docela davno a postupem casu toho hodne chybelo, nebo nektere veci byly uz i zavadejici a nepravdive. Cilem bylo i krome otrockeho prekladu zohlednit nekde i ceska specifika, pripadne doplnit nejcastejsi useful combination tagy, ktere by sice idealne mely byt popsane v ceskych prekladech jednotlivych tagu, ale ty nejsou a asi hned tak nebudou. Tedy je to misty ukecane, ale snad k dobru veci. Zatim jsem prosel: - highway - barrier - cycleway - tracktype - waterway - railway - aeroway - aerialway - power - man made - leisure - amenity Byl bych rad, kdyby si to nekdo mohl precist a pripadne mi vytknout, co jsem napsal spatne, nebo doplnit dalsi informace, ktere me nenapadly. Zdravi, Dalibor ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
[Talk-cz] iD editor a mapový podklad ČÚZK ortofoto
Dobrý den. S nadšením jsem udělal pár editací OSM (stále se učím jak to dělat kvalitně a správně). Používám pro editaci webový iD editor, který je dostupný všude a bez instalace (i když na Atomu je trochu pomalý). Co mne v tomto editoru chybí je přímá volba lepších leteckých podkladů. Podklad Bing aerial pokud je dostupný tak je mdlý a hlavně posunutý (alespoň tam, kde jsem se v ČR díval). Slušné letecké mapy jsou k dispozici u ČUZK. Například z WMS mapové služby: http://geoportal.cuzk.cz/WMS_ORTOFOTO_PUB/WMService.aspx?service=WMSrequest=getCapabilities lze (technicky) (při vhodných volbách) získat mapové dlaždice ve stylu OSM. K dispozici je přímo i dlaždicová služba WMTS viz: http://geoportal.cuzk.cz/WMTS_ORTOFOTO/WMTService.aspx?service=WMTSrequest=GetCapabilities Ale ta kupodivu se jeví méně kvalitní než služba WMS a dokonce i pomalejší a asi je i méně aktuální. Ve webovém editoru iD pokud zadám mapový podklad Vlastní a vložím url: http://geoportal.cuzk.cz/WMTS_ORTOFOTO_900913/service.svc/get?SERVICE=WMTSREQUEST=GetTileVERSION=1.0.0LAYER=ortoSTYLE=defaultTILEMATRIXSET=googlemapscompatibleext2:epsg:3857TILEMATRIX={z}TILECOL={x}TILEROW={y}FORMAT=image%2Fjpg tak to funguje (někdy), ale velmi pomalu. Mé dotazy: Je možné (legální) využívat letecké mapy, které na uvedených službách ČUZK poskytuje pro editaci OSM map? Co je třeba udělat (kam se obrátit), aby v oblasti ČR byla ve webovém iD editoru nabízena přímo ČUZK letecká mapa? Existují nějaké další mapové podklady ČR a s nimi spojené služby, které by se daly využít jako podklad pro editaci OSM map a které by bylo možné přímo doplnit v iD editoru do výběru vrstev? Mít kvalitní podklad pro editaci map OSM na území ČR přímo ve webovém iD editoru by bylo úžasné... Zdraví Marek Chlup ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] iD editor a mapový podklad ČÚZK ortofoto
Ahoj Marku, On Mon 13-01-14 15:18:27, Marek Chlup wrote: Mé dotazy: Je možné (legální) využívat letecké mapy, které na uvedených službách ČUZK poskytuje pro editaci OSM map? Nikoli. Viz http://wiki.openstreetmap.org/wiki/WikiProject_Czech_Republic/freemap#Ov.C4.9B.C5.99ovac.C3.AD_zdroje Co je třeba udělat (kam se obrátit), aby v oblasti ČR byla ve webovém iD editoru nabízena přímo ČUZK letecká mapa? Jak tomu rozumím, především svolení vlastníka s použitím ortofota v OSM. Myslím, že nějaké pokusy o získání souhlasu byly, podívej se do archivu konference. HTH, Libor ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] iD editor a mapový podklad ČÚZK ortofoto
Děkuji za odpověď. ČÚZK u ORTOFOTO odkazuje pokud jde o podmínky poskytování (a i užití) na dokument: http://geoportal.cuzk.cz/Dokumenty/Podminky_sluzby_CUZK.pdf ten pak zmiňuje například vyhlášku č. 103/2010 Sb.: http://inspire.gov.cz/sites/default/files/documents/103_2010.pdf Chvíli jsem si to pročítal, ale kolize s licencí ODbL se mi těžko posuzují (přiznám se, že i ODbL nechápu detailně)... Každopádně děkuji za odkaz na wiki. Díval jsem se zejména na WMS katastrální mapy, které jsou hodnoceny jako zdroj dat v pořádku. Na některé záležitosti jde i o lepší zdroj než ORTOFOTO. Tedy velmi bych přivítal, kdyby bylo možné v iD editoru na openstreetmap.org vybrat přímo vrstvu ČÚZK Katastrální mapy. Kam se s takovou prosbou dá vhodně obrátit (aby to bylo zakomponováno do nabídky iD editoru)? Zdraví Marek Chlup On Mon, Jan 13, 2014 at 03:42:51PM +0100, Libor Pechacek wrote: Ahoj Marku, On Mon 13-01-14 15:18:27, Marek Chlup wrote: Mé dotazy: Je možné (legální) využívat letecké mapy, které na uvedených službách ČUZK poskytuje pro editaci OSM map? Nikoli. Viz http://wiki.openstreetmap.org/wiki/WikiProject_Czech_Republic/freemap#Ov.C4.9B.C5.99ovac.C3.AD_zdroje Co je třeba udělat (kam se obrátit), aby v oblasti ČR byla ve webovém iD editoru nabízena přímo ČUZK letecká mapa? Jak tomu rozumím, především svolení vlastníka s použitím ortofota v OSM. Myslím, že nějaké pokusy o získání souhlasu byly, podívej se do archivu konference. HTH, Libor ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] iD editor a mapový podklad ČÚZK ortofoto
Ahoj, myslím, že nejlíp přes databázi podkladů, které iD používá: https://github.com/osmlab/editor-imagery-index Honza Vršovský -- Původní zpráva -- Od: Marek Chlup m...@chlup.net Datum: 13. 1. 2014 Předmět: Re: [Talk-cz] iD editor a mapový podklad ČÚZK ortofoto Děkuji za odpověď. ČÚZK u ORTOFOTO odkazuje pokud jde o podmínky poskytování (a i užití) na dokument: http://geoportal.cuzk.cz/Dokumenty/Podminky_sluzby_CUZK.pdf ten pak zmiňuje například vyhlášku č. 103/2010 Sb.: http://inspire.gov.cz/sites/default/files/documents/103_2010.pdf Chvíli jsem si to pročítal, ale kolize s licencí ODbL se mi těžko posuzují (přiznám se, že i ODbL nechápu detailně)... Každopádně děkuji za odkaz na wiki. Díval jsem se zejména na WMS katastrální mapy, které jsou hodnoceny jako zdroj dat v pořádku. Na některé záležitosti jde i o lepší zdroj než ORTOFOTO. Tedy velmi bych přivítal, kdyby bylo možné v iD editoru na openstreetmap.org vybrat přímo vrstvu ČÚZK Katastrální mapy. Kam se s takovou prosbou dá vhodně obrátit (aby to bylo zakomponováno do nabídky iD editoru)? Zdraví Marek Chlup On Mon, Jan 13, 2014 at 03:42:51PM +0100, Libor Pechacek wrote: Ahoj Marku, On Mon 13-01-14 15:18:27, Marek Chlup wrote: Mé dotazy: Je možné (legální) využívat letecké mapy, které na uvedených službách ČUZK poskytuje pro editaci OSM map? Nikoli. Viz http://wiki.openstreetmap.org/wiki/WikiProject_Czech_Republic/ freemap#Ov.C4.9B.C5.99ovac.C3.AD_zdroje Co je třeba udělat (kam se obrátit), aby v oblasti ČR byla ve webovém iD editoru nabízena přímo ČUZK letecká mapa? Jak tomu rozumím, především svolení vlastníka s použitím ortofota v OSM. Myslím, že nějaké pokusy o získání souhlasu byly, podívej se do archivu konference. HTH, Libor ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz;___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] RUIAN nad OSM
Také všechny zdravím, Dne Po 13. ledna 2014 07:53:55, JV napsal(a): Zdravím všechny, ad artefakty - to není chyba, ale zcela legální stav. Je potřeba si uvědomit, že katastrální mapa *není* technická mapa a že do 31.12.2013 budova a pozemek pod ní byly dvě nemovitosti (a u nemovitostí, existujících před 1.1.2014 to bude i nadále, pokud se vlastnické poměry liší - velice rozumím, že katastrální mapa je mapa právní a že tedy neodráží realitu, ale právní stav. Opakovaně narážím na stav (RUIAN), o kterém si myslím, že nikdy nebyl stavem skutečným ani stavem právním. Je to v případech, kdy leží třeba 3 budovy na sobě https://ruian.poloha.net/20/50.08934/14.46915 - rozsviťte si overlay budov a je to dokonce vidět, jak ta překryvná vrstva má jinou barvu na budově Biskupcova 347/12. Biskupcova 14 a 16 ovšem chybí. Tedy nechybí, ale leží na Biskupcově 12. To není zdaleka jediný případ. Tento konkrétní případ vypadá v RUIAN takto: kod| budova_id | cisla_domovni --+---+--- 21695270 | 884184101 | {347} 21695547 | 884184101 | {382} 21696519 | 884184101 | {501} Zrovna tyto případy není nutné složitě hledat; postačil by vhodně zvolený dotaz do databáze. Dalším ne zcela vzácným jevem je výskyt budovy na místě vnitrobloku: https://ruian.poloha.net/20/50.08313/14.42040 přičemž v místě, kde budova má být, tak není. Vypadá to na nějakou zavlečenou chybu, nevím. Mohu třeba tyto výskyty někam hlásit, pokud by to mělo skutečně smysl. -- Petr zjednodušeně řečeno). Zrovna v těch Pardubicích to znamená, že budova je Ministerstva obrany (http://vdp.cuzk.cz/vdp/ruian/stavebniobjekty/46757481; - tlačítko Údaje o vlastnictví otevře Nahlížení do KN se zvýrazněným obvodem budovy), ale pozemky pod ní jsou částečně i města (to je ten hnusný artefakt). Netvrdím, že v katastru nejsou chyby - ale vždy je mít na paměti výše uvedené a že katastr eviduje *právní* stav. Tedy pokud v terénu již nějaká budova není, může se v katastru i nadále zobrazovat, protože nikdo tu změnu neohlásil. A aby to bylo ještě složitější, zrovna cesta k odstranění budovy začíná na stavebním úřadu a teprve následně je možné to oznámit katastru. J. Veselý -- Původní zpráva -- Od: Petr Morávek [Xificurk] p...@pada.cz Datum: 11. 1. 2014 Předmět: Re: [Talk-cz] RUIAN nad OSM Dne 11.1.2014 09:27, Marián Kyral napsal(a): Ad import budov) Kromě toho, že některé budovy v RUIAN chybí, jsou i takové, které přebývají. Třeba ulice Na Poříčí, mezi vlakovým a autobusovým nádražím. Tam je obrovská parcela, kde sice byly budovy, ale před několika lety je srovnali se zemí a teď tam roste jen tráva. Pokud by jsi provedl automatický import, budovy by se opět objevily. Asi bych se prvně zaměřil na místa, kde zatím není vůbec nic. Tam to pak stejně musí někdo znalý revidovat. Případně, bylo by možné udělat něco na způsob traceru? Tedy, že kliknu do mapy v místě, kde je nějaká budova, plugin se spojí s nějakým serverem a vrátí tvar budovy z RUIAN. Taky by tam mohla být volba Importuj vše v okolí pro místa, kde ještě vůbec nic není. Ať to není třeba dělat po jedné. Ahoj, bohužel kvalita budov v RUIAN není nijak dobrá. Já jsem narazil na to, že některá (části) budov jsou označeny jen jako zastavěná plocha a naopak zastavěné plochy jsou označeny jako budova. Navíc se občas objeví docela hnusné artefakty přímo v geometriích. http://maps.fordfrog.com/?zoom=17lat=50.02363lon=15.77651layers=B00FFF http://mapy.cz/#!x=15.774797y=50.023553z=15l=15 Pokud tedy bude opravdu nějaký import budov probíhat, tak rozhodně nemůže být automatický, spíš opravdu něco na styl traceru. Zdraví, Petr Morávek aka Xificurk ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz; ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] iD editor a mapový podklad ČÚZK ortofoto
Hmm. Tady: https://github.com/osmlab/editor-imagery-index/blob/gh-pages/sources/europe/CzechCUZKKM.json je dokonce definice pro KM. Marek On Mon, Jan 13, 2014 at 08:13:05PM +0100, Jan Vršovský wrote: Ahoj, myslím, že nejlíp přes databázi podkladů, které iD používá: https://github.com/osmlab/editor-imagery-index Honza Vršovský -- Původní zpráva -- Od: Marek Chlup m...@chlup.net Datum: 13. 1. 2014 Předmět: Re: [Talk-cz] iD editor a mapový podklad ČÚZK ortofoto Děkuji za odpověď. ČÚZK u ORTOFOTO odkazuje pokud jde o podmínky poskytování (a i užití) na dokument: http://geoportal.cuzk.cz/Dokumenty/Podminky_sluzby_CUZK.pdf ten pak zmiňuje například vyhlášku č. 103/2010 Sb.: http://inspire.gov.cz/sites/default/files/documents/103_2010.pdf Chvíli jsem si to pročítal, ale kolize s licencí ODbL se mi těžko posuzují (přiznám se, že i ODbL nechápu detailně)... Každopádně děkuji za odkaz na wiki. Díval jsem se zejména na WMS katastrální mapy, které jsou hodnoceny jako zdroj dat v pořádku. Na některé záležitosti jde i o lepší zdroj než ORTOFOTO. Tedy velmi bych přivítal, kdyby bylo možné v iD editoru na openstreetmap.org vybrat přímo vrstvu ČÚZK Katastrální mapy. Kam se s takovou prosbou dá vhodně obrátit (aby to bylo zakomponováno do nabídky iD editoru)? Zdraví Marek Chlup On Mon, Jan 13, 2014 at 03:42:51PM +0100, Libor Pechacek wrote: Ahoj Marku, On Mon 13-01-14 15:18:27, Marek Chlup wrote: Mé dotazy: Je možné (legální) využívat letecké mapy, které na uvedených službách ČUZK poskytuje pro editaci OSM map? Nikoli. Viz http://wiki.openstreetmap.org/wiki/WikiProject_Czech_Republic/ freemap#Ov.C4.9B.C5.99ovac.C3.AD_zdroje Co je třeba udělat (kam se obrátit), aby v oblasti ČR byla ve webovém iD editoru nabízena přímo ČUZK letecká mapa? Jak tomu rozumím, především svolení vlastníka s použitím ortofota v OSM. Myslím, že nějaké pokusy o získání souhlasu byly, podívej se do archivu konference. HTH, Libor ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz; ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] iD editor a mapový podklad ČÚZK ortofoto
Aha, nojo, teď koukám, že iD nepodporuje WMS zdroje (umí zatím jen TMS a Bing), takže proto to KM nenabízí. Než to někdo vyřeší (https://github.com/openstreetmap/iD/issues/1141), tak to lze řešit prostřednictvím proxy (http://whoots.mapwarper.net/). Stačí zvolit v iD vlastní pozadí a zadat tam např. http://whoots.mapwarper.net:80/tms/{z}/{x}/{y}/parcelni_cisla,obrazy_parcel, RST_KMD,hranice_parcel,DEF_BUDOVY,RST_KN,dalsi_p_mapy,prehledka_kat_prac, prehledka_kat_uz,prehledka_kraju-linie/http://services.cuzk.cz/wms/wms.asp Honza -- Původní zpráva -- Od: Marek Chlup m...@chlup.net Datum: 13. 1. 2014 Předmět: Re: [Talk-cz] iD editor a mapový podklad ČÚZK ortofoto Hmm. Tady: https://github.com/osmlab/editor-imagery-index/blob/gh-pages/sources/europe/ CzechCUZKKM.json je dokonce definice pro KM. Marek On Mon, Jan 13, 2014 at 08:13:05PM +0100, Jan Vršovský wrote: Ahoj, myslím, že nejlíp přes databázi podkladů, které iD používá: https://github.com/osmlab/editor-imagery-index Honza Vršovský -- Původní zpráva -- Od: Marek Chlup m...@chlup.net Datum: 13. 1. 2014 Předmět: Re: [Talk-cz] iD editor a mapový podklad ČÚZK ortofoto Děkuji za odpověď. ČÚZK u ORTOFOTO odkazuje pokud jde o podmínky poskytování (a i užití) na dokument: http://geoportal.cuzk.cz/Dokumenty/Podminky_sluzby_CUZK.pdf ten pak zmiňuje například vyhlášku č. 103/2010 Sb.: http://inspire.gov.cz/sites/default/files/documents/103_2010.pdf Chvíli jsem si to pročítal, ale kolize s licencí ODbL se mi těžko posuzují (přiznám se, že i ODbL nechápu detailně)... Každopádně děkuji za odkaz na wiki. Díval jsem se zejména na WMS katastrální mapy, které jsou hodnoceny jako zdroj dat v pořádku. Na některé záležitosti jde i o lepší zdroj než ORTOFOTO. Tedy velmi bych přivítal, kdyby bylo možné v iD editoru na openstreetmap.org vybrat přímo vrstvu ČÚZK Katastrální mapy. Kam se s takovou prosbou dá vhodně obrátit (aby to bylo zakomponováno do nabídky iD editoru)? Zdraví Marek Chlup On Mon, Jan 13, 2014 at 03:42:51PM +0100, Libor Pechacek wrote: Ahoj Marku, On Mon 13-01-14 15:18:27, Marek Chlup wrote: Mé dotazy: Je možné (legální) využívat letecké mapy, které na uvedených službách ČUZK poskytuje pro editaci OSM map? Nikoli. Viz http://wiki.openstreetmap.org/wiki/WikiProject_Czech_ Republic/ freemap#Ov.C4.9B.C5.99ovac.C3.AD_zdroje Co je třeba udělat (kam se obrátit), aby v oblasti ČR byla ve webovém iD editoru nabízena přímo ČUZK letecká mapa? Jak tomu rozumím, především svolení vlastníka s použitím ortofota v OSM. Myslím, že nějaké pokusy o získání souhlasu byly, podívej se do archivu konference. HTH, Libor ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz; ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz;___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] iD editor a mapový podklad ČÚZK ortofoto
Děkuji. S tím proxy to funguje. Takže zřejmě až bude iD umět WMS zdroje tak asi do nabídky mapových podkladů spadne výběr katastrálních map automaticky. Mimochodem help v iD zřejmě předběhl dobu jelikož v sekci helpu Podkladové snímky je text: ... Pro velkou část České republiky jsou také dostupné velmi detailní satelitní snímky a navíc data z katastru nemovitostí. iD mne každopádně fascinuje co vše je již možné v prohlížeči čistě na bázi HTML/JavaScript realizovat (až na tu pomalost na Atom je super). Marek On Mon, Jan 13, 2014 at 09:52:00PM +0100, Jan Vršovský wrote: Aha, nojo, teď koukám, že iD nepodporuje WMS zdroje (umí zatím jen TMS a Bing), takže proto to KM nenabízí. Než to někdo vyřeší (https://github.com/openstreetmap/iD/issues/1141), tak to lze řešit prostřednictvím proxy (http://whoots.mapwarper.net/). Stačí zvolit v iD vlastní pozadí a zadat tam např. http://whoots.mapwarper.net:80/tms/{z}/{x}/{y}/parcelni_cisla,obrazy_parcel, RST_KMD,hranice_parcel,DEF_BUDOVY,RST_KN,dalsi_p_mapy,prehledka_kat_prac, prehledka_kat_uz,prehledka_kraju-linie/http://services.cuzk.cz/wms/wms.asp Honza -- Původní zpráva -- Od: Marek Chlup m...@chlup.net Datum: 13. 1. 2014 Předmět: Re: [Talk-cz] iD editor a mapový podklad ČÚZK ortofoto Hmm. Tady: https://github.com/osmlab/editor-imagery-index/blob/gh-pages/sources/europe/ CzechCUZKKM.json je dokonce definice pro KM. Marek On Mon, Jan 13, 2014 at 08:13:05PM +0100, Jan Vršovský wrote: Ahoj, myslím, že nejlíp přes databázi podkladů, které iD používá: https://github.com/osmlab/editor-imagery-index Honza Vršovský -- Původní zpráva -- Od: Marek Chlup m...@chlup.net Datum: 13. 1. 2014 Předmět: Re: [Talk-cz] iD editor a mapový podklad ČÚZK ortofoto Děkuji za odpověď. ČÚZK u ORTOFOTO odkazuje pokud jde o podmínky poskytování (a i užití) na dokument: http://geoportal.cuzk.cz/Dokumenty/Podminky_sluzby_CUZK.pdf ten pak zmiňuje například vyhlášku č. 103/2010 Sb.: http://inspire.gov.cz/sites/default/files/documents/103_2010.pdf Chvíli jsem si to pročítal, ale kolize s licencí ODbL se mi těžko posuzují (přiznám se, že i ODbL nechápu detailně)... Každopádně děkuji za odkaz na wiki. Díval jsem se zejména na WMS katastrální mapy, které jsou hodnoceny jako zdroj dat v pořádku. Na některé záležitosti jde i o lepší zdroj než ORTOFOTO. Tedy velmi bych přivítal, kdyby bylo možné v iD editoru na openstreetmap.org vybrat přímo vrstvu ČÚZK Katastrální mapy. Kam se s takovou prosbou dá vhodně obrátit (aby to bylo zakomponováno do nabídky iD editoru)? Zdraví Marek Chlup On Mon, Jan 13, 2014 at 03:42:51PM +0100, Libor Pechacek wrote: Ahoj Marku, On Mon 13-01-14 15:18:27, Marek Chlup wrote: Mé dotazy: Je možné (legální) využívat letecké mapy, které na uvedených službách ČUZK poskytuje pro editaci OSM map? Nikoli. Viz http://wiki.openstreetmap.org/wiki/WikiProject_Czech_ Republic/ freemap#Ov.C4.9B.C5.99ovac.C3.AD_zdroje Co je třeba udělat (kam se obrátit), aby v oblasti ČR byla ve webovém iD editoru nabízena přímo ČUZK letecká mapa? Jak tomu rozumím, především svolení vlastníka s použitím ortofota v OSM. Myslím, že nějaké pokusy o získání souhlasu byly, podívej se do archivu konference. HTH, Libor ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz; ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz; ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] RUIAN nad OSM
Dobrý den, ano, většinou to jsou chyby. U některých typů probíhají kontroly a katastrální pracoviště to postupně opravují. Tu možnost hlášení zjistím. J. Veselý -- Původní zpráva -- Od: Petr Vejsada o...@propsychology.cz Datum: 13. 1. 2014 Předmět: Re: [Talk-cz] RUIAN nad OSM Také všechny zdravím, Dne Po 13. ledna 2014 07:53:55, JV napsal(a): Zdravím všechny, ad artefakty - to není chyba, ale zcela legální stav. Je potřeba si uvědomit, že katastrální mapa *není* technická mapa a že do 31.12.2013 budova a pozemek pod ní byly dvě nemovitosti (a u nemovitostí, existujících před 1.1.2014 to bude i nadále, pokud se vlastnické poměry liší - velice rozumím, že katastrální mapa je mapa právní a že tedy neodráží realitu, ale právní stav. Opakovaně narážím na stav (RUIAN), o kterém si myslím, že nikdy nebyl stavem skutečným ani stavem právním. Je to v případech, kdy leží třeba 3 budovy na sobě https://ruian.poloha.net/20/50.08934/14.46915 - rozsviťte si overlay budov a je to dokonce vidět, jak ta překryvná vrstva má jinou barvu na budově Biskupcova 347/12. Biskupcova 14 a 16 ovšem chybí. Tedy nechybí, ale leží na Biskupcově 12. To není zdaleka jediný případ. Tento konkrétní případ vypadá v RUIAN takto: kod | budova_id | cisla_domovni --+---+--- 21695270 | 884184101 | {347} 21695547 | 884184101 | {382} 21696519 | 884184101 | {501} Zrovna tyto případy není nutné složitě hledat; postačil by vhodně zvolený dotaz do databáze. Dalším ne zcela vzácným jevem je výskyt budovy na místě vnitrobloku: https://ruian.poloha.net/20/50.08313/14.42040 přičemž v místě, kde budova má být, tak není. Vypadá to na nějakou zavlečenou chybu, nevím. Mohu třeba tyto výskyty někam hlásit, pokud by to mělo skutečně smysl. -- Petr zjednodušeně řečeno). Zrovna v těch Pardubicích to znamená, že budova je Ministerstva obrany (http://vdp.cuzk.cz/vdp/ruian/stavebniobjekty/ 46757481 - tlačítko Údaje o vlastnictví otevře Nahlížení do KN se zvýrazněným obvodem budovy), ale pozemky pod ní jsou částečně i města (to je ten hnusný artefakt). Netvrdím, že v katastru nejsou chyby - ale vždy je mít na paměti výše uvedené a že katastr eviduje *právní* stav. Tedy pokud v terénu již nějaká budova není, může se v katastru i nadále zobrazovat, protože nikdo tu změnu neohlásil. A aby to bylo ještě složitější, zrovna cesta k odstranění budovy začíná na stavebním úřadu a teprve následně je možné to oznámit katastru. J. Veselý -- Původní zpráva -- Od: Petr Morávek [Xificurk] p...@pada.cz Datum: 11. 1. 2014 Předmět: Re: [Talk-cz] RUIAN nad OSM Dne 11.1.2014 09:27, Marián Kyral napsal(a): Ad import budov) Kromě toho, že některé budovy v RUIAN chybí, jsou i takové, které přebývají. Třeba ulice Na Poříčí, mezi vlakovým a autobusovým nádražím. Tam je obrovská parcela, kde sice byly budovy, ale před několika lety je srovnali se zemí a teď tam roste jen tráva. Pokud by jsi provedl automatický import, budovy by se opět objevily. Asi bych se prvně zaměřil na místa, kde zatím není vůbec nic. Tam to pak stejně musí někdo znalý revidovat. Případně, bylo by možné udělat něco na způsob traceru? Tedy, že kliknu do mapy v místě, kde je nějaká budova, plugin se spojí s nějakým serverem a vrátí tvar budovy z RUIAN. Taky by tam mohla být volba Importuj vše v okolí pro místa, kde ještě vůbec nic není. Ať to není třeba dělat po jedné. Ahoj, bohužel kvalita budov v RUIAN není nijak dobrá. Já jsem narazil na to, že některá (části) budov jsou označeny jen jako zastavěná plocha a naopak zastavěné plochy jsou označeny jako budova. Navíc se občas objeví docela hnusné artefakty přímo v geometriích. http://maps.fordfrog.com/?zoom=17lat=50.02363lon=15.77651layers=B00FFF http://mapy.cz/#!x=15.774797y=50.023553z=15l=15 Pokud tedy bude opravdu nějaký import budov probíhat, tak rozhodně nemůže být automatický, spíš opravdu něco na styl traceru. Zdraví, Petr Morávek aka Xificurk ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz; ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz;___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [OSM-talk-fr] combien d'adresses en Alsace ?
Pour déterminer les règles d’usage, vous pouvez vous servir de la page wiki ad hoc : http://wiki.openstreetmap.org/wiki/Mulhouse/MulhouseData. A ce propos, l’import de l’opendata mulhousien avance bien. Bravo eiger Denis De : Matthias Dietrich [mailto:eiger@gmail.com] Envoyé : samedi 11 janvier 2014 18:54 À : Discussions sur OSM en français Objet : Re: [OSM-talk-fr] combien d'adresses en Alsace ? Le 11 janvier 2014 18:06, Jean-Baptiste Holcroft jb.holcr...@gmail.commailto:jb.holcr...@gmail.com a écrit : Quelle est la règle actuelle ? REF:FR:M2A ? Il n'y en a pas ;-) (de règle), mais cela pourrait en effet devenir ref:FR:M2A. Les jeux de données de la M2A ne comportent pas tous d'identifiant ou de référence. Les stations Vélocité ont été importées depuis plus longtemps à partir des fichiers mis à disposition par JCDecaux, avec un simple ref=numéro de station. La plupart des autres objets n'ont pas de d'identifiant. Pour parler concrètement : est-ce que tu souhaites procéder à l'import des arbres de la M2A ? Il faudrait s'accorder sur ce qu'on fait des attributs disponibles (diamètre de la couronne, etc.). ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bâtiments se chevauchant
Le 13/01/2014 07:43, Jean-Francois Nifenecker a écrit : Le 12/01/2014 21:18, didier2020 a écrit : Le dimanche 12 janvier 2014 à 20:20 +0100, lenny a écrit : - des Bâtiments se chevauchant - des Bâtiments à l'intérieur d'un autre pour ces mini erreurs, j'utilise un script qui les corrige automatiquement. (je le fais regulierement sur la france) je ne connaissais pas. Je regarde ça... Il y a aussi un Osmecum : http://wiki.openstreetmap.org/w/images/2/2d/Osmecum_integration_bati_v020.pdf Mes 2 euro-cents, Merci à tous les deux, ça fonctionne, j'ai corrigé et j'ai encore de la lecture. Cette liste est vraiment une mine !!! Lenny ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rendu QA: ajout croisement FANTOIR et visu noname
Le 12 janvier 2014 23:37, Christian Quest cqu...@openstreetmap.fr a écrit : 184... c'est le nombre d'abréviations dans la colonne nature_voie de FANTOIR Pour certaines, j'ai du mal à trouver la correspondance, si vous voulez m'aider, c'est ici: https://docs.google.com/spreadsheet/ccc?key=0AkurI9Y66dXNdHVDRnNtNFk2TVlBUDdvRURIWmNDM1E Ensuite, je vais regarder les abréviation dans le nom de voies (GAL=Général MAL=Maréchal, etc). Il me semble avoir déjà vu la liste dans une des doc du fantoir/rivoli ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] combien d'adresses en Alsace ?
Pour en revenir à l'image du taux de couverture, il y a un nombre significatif de village que je pense avoir complété avec toutes les adresses que j'arrive à distinguer sur le cadastre mais qui apparaissent en vert clair (60-80%). Un exemple : Lembach, tout au nord de la région. Est-ce que ça veut dire que la base cadastrale à laquelle tu avais accès était plus complète que celle qu'on peut télécharger avec le plugin de JOSM cadastre-fr ? J'ai remarqué qu'il manquait un certain nombre de numéros, parfois tout un côté de la rue, mais je pensais que ces données étaient complètement absentes de la base cadastrale. 2014/1/13 HELFER Denis denis.hel...@rff.fr Pour déterminer les règles d’usage, vous pouvez vous servir de la page wiki ad hoc : http://wiki.openstreetmap.org/wiki/Mulhouse/MulhouseData. A ce propos, l’import de l’opendata mulhousien avance bien. Bravo eiger Denis *De :* Matthias Dietrich [mailto:eiger@gmail.com] *Envoyé :* samedi 11 janvier 2014 18:54 *À :* Discussions sur OSM en français *Objet :* Re: [OSM-talk-fr] combien d'adresses en Alsace ? Le 11 janvier 2014 18:06, Jean-Baptiste Holcroft jb.holcr...@gmail.com a écrit : Quelle est la règle actuelle ? REF:FR:M2A ? Il n'y en a pas ;-) (de règle), mais cela pourrait en effet devenir ref:FR:M2A. Les jeux de données de la M2A ne comportent pas tous d'identifiant ou de référence. Les stations Vélocité ont été importées depuis plus longtemps à partir des fichiers mis à disposition par JCDecaux, avec un simple ref=numéro de station. La plupart des autres objets n'ont pas de d'identifiant. Pour parler concrètement : est-ce que tu souhaites procéder à l'import des arbres de la M2A ? Il faudrait s'accorder sur ce qu'on fait des attributs disponibles (diamètre de la couronne, etc.). ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] données douteuses
Bonjour Contacté début décembre, reçu aucune réponse cordialement Claude Le 7 décembre 2013 23:39, Christian Quest cqu...@openstreetmap.fr a écrit : Tu contacte le contributeur... Le 7 décembre 2013 23:29, Claude claude.mar...@gmail.com a écrit : Bonsoir En faisant des mise à jours du coté de Briennon (42) je suis tombé sur une routes départementale avec un tag name=La Bourbasse. J'avais pas encore vu de départementale avec un nom comme ca mais pourquoi pas. En continuant mes tracé, j'en ai trouvé plein d'autre et ça m'a fais penser à Google Map. je suis allé vérifier Je pense que c'est bien ça. c'est flagrant ici http://osm.org/go/0AnsCL~I la D35 est coupé exactement au même point que sur Google Map et les nom sont identiques Que doit-je faire, je supprime les name? cordialement Claude -- Envoyé avec Mozilla Thunderbird --- ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rendu QA: ajout croisement FANTOIR et visu noname
FANTOIR... où comment se cultiver... La recherche de la rue Richepance (Paris 1er): http://openstreetmap.fr/blogs/cquest/fantoir-et-culture-generale -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] données douteuses
Bizarre en effet... Pas de BOURBASSE à Briennon dans FANTOIR... http://openstreetmap.fr/outils/adresses?insee=42026 Par contre, on trouve des adresses comme une menuiserie au 7 La Bourbasse... Le 13 janvier 2014 12:28, claude marani claude.mar...@gmail.com a écrit : Bonjour Contacté début décembre, reçu aucune réponse cordialement Claude -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] combien d'adresses en Alsace ?
Plusieurs éléments de réponse : · La base cadastrale sur laquelle je me suis appuyé contient plus d'éléments que de réelles adresses. J'avais empiriquement pris uniquement 92% de ce résultat pour tenir compte de cas particuliers que j'avais repéré : poste de transformation électrique qui avait une adresse, adresses placées alors qu'aucun bâtiment n'existe (cas dans des lotissements où l'adresse est prévisible), hangars agricoles avec adresse, etc. · L'ensemble des adresses n'est pas affiché sur le plan cadastral. Parfois, il faut aller sur le site du cadastre, choisir une parcelle et afficher les informations. Il faut donc jongler entre JOSM et le cadastre à moins qu'une développeur fou ne nous permette de remonter l'info dans JOSM. Une bière (ou plus si affinités) à la clé ! · Comme déjà évoqué, il ne faut pas prendre les chiffres à la lettre (elle est bonne celle là ;-) Il s'agit plutôt d'un indicateur que l'on pourrait remplacer par : rien, un tout petit peu, un petit peu, un peu, pas mal, vraiment beaucoup, top moumoute. Prochaine version. · Il faut tenir compte que la base de comparaison commence à dater un peu et fausse encore plus les calculs · Enfin, il faut repasser régulièrement sur les communes, au moins annuellement. Les plans cadastraux évoluent pas mal surtout s'ils sont vectorisés. Pour le cas particulier de Lembach, il y a une centaine d'adresses attribut de bâti qui ne sont pas comptées sur Pfaffenbronn (je ne compte que les points par pure fainéantise). Sur la rue André Maginot, tu peux raisonnablement interpoler les n°11 et 13. L'impasse des Noyers a 6 adresses, etc. Tu dois pouvoir basculer très rapidement dans la catégorie « pas mal » voire même « vraiment beaucoup ». Je referai une analyse début février. Denis De : Pierre Knobel [mailto:pierr...@gmail.com] Envoyé : lundi 13 janvier 2014 11:58 À : Discussions sur OSM en français Objet : Re: [OSM-talk-fr] combien d'adresses en Alsace ? Pour en revenir à l'image du taux de couverture, il y a un nombre significatif de village que je pense avoir complété avec toutes les adresses que j'arrive à distinguer sur le cadastre mais qui apparaissent en vert clair (60-80%). Un exemple : Lembach, tout au nord de la région. Est-ce que ça veut dire que la base cadastrale à laquelle tu avais accès était plus complète que celle qu'on peut télécharger avec le plugin de JOSM cadastre-fr ? J'ai remarqué qu'il manquait un certain nombre de numéros, parfois tout un côté de la rue, mais je pensais que ces données étaient complètement absentes de la base cadastrale. 2014/1/13 HELFER Denis denis.hel...@rff.frmailto:denis.hel...@rff.fr Pour déterminer les règles d'usage, vous pouvez vous servir de la page wiki ad hoc : http://wiki.openstreetmap.org/wiki/Mulhouse/MulhouseData. A ce propos, l'import de l'opendata mulhousien avance bien. Bravo eiger Denis De : Matthias Dietrich [mailto:eiger@gmail.commailto:eiger@gmail.com] Envoyé : samedi 11 janvier 2014 18:54 À : Discussions sur OSM en français Objet : Re: [OSM-talk-fr] combien d'adresses en Alsace ? Le 11 janvier 2014 18:06, Jean-Baptiste Holcroft jb.holcr...@gmail.commailto:jb.holcr...@gmail.com a écrit : Quelle est la règle actuelle ? REF:FR:M2A ? Il n'y en a pas ;-) (de règle), mais cela pourrait en effet devenir ref:FR:M2A. Les jeux de données de la M2A ne comportent pas tous d'identifiant ou de référence. Les stations Vélocité ont été importées depuis plus longtemps à partir des fichiers mis à disposition par JCDecaux, avec un simple ref=numéro de station. La plupart des autres objets n'ont pas de d'identifiant. Pour parler concrètement : est-ce que tu souhaites procéder à l'import des arbres de la M2A ? Il faudrait s'accorder sur ce qu'on fait des attributs disponibles (diamètre de la couronne, etc.). ___ Talk-fr mailing list Talk-fr@openstreetmap.orgmailto:Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] données douteuses
Bonjour Il y a un lieu dit La Bourbasse.à Briennon (source base Hexavia) Le 13 janvier 2014 12:44, Christian Quest cqu...@openstreetmap.fr a écrit : Bizarre en effet... Pas de BOURBASSE à Briennon dans FANTOIR... http://openstreetmap.fr/outils/adresses?insee=42026 Par contre, on trouve des adresses comme une menuiserie au 7 La Bourbasse... Le 13 janvier 2014 12:28, claude marani claude.mar...@gmail.com a écrit : Bonjour Contacté début décembre, reçu aucune réponse cordialement Claude -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] combien d'adresses en Alsace ?
D'accord, donc dans ce cas particuliers ça s'explique bien par la quantité d'adresses placées sur le bâti (Pfafenbronn et aussi Mattstall). Pour les autres villages il va falloir que je jette un deuxième coup d'oeil, l'explication des adresses sur polygones ne fonctionne que pour Lembach ;-) http://tools.geofabrik.de/osmi/?view=addresseslon=7.74758lat=48.94608zoom=12overlays=buildings_with_addresses,nodes_with_addresses_defined,nodes_with_addresses_interpolated,no_addr_street,street_not_found,nearest_roads Autre question : Est-ce qu'on a une technique pour les villages qui n'ont pas de cadastre vectoriel (Dambach) ? 2014/1/13 HELFER Denis denis.hel...@rff.fr Plusieurs éléments de réponse : · La base cadastrale sur laquelle je me suis appuyé contient plus d’éléments que de réelles adresses. J’avais empiriquement pris uniquement 92% de ce résultat pour tenir compte de cas particuliers que j’avais repéré : poste de transformation électrique qui avait une adresse, adresses placées alors qu’aucun bâtiment n’existe (cas dans des lotissements où l’adresse est prévisible), hangars agricoles avec adresse, etc. · L’ensemble des adresses n’est pas affiché sur le plan cadastral. Parfois, il faut aller sur le site du cadastre, choisir une parcelle et afficher les informations. Il faut donc jongler entre JOSM et le cadastre à moins qu’une développeur fou ne nous permette de remonter l’info dans JOSM. Une bière (ou plus si affinités) à la clé ! · Comme déjà évoqué, il ne faut pas prendre les chiffres à la lettre (elle est bonne celle là ;-) Il s’agit plutôt d’un indicateur que l’on pourrait remplacer par : rien, un tout petit peu, un petit peu, un peu, pas mal, vraiment beaucoup, top moumoute. Prochaine version. · Il faut tenir compte que la base de comparaison commence à dater un peu et fausse encore plus les calculs · Enfin, il faut repasser régulièrement sur les communes, au moins annuellement. Les plans cadastraux évoluent pas mal surtout s’ils sont vectorisés. Pour le cas particulier de Lembach, il y a une centaine d’adresses attribut de bâti qui ne sont pas comptées sur Pfaffenbronn (je ne compte que les points par pure fainéantise). Sur la rue André Maginot, tu peux raisonnablement interpoler les n°11 et 13. L’impasse des Noyers a 6 adresses, etc. Tu dois pouvoir basculer très rapidement dans la catégorie « pas mal » voire même « vraiment beaucoup ». Je referai une analyse début février. Denis *De :* Pierre Knobel [mailto:pierr...@gmail.com] *Envoyé :* lundi 13 janvier 2014 11:58 *À :* Discussions sur OSM en français *Objet :* Re: [OSM-talk-fr] combien d'adresses en Alsace ? Pour en revenir à l'image du taux de couverture, il y a un nombre significatif de village que je pense avoir complété avec toutes les adresses que j'arrive à distinguer sur le cadastre mais qui apparaissent en vert clair (60-80%). Un exemple : Lembach, tout au nord de la région. Est-ce que ça veut dire que la base cadastrale à laquelle tu avais accès était plus complète que celle qu'on peut télécharger avec le plugin de JOSM cadastre-fr ? J'ai remarqué qu'il manquait un certain nombre de numéros, parfois tout un côté de la rue, mais je pensais que ces données étaient complètement absentes de la base cadastrale. 2014/1/13 HELFER Denis denis.hel...@rff.fr Pour déterminer les règles d’usage, vous pouvez vous servir de la page wiki ad hoc : http://wiki.openstreetmap.org/wiki/Mulhouse/MulhouseData. A ce propos, l’import de l’opendata mulhousien avance bien. Bravo eiger Denis *De :* Matthias Dietrich [mailto:eiger@gmail.com] *Envoyé :* samedi 11 janvier 2014 18:54 *À :* Discussions sur OSM en français *Objet :* Re: [OSM-talk-fr] combien d'adresses en Alsace ? Le 11 janvier 2014 18:06, Jean-Baptiste Holcroft jb.holcr...@gmail.com a écrit : Quelle est la règle actuelle ? REF:FR:M2A ? Il n'y en a pas ;-) (de règle), mais cela pourrait en effet devenir ref:FR:M2A. Les jeux de données de la M2A ne comportent pas tous d'identifiant ou de référence. Les stations Vélocité ont été importées depuis plus longtemps à partir des fichiers mis à disposition par JCDecaux, avec un simple ref=numéro de station. La plupart des autres objets n'ont pas de d'identifiant. Pour parler concrètement : est-ce que tu souhaites procéder à l'import des arbres de la M2A ? Il faudrait s'accorder sur ce qu'on fait des attributs disponibles (diamètre de la couronne, etc.). ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Raildar OSM
Bonjour Pierre, Je ne connais pas toutes les subtilités des tags dans ce domaine, mais en regardant certaines gares parisiennes, j'ai décelé quelques noeuds taggués comme suit : public_transport = stop_position train = yes Selon [1] il est possible d'ajouter un numéro de référence, du genre (pour la voie N°3) ref = 3 Il y a également des mentions concernant les références / noms UIC. Ces informations sont généralement situées sur le noeud décrivant l'ensemble de la gare. En conséquence j'aurais tendance à ne pas les multiplier pour chacun des points d'arrêt (*) Les quais peuvent également être référencés. NB : Pour faciliter la contribution des nouveaux arrivants dans osm, et en particulier ceux qui s'intéressent à un sujet en particulier, il est possible de mettre en place une fiche osmecum [2] C'est très pratique comme pense-bête, et ça permet de maintenir une bonne homogénéité dans les contributions. Il n'existe pas encore pour le domaine ferroviaire. Il est également bienvenu de partager les zones que l'on sait très bien cartographiées. Un recensement existe pour un grand nombre de domaines et donne deux exemples de gares : Avignon TGV et Cologne [3]. Comme souvent dans OSM, l'exemple allemand est très ... fourni ;-) (*) En affichant la carte sur le site principal, il est possible de cliquer sur les éléments (points, polylignes ...) en allant dans le menu des couches et en cochant la case Données de la carte. Les noeuds qui comportent des tags sont cerclés. Bonne journée - [1] http://wiki.openstreetmap.org/wiki/Tag:public_transport%3Dstop_position [2] http://wiki.openstreetmap.org/wiki/WikiProject_France/Osmecum [3] http://wiki.openstreetmap.org/wiki/FR:Cartotheque#Transport_ferroviaire (*) Pour la gare de Cologne, chaque point d'arrêt porte les infos de la gare (nom, références nationale et internationale) Le 13 janvier 2014 02:16, Pierre Beyssac p...@fasterix.frmug.org a écrit : Bonjour, Je rebondis sur la discussion en cours. Je me présente car c'est mon premier message ici : je travaille, euh m'amuse disons, sur le projet Raildar lancé par Bruno. Je m'intéresse donc principalement aux voies ferrées dans OSM et à vrai dire (pour avoir fait beaucoup de traces GPS ferroviaires au fil des ans et rencontré des problèmes de précision) je trouve la base de bonne qualité et plutôt complète. J'ai fait pas mal de corrections dans OSM suite aux bugs de voies trouvés par Raildar et j'ai créé un visualisateur de routes ferroviaires OSRM pour aider au debug (il est là http://www.raildar.fr/osrm/osrm.html ou là pour la version de dev http://signal.eu.org/osm/ ). Comme je suis (indépendamment de Raildar) un indécrottable amateur de trains j'ai aussi ajouté/complété des gares et voies. On Mon, Jan 13, 2014 at 12:00:43AM +0100, Spyou wrote: Le 11/01/2014 23:57, François Lacombe a écrit : A mon avis il serait peut-être possible de se servir du type de voie pour faire le routage plutôt que de rajouter des waypoints fantômes. C'est à dire qu'OSRM devrait tenir compte du fait qu'un TER ne peut pas prendre les voies TGV par exemple. OSRM est malheureusement incapable de prendre des consignes à l'entrée lors des demandes. Tout passe par la conf en LUA qui doit ensuite être moulinée pendant deux bonnes heures avant de donner une db utilisable. On peut bien entendu faire tourner X instances d'OSRM (une pour les TGV, une pour les TER, une pour les RER, ...) mais c'est autant de boulot à maintenir :( Je vois quand même un cas où des infos supplémentaires dans OSM pourraient être très utiles et d'intérêt général : des labels aux voies/quais dans les gares, qui permettraient de relier une indication de voie pour un train (de SNCF Direct co) avec une position géographique, qui est un des points qui posent problème à Raildar dans les (nombreuses) gares avec des quais ne desservant pas toutes les destinations. -- Sent from my FreeBSD server on its IPv6 connection Pierre Beyssac p...@fasterix.frmug.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab Il n'y a pas de pas perdus, Nadja ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] combien d'adresses en Alsace ?
Pour les cadastres raster, tout se fait à la mano. La visite terrain est un plus !! De : Pierre Knobel [mailto:pierr...@gmail.com] Envoyé : lundi 13 janvier 2014 15:23 À : Discussions sur OSM en français Objet : Re: [OSM-talk-fr] combien d'adresses en Alsace ? D'accord, donc dans ce cas particuliers ça s'explique bien par la quantité d'adresses placées sur le bâti (Pfafenbronn et aussi Mattstall). Pour les autres villages il va falloir que je jette un deuxième coup d'oeil, l'explication des adresses sur polygones ne fonctionne que pour Lembach ;-) http://tools.geofabrik.de/osmi/?view=addresseslon=7.74758lat=48.94608zoom=12overlays=buildings_with_addresses,nodes_with_addresses_defined,nodes_with_addresses_interpolated,no_addr_street,street_not_found,nearest_roads Autre question : Est-ce qu'on a une technique pour les villages qui n'ont pas de cadastre vectoriel (Dambach) ? 2014/1/13 HELFER Denis denis.hel...@rff.frmailto:denis.hel...@rff.fr Plusieurs éléments de réponse : * La base cadastrale sur laquelle je me suis appuyé contient plus d'éléments que de réelles adresses. J'avais empiriquement pris uniquement 92% de ce résultat pour tenir compte de cas particuliers que j'avais repéré : poste de transformation électrique qui avait une adresse, adresses placées alors qu'aucun bâtiment n'existe (cas dans des lotissements où l'adresse est prévisible), hangars agricoles avec adresse, etc. * L'ensemble des adresses n'est pas affiché sur le plan cadastral. Parfois, il faut aller sur le site du cadastre, choisir une parcelle et afficher les informations. Il faut donc jongler entre JOSM et le cadastre à moins qu'une développeur fou ne nous permette de remonter l'info dans JOSM. Une bière (ou plus si affinités) à la clé ! * Comme déjà évoqué, il ne faut pas prendre les chiffres à la lettre (elle est bonne celle là ;-) Il s'agit plutôt d'un indicateur que l'on pourrait remplacer par : rien, un tout petit peu, un petit peu, un peu, pas mal, vraiment beaucoup, top moumoute. Prochaine version. * Il faut tenir compte que la base de comparaison commence à dater un peu et fausse encore plus les calculs * Enfin, il faut repasser régulièrement sur les communes, au moins annuellement. Les plans cadastraux évoluent pas mal surtout s'ils sont vectorisés. Pour le cas particulier de Lembach, il y a une centaine d'adresses attribut de bâti qui ne sont pas comptées sur Pfaffenbronn (je ne compte que les points par pure fainéantise). Sur la rue André Maginot, tu peux raisonnablement interpoler les n°11 et 13. L'impasse des Noyers a 6 adresses, etc. Tu dois pouvoir basculer très rapidement dans la catégorie « pas mal » voire même « vraiment beaucoup ». Je referai une analyse début février. Denis De : Pierre Knobel [mailto:pierr...@gmail.commailto:pierr...@gmail.com] Envoyé : lundi 13 janvier 2014 11:58 À : Discussions sur OSM en français Objet : Re: [OSM-talk-fr] combien d'adresses en Alsace ? Pour en revenir à l'image du taux de couverture, il y a un nombre significatif de village que je pense avoir complété avec toutes les adresses que j'arrive à distinguer sur le cadastre mais qui apparaissent en vert clair (60-80%). Un exemple : Lembach, tout au nord de la région. Est-ce que ça veut dire que la base cadastrale à laquelle tu avais accès était plus complète que celle qu'on peut télécharger avec le plugin de JOSM cadastre-fr ? J'ai remarqué qu'il manquait un certain nombre de numéros, parfois tout un côté de la rue, mais je pensais que ces données étaient complètement absentes de la base cadastrale. 2014/1/13 HELFER Denis denis.hel...@rff.frmailto:denis.hel...@rff.fr Pour déterminer les règles d'usage, vous pouvez vous servir de la page wiki ad hoc : http://wiki.openstreetmap.org/wiki/Mulhouse/MulhouseData. A ce propos, l'import de l'opendata mulhousien avance bien. Bravo eiger Denis De : Matthias Dietrich [mailto:eiger@gmail.commailto:eiger@gmail.com] Envoyé : samedi 11 janvier 2014 18:54 À : Discussions sur OSM en français Objet : Re: [OSM-talk-fr] combien d'adresses en Alsace ? Le 11 janvier 2014 18:06, Jean-Baptiste Holcroft jb.holcr...@gmail.commailto:jb.holcr...@gmail.com a écrit : Quelle est la règle actuelle ? REF:FR:M2A ? Il n'y en a pas ;-) (de règle), mais cela pourrait en effet devenir ref:FR:M2A. Les jeux de données de la M2A ne comportent pas tous d'identifiant ou de référence. Les stations Vélocité ont été importées depuis plus longtemps à partir des fichiers mis à disposition par JCDecaux, avec un simple ref=numéro de station. La plupart des autres objets n'ont pas de d'identifiant. Pour parler concrètement : est-ce que tu souhaites procéder à l'import des arbres de la M2A ? Il faudrait s'accorder sur ce qu'on fait des attributs disponibles (diamètre de la couronne, etc.). ___ Talk-fr mailing list Talk-fr@openstreetmap.orgmailto:Talk-fr@openstreetmap.org
[OSM-talk-fr] Forum Ile-de-France
La liste de diffusion local-idf n'ayant jamais décollé, j'ai proposé sur celle-ci de basculer sur le forum phpBB. Il n'y a eu qu'une réponse (positive), donc le forum IdF est maintenant dispo sur http://forum.openstreetmap.fr/viewforum.php?f=18 Rdv pour y parler de sujets francilio-franciliens ! -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rendu QA: ajout croisement FANTOIR et visu noname
c'est peut etre cela que tu cherches Christian: www.agencealpha.com/download/r_cadastraux.doc Par contre pour VC j'ai pas trouvé la réponse... Pour info chez moi j'ai un VC VILLAGE DE LA ROCHE AVANE c'est un village avec un petit lotissement mais aussi une rue unique... bref je voit pas trop a quoi correspond le c a part pour comunal? -- View this message in context: http://gis.19327.n5.nabble.com/Rendu-QA-ajout-croisement-FANTOIR-et-visu-noname-tp5791052p5792898.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rendu QA: ajout croisement FANTOIR et visu noname
VC = Voie Communale... Super pour le reste, je vais intégrer ça dans mon désabréviateur ©®™ ;) Le 13 janvier 2014 19:21, PierreV belett...@hotmail.fr a écrit : c'est peut etre cela que tu cherches Christian: www.agencealpha.com/download/r_cadastraux.doc Par contre pour VC j'ai pas trouvé la réponse... Pour info chez moi j'ai un VC VILLAGE DE LA ROCHE AVANE c'est un village avec un petit lotissement mais aussi une rue unique... bref je voit pas trop a quoi correspond le c a part pour comunal? -- View this message in context: http://gis.19327.n5.nabble.com/Rendu-QA-ajout-croisement-FANTOIR-et-visu-noname-tp5791052p5792898.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rendu QA: ajout croisement FANTOIR et visu noname
Le 13/01/2014 20:15, Christian Quest a écrit : VC = Voie Communale... Super pour le reste, je vais intégrer ça dans mon désabréviateur ©®™ ;) CDT == Commandant BOULEVARD DU CDT RENE MOUCHOTTE == Boulevard du Commandant René Mouchotte RI == Régiment d'Infanterie BOULEVARD CORPS FRANC POMMIES 49 RI == Boulevard du Corps Franc Pommiès et du 49e Régiment d'Infanterie Sinon une erreur du FANTOIR sur Pau AVENUE ROBERT SCHUMANN au lieu de Avenue Robert Schuman Les bio de ces 2 personnages pour voir que l'erreur est possible dans votre commune (pour l'un ou l'autre des patronymes). L'homme politique est sans aucun doute celui qui donne son nom à la majorité des voies... https://fr.wikipedia.org/wiki/Robert_Schumann https://fr.wikipedia.org/wiki/Robert_Schuman Librement, -- Christophe Merlet (RedFox) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr