Re: [Talk-at] Public Transport Schema und Wien
Am 30.05.2015 um 18:17 schrieb Robin Däneke: Könntest du mir da ein paar Beispiele nennen? Schau Dir mal den Stadtbus 1 in Mödling an. http://overpass-api.de/api/sketch-line?network=VORref=Stadtbus%201 Master-Relation: http://www.openstreetmap.org/relation/3765829 Route Bahnhof - Babenbergergasse - Prießnitztal http://www.openstreetmap.org/relation/3763890 Route Prießnitztal - Stadtbad - Bahnhof http://www.openstreetmap.org/relation/3763891 Das ist eine relativ kurze Busstrecke mit zwei unterschiedlichen Routenführungen. LG, Christian ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Versatz geoimage vs. basemap
On 2015-05-30 16:00, Flaimo wrote: Welches Bildmaterial ist hier aber wirklich exakt? Soll ich jetzt jedes Mal den Basemap-Layer vorher manuell zurechtschieben? Oder besteht die Chance, dass die neuen geoimage-Bilder dann besser sind? Dann würde ich noch mit größeren Änderungen warten... meiner Erfahrung nach stimmen die Lagepositionen von Gebäuden in der Basemap nur bedingt und sind keine verlässliche Quelle. genauso wie deren Hausnummern usw... leider. wo in der Basemap die einzelnen Daten herkommen würde ich wirklich gerne wissen - und zwar am liebsten pro Objekt. derzeit ist die Basemap leider etwas, das unter wikipedia-Regeln mit [citation needed] markiert werden würde. dagegen sind die Orthofotos von geoimage.at selbst im dreidimensionalen Gelände in den Bergen so perfekt korrigiert, dass man sich fragt ob die zaubern können. andrerseits machen die das auch schon länger.. ;) beide Einschätzungen allerdings ohne exakte vermessungstechnische Daten, sondern nur aus der Beobachtung und Arbeit mit beiden Quellen im Vergleich mit allem anderen deren man so habhaft werden kann. ausserdem mappe ich kaum in OÖ sondern meistens in der Stmk. generell rücke ich Gebäude mit source plan.at 09 oder überhaupt mit wechselndem Versatz schon in Richtung geoimage Position. zumindest wenn der Versatz offensichtlich ist und sich vorallem mit anderen Objekten deutlich in die Quere kommt. aber wenn man sich mal die ÖK/AMAP anschaut, dann merkt man, dass eine perfekte Karte nicht unbedingt auf den Millimeter exakt sein muss, sondern funktionieren. *grins* grüsse, grubernd ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [OSM-talk-ie] Water depth in lake
On Sat, May 30, 2015 at 05:47:18PM +0100, Colm Moore wrote: Hi, This is potentially life or death information, so I'm not sure if it is approved for OSM. Different datums (measurements) are used: http://en.wikipedia.org/wiki/Chart_datum However, with lakes, you might find novel effects on water depth, like flows from higher rivers / lakes, reservoirs, currents, etc. Colm Thanks for all the responses to my message and it's certainly food for thought. I was actually talking with a boat person about it and they were saying that it wasn't simple at all. If I did have a depth at a position I'd also have to get my hands on the official water level at that time. He wasn't sure who keeps that info but basically all water depths are measured relative to a set water level. If the current level is below or above that then you have to adjust all figures. Guess it's something I've never thought about before, but sure now I know. Thanks again. John --- Never doubt that a small group of thoughtful, committed citizens can change the world. Indeed, it is the only thing that ever has. Margaret Mead Message: 2 Date: Fri, 29 May 2015 15:10:51 +0100 From: Daniel Cussen d...@post.com To: Discussion of OpenStreetMap in Ireland talk-ie@openstreetmap.org Subject: Re: [OSM-talk-ie] Water depth in lake 3) Depth is normally displayed on maps as mean tide level (I think), are you taking into account tide (off shore) or recent rain for rivers to calculate the actual depth below mean level? ___ Talk-ie mailing list Talk-ie@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ie ___ Talk-ie mailing list Talk-ie@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ie
Re: [Talk-de] Tag für Fahrradzählstellen
Hallo Frau Robert Klemm, bevor wir einen Tag erfinden sollten wir überlegen, ob wir diese Dinge überhaupt mappen wollen. Auch wenn es von den Fahrradsensoren erst ein paar Handvoll gibt -- Fahrzeugsensoren, als Induktionsschleifen oder als Bewegungsmelder von oben, gibt es ja schon zuhauf, an vielen Kreuzungen je ankommende Spur, und unterwegs auch noch genug. Selbst die Vorschläge, die Ampellichter pro Spur zu erfassen sind bisher nicht übermässig erfolgreich, ich sehe daher noch nicht den tieferen Nutzen, Fahrzeugsensoren egel welcher Ausprägung in OSM zu erfassen. Tom Frau Klemm wrote on 2015-05-30 11:40: Hallo Zusammen, ich wollte fragen, ob ein Tag für Fahrrad-Zählstellen gibt? Ich bin heute mit dem Rad in Berlin unterwegs gewesen und hab einige Zählstellen gefunden, die auf dem Radweg eingelassen wurden. Siehe link: https://www.dropbox.com/s/ifuzc8yd2a5ki5f/IMG_20150530_093503.jpg?dl=0 http://www.rbb-online.de/panorama/beitrag/2015/03/berliner-radfahrer-werden- kuenftig-elektronisch-erfasst.html Könnt Ihr mir da weiterhelfen? Viele Grüße Robert ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk-ie] Water depth in lake
Hi, This is potentially life or death information, so I'm not sure if it is approved for OSM. Different datums (measurements) are used: http://en.wikipedia.org/wiki/Chart_datum However, with lakes, you might find novel effects on water depth, like flows from higher rivers / lakes, reservoirs, currents, etc. Colm --- Never doubt that a small group of thoughtful, committed citizens can change the world. Indeed, it is the only thing that ever has. Margaret Mead Message: 2 Date: Fri, 29 May 2015 15:10:51 +0100 From: Daniel Cussen d...@post.com To: Discussion of OpenStreetMap in Ireland talk-ie@openstreetmap.org Subject: Re: [OSM-talk-ie] Water depth in lake 3) Depth is normally displayed on maps as mean tide level (I think), are you taking into account tide (off shore) or recent rain for rivers to calculate the actual depth below mean level? ___ Talk-ie mailing list Talk-ie@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ie
Re: [Talk-at] Public Transport Schema und Wien
Am 30.05.2015 um 18:58 schrieb Robin Däneke: OK. Habe den *33A* jetzt so angepasst, dass er sowohl stop und platform hat, und im Overpass richtig ist. Passt das so? Bei der stop_position gehört noch ein bus=yes. Ansonsten ist mir beim schnellen drüber schauen nichts aufgefallen. Außer natürlich, daß die Hin- und die Rückfahrt jeweils in eine eigene Relation gehört. ;-) Aber das muß nicht sofort geändert werden. LG, Christian ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-GB] Data Model for Address
On 30/05/15 09:00, SK53 wrote: However, there is a British Standard for addresses, which I'm told by those who know it well provides a high degree of flexibility for the numerous cases which do not reflect housenumber, supplement, street, place model. There is a standard for identifying any property in the UK http://www.iahub.net/docs/1398672866952.pdf This is used by every UK council to provide the data free of charge, but we are not then allowed to use it freely :( -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-at] aufgeteilte Straßen wieder vereinen
Hast du mal versucht - natürlich ohne hochzuladen- einfach beide Ways im Josm zu vereinigen? Josm bringt das dann mit den Relationen selber in Ordnung, wenn sonst nicht geändert wurde. Gruss walter On 30.05.2015 17:48, Christian Aigner wrote: Hallo! Ich bin gerade dabei, den Liesinger Platz wieder zu reparieren. Dort wurde z.B. die B13a aufgeteilt, obwohl gar keine bauliche Trennung irgend einer Art vorhanden ist. Beim Auftrennen wurden jede Menge Bus-Relationen kaputt gemacht. Ich möchte das jetzt wieder reparieren. ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Public Transport Schema und Wien
OK. Habe den 33A jetzt so angepasst, dass er sowohl stop und platform hat, und im Overpass richtig ist. Passt das so? ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-cz] Nove preklady wiki
Ahoj, k úpravě wiki (pokud ji mám udělat jako rozšíření dosavadní práce) bych potřeboval nějakou širší shodu komunity. Pochopil jsem, že by se mělo jednat o změnu ve smyslu nepoužíváme kombinaci noexit=no(https://wiki.openstreetmap.org/wiki/Tag:noexit%3Dno) a fixme (https://wiki.openstreetmap.org/wiki/Cs:Key:fixme)=continue (https://wiki.openstreetmap.org/w/index.php?title=Tag:fixme%3Dcontinueaction=editredlink=1) ale pouze fixme(https://wiki.openstreetmap.org/wiki/Cs:Key:fixme)=continue (https://wiki.openstreetmap.org/w/index.php?title=Tag:fixme%3Dcontinueaction=editredlink=1) , protože značka noexit=no (https://wiki.openstreetmap.org/wiki/Tag:noexit%3Dno) je zastaralá, neboť a tady bych asi chtěl poradit nějaký jasný postoj, rozhodnutí, odkaz... vop -- Původní zpráva -- Od: Martin Švec - OSM o...@maatts.cz Komu: talk-cz@openstreetmap.org Datum: 30. 5. 2015 14:32:00 Předmět: Re: [Talk-cz] Nove preklady wiki On 29.5.2015 23:56, Marián Kyral wrote: Dne 29.5.2015 v 23:21 Martin Švec - OSM napsal(a): Ahoj, koukám do Osmose a co nevidím... Najednou se mu nelíbí moje noexit=no tagy. Po chvíli jsem našel, že v [1] byla hodnota noexit=no opravdu už dávno prohlášena za zastaralou, hmmm. Z diskuse na wiki není ten závěr tak jednoznačný, nicméně anglická verze [2] se o možnosti noexit=no taky nezmiňuje. Tušíte někdo kudy se dostávají pravidla do Osmose? Pokud je všeobecná shoda že noexit=no je zastaralé, měla by se upravit i česká wiki. A já se naučím používat jen fixme=continue :-) Commit na githubu: https://github.com/osm-fr/osmose-backend/commit/faf16aebcb2f26e34be04f 891504ad1bce02ebb3 A Trac je tady: http://trac.openstreetmap.fr/ticket/608 (bohužel většina je francouzky :-( ) Marián Dík za nasměrování. Chybu noexit=no Osmose tahá přímo z wiki Deprecated_ features, viz např. https://github.com/osm-fr/osmose-backend/commit/5acae8f715338f57277265a667da 15d1d1c61207 V květnu proběhl úklid stránky Deprecated_features, noexit=no se tam dostal 18.5. prý ze seznamu abandoned a inactive tags: http://wiki.openstreetmap.org/w/index.php?title=Template:Deprecated_features diff=prevoldid=1180184 Dále, nerealizovaný návrh pravidel v JOSM (a výživná diskuse na tagging listu :-)): https://josm.openstreetmap.de/ticket/9895 https://lists.openstreetmap.org/pipermail/tagging/2014-April/017247.html Můj osobní závěr: noexit=no by se neměl používat, preferuje se fixme= continue. Tag noexit=yes na cestách je dlouhodobě sporný, líbí se mi současný výklad na české wiki. Doporučuji upravit wiki ve smyslu, že noexit= no je zastaralé a pro označení nedomapované cesty se má použít pouze fixme= continue na posledním známém uzlu. Martin ___ 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-de] waterway=riverbank
Am 29.05.2015 06:25, schrieb Markus: Das würde ein weltweites Tagging-Schema zerstören... Wer weiss Genaueres? Das geht auf ein erfolgreiches Proposal von 2011 zurück: http://wiki.openstreetmap.org/wiki/Proposed_features/Water_details ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-at] Public Transport Schema und Wien
Passt der 33a jetzt? Wenn ja, dann werde ich sobald wie möglich alle Linien so anpassen...___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [OSM-talk] Can wikidata links help fight name inflation?
We've got beautiful name:LANGUAGE tags, they work, I say let's use them. The English speaking community is well started into this practice (just look at the 1.3 million name:en tags [1]!) - now let's have the rest of us get in on the fun too ;-) Frederik's called upon the local-first rule a couple of times. It's a really useful principle for deciding conflicting edits, and I read it as local observation wins. This is good, but it shouldn't mean if you can't read the name of a thing at its place in a specific language it doesn't have one - just like so many other things that aren't labeled in the real world in the local language. In regards to relying on Wikidata for translations: OpenStreetMap is so much bigger than the people who pay attention to the mailing list. If we changed the standing practice of name:LANGUAGE tags and punted translations to Wikidata - how would the average mapper know about it? Would we write Wikidata integration for iD and JOSM to allow for seamless editing of Wikidata translations, then migrate name:LANGUAGE tags off to Wikidata? This seems a lot of effort for unclear gain. [1] Others have already compared the usage of name:en vs name:ru http://taginfo.openstreetmap.org/search?q=name%3Aen http://taginfo.openstreetmap.org/search?q=name%3Aru On Fri, May 29, 2015 at 8:27 AM, SomeoneElse li...@atownsend.org.uk wrote: On 29/05/2015 12:58, moltonel 3x Combo wrote: On 29/05/2015, SomeoneElse li...@atownsend.org.uk wrote: I'd say that whether or not a name is actually usable to help navigate to a place is a pretty important piece of information. True. And that what name should give you. The name:CC tags should not be a hindrance, at most they should be given alongside name by your satnav. For example, when processing OSM data for my own use I'll try and drop unsigned names and refs from roads (there's no point in saying turn left on Foo Street if Foo Street does not appear on the sign). That's really neat. How do you know wether a street is signposted or not ? I don't know of any tag that gives that info. I can't imagine a good heuristic using name:CC. I've added quite a few unsignposted street names by asking locals. I've used name:signed=no (though this is by no means an accepted tag, and if anyone can come up with a more accepted version that does the same job I'm all ears). Maybe something like name:signed=en;cy might solve the name verifiability problem for Abergavenny? It's the same principle here - if there are 300 names for a place, are you really suggesting that I have to do an external check to some other database to find that as it's in South Wales, signs are likely to be in Welsh and English, so it's those language names that I need to look out for? What's wrong with name ? What's the UK policy on the content of name for places with Welsh and English names ? If you want to see Welsh names as often as possible but still make the local name more prominent, use local name (welsh name if different) in your map generating script. The problem here is that there are two* equally valid and correct names (in on-the-ground verifiable terms) for Abergavenny. Obviously there are more complicated places too - http://www.openstreetmap.org/node/52241235 and http://www.openstreetmap.org/node/267762522 immediately sprung to mind (re the former I thought that it was An Daingean that appeared on the official signs these days?). Cheers, Andu * or possibly three if you count Latin. It wouldn't surprise me if that wasn't on a Welcome to Abergavenny sign somewhere. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-at] Versatz geoimage vs. basemap
On 30.05.2015 19:58, grubernd wrote: On 2015-05-30 16:00, Flaimo wrote: Welches Bildmaterial ist hier aber wirklich exakt? Soll ich jetzt jedes Mal den Basemap-Layer vorher manuell zurechtschieben? Oder besteht die Chance, dass die neuen geoimage-Bilder dann besser sind? Dann würde ich noch mit größeren Änderungen warten... Flaimo, du wirst am besten wissen, was in deiner Gegend am exaktesten ist. Im Normalfall würde ich aber die Orthofotos von geoimage.at als Referenz annehmen, sofern sie einigermaßen senkrecht aufgenommen wurden (also in den Häusern, Bäumen usw. keine Perspektive erkennbar ist). Wenn die alten geoimage.at-Orthofotos anders liegen als die anderen, ist das schon fast ein Wunder. Um kleine Fehler zu bestimmen, müsste man mit amtlichen Vermessungspunkten (z.B. KT-Steine) vergleichen, deren genaue Koordinaten das BEV aber leider geheim hält. Die nächstbeste Alternative wäre ein Vergleich mit einem genauen Laserscan, der für OÖ aber ebenfalls nicht verfügbar ist (siehe anderen Thread). Ansonsten bleibt noch der Vergleich mit GPS-Tracks und anderen Orthofotos. meiner Erfahrung nach stimmen die Lagepositionen von Gebäuden in der Basemap nur bedingt und sind keine verlässliche Quelle. genauso wie deren Hausnummern usw... leider. Das hängt vom Bundesland ab. In Wien stimmen die Gebäude einigermaßen. Aber auch nicht immer. Aufs Orthofoto muss man beim Nachzeichnen immer schauen, die Basemap eignet sich nur zur Kontrolle, oder wenn man am Orthofoto was nicht genau erkennen kann (Perspektive, Schatten o.ä.). wo in der Basemap die einzelnen Daten herkommen würde ich wirklich gerne wissen Die kommen m.W. alle aus amtlichen Datenbeständen der Bundesländer. Mich wundert nicht, dass die so viel Müll in den Datenbeständen haben. Das ist überall so, wo es Daten gibt. Mich wundert aber, dass die den Müll so ungeniert in die Basemap reingeschüttet haben. Mein Verdacht ist, dass sie nur die miesen Daten kostenlos zur Verfügung stellen wollen, die genauen Daten gibts - so wie früher auch schon - gegen Cash. dagegen sind die Orthofotos von geoimage.at selbst im dreidimensionalen Gelände in den Bergen so perfekt korrigiert, dass man sich fragt ob die zaubern können. andrerseits machen die das auch schon länger.. ;) Sie können leider nicht zaubern. In den Bergen sowieso nicht, und sogar im Flachland gibt es immer wieder haarsträubende Diskrepanzen wie z.B. hier: http://www.openstreetmap.org/node/1149650422 aber wenn man sich mal die ÖK/AMAP anschaut, dann merkt man, dass eine perfekte Karte nicht unbedingt auf den Millimeter exakt sein muss Kommt auf den Mapstab an. Aber ich stimme dir zu, dass die Amap in kleinen Mapstäben besser aussieht als alle OSM-Karten. Gründe sind vor allem die nichtinterpolierten 20m-Höhenlinien und die dezenteren Flächensignaturen. -- 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
[Talk-TW] 2015 OpenStreetMap臺北聚會第二彈！6/8(一) 摩茲工寮
各位好： 2015年重啟的臺北聚會要來第二次了 6/8(一) 19:30~21:30 在八德路一段94號3樓的摩茲工寮 (https://moztw.org/space/) 之後臺北聚會將固定每月第二個週一晚上，在摩茲工寮聚會 這次將會針對一些難解的問題－臺南公園一起討論怎麼處理，並且動手修改 Hackpad討論 https://osmtw.hackpad.com/2015-06-08-Taipei-OpenStree tMap-Meetup-note-mPslv9FYZUN 目前也開了臉書活動，歡迎協助宣傳 https://www.facebook.com/events/396243120562780/ Supaplex/Dennis ___ Talk-TW mailing list Talk-TW@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-tw
Re: [Talk-de] Tag für Fahrradzählstellen
Am 30.05.2015 um 22:37 schrieb Tom Pfeifer: Hallo Frau Robert Klemm, bevor wir einen Tag erfinden sollten wir überlegen, ob wir diese Dinge überhaupt mappen wollen. Auch wenn es von den Fahrradsensoren erst ein paar Handvoll gibt -- Fahrzeugsensoren, als Induktionsschleifen oder als Bewegungsmelder von oben, gibt es ja schon zuhauf, an vielen Kreuzungen je ankommende Spur, und unterwegs auch noch genug. Selbst die Vorschläge, die Ampellichter pro Spur zu erfassen sind bisher nicht übermässig erfolgreich, ich sehe daher noch nicht den tieferen Nutzen, Fahrzeugsensoren egel welcher Ausprägung in OSM zu erfassen. Allein schon mal um einen Eindruck davon zu bekommen was wo erfasst wird. Ein Gesamtbild vermittelt einen anderen Eindruck als das Wissen über das Vorhandensein einzelner Sensoren. Letztenendes geht es bei den Sensoren auch um politische Zwecke. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk-fr] tag et point-virgule
Ca dépend lesquelles. Pour name=* ou name:lang=* (ou wikipedia=* ou wikipedia:lang=*) par exemple il ne faut qu'une seule valeur. Mais en revanche pour alt_name=* ou alt_name:lang=* sont faits pour stocker des valeurs supplémentaires, et il me parait valide d'en mettre plusieurs séparées par point-virgule : ces tag alt_name sont justement faits pour ça: stocker ce qu'on ne met pas dans name=*. Il me semble aussi que loc_name=* et loc_name:lang=* pourrait aussi avoir plusieurs noms car le seul critère de code langue n'est pas suffisant pour les distinguer et il n'y a pas de critère précis en dehors de l'indication d'un usage local qui peut lui aussi avoir des alternatives (particulièrement dans des pays ou des langues sans orthographe réellement officialisée : on écrit un peu comme on prononce, et il y a aussi des petites différences dialectales même au plan local et dans une même langue). Même dans des pays ayant des agences officielles, on trouve aussi des variantes orthographiques selon les agences (géographiques, électorales, statistiques/démographiques, différents ministères, organismes publics divers...). Ce n'est pas aussi strict qu'on le voit en France (ou existe pourtant aussi des variantes) sans qu'on puisse réelleement savoir laquelle variante est la plus officielle. Tant que les diférences sont réduites à l'absence ou la présence d'accent, on peut garder la version accentuée (mais on trouve couramment des différences d'accents, notamment en Afrique où les tononymes francophones hésitent très souvent entre accent aigu et accent grave, du fait de la présence aussi d'autres langues africaines très courantes localement, comme le bambara et d'autres). Nombre de pays africains sont polyethniques, les langues sont nombreuses (et même quand la langue française est officielle, elle ne l'est que pour une partie du gouvernement et minoritaire ailleurs dans la population, le français ou l'anglais étant seulement utilisés de facto comme langue d'échange, plus ou moins bien maitrisée et localement très créolisée avec les langues indigènes. Même là-bas pour ceux qui défende un français très épuré, pour éviter la multiplication des créoles mais aussi préserver les langues locales, ils s'adaptent aussi à des variantes orthographiques et de prononciation sur la toponymie et les noms propres en général, et ils sont conscients que tout le monde autour ne connait pas ce français ou anglais épuré (que même nous en France ou au Royaume-Uni ne connaissont plus aussi bien, ou pouvons considérer parfois comme des formes archaïques.) Le 29 mai 2015 09:59, bernard bernard.a...@laposte.net a écrit : Bonjour, J'ai remarqué qu'Osmose n'appréciait pas que les valeurs soient séparées par des point-virgules. Or, des pages wiki le proposent Qu'en est-il? Il est mentionné dans la FAQ http://wiki.openstreetmap.org/wiki/FR:FAQ Valeur avec ou sans point-virgule? Merci de votre réponse Bernard --- L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast. http://www.avast.com ___ 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] Cépages ?
Bonsoir, Merci pour vos réponses. Je vais fouiller les pistes suggérées Amicalement Laurent Le 29 mai 2015 16:12, Francescu GAROBY windu...@gmail.com a écrit : crop=grape http://wiki.openstreetmap.org/wiki/Tag:crop%3Dgrape existe, mais c'est pour du raisin, en général. Donc pas pour spécifier le cépage. Par contre, bien que les cépages ne rentrent pas dans les classifications biologiques http://fr.wikipedia.org/wiki/C%C3%A9page#Classification_botanique, peut-être faudrait-il s'inspirer de cette hiérarchie des tags existante (species, genus, taxon) pour classer les cépages et leur famille d'appartenance ? Francescu Le 29 mai 2015 15:51, dHuy Pierre dh...@yahoo.fr a écrit : Le Tag crop semble correspondre à ton besoin même si actuellement aucun usage n'en ai fait pour cartographier les cépages.L'usage d'un crop:type me paraîtrait bien aussi mais sans aucun fondement. Si tu trouves une solution meilleure tiens nous au courant :) Le Vendredi 29 mai 2015 12h32, Laurent Chiche rop...@gmail.com a écrit : Bonjour, Quelqu'un sait-il s'il est possible d'indiquer les cépages des vignes et quels attributs utiliser ? J'ai cherché, mais rien trouvé à ce sujet dans le wiki. Merci Amicalement Laurent ___ 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 -- Francescu ___ 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] Cépages ?
Remarque aussi applicables aux élevages animaux (la plupart des genres d'animaux domestiques ne sont pas des espèces distinctes, juste le fruit de sélections au sein d'une même espèce (par exemple les races de chiens, bon nombre de races de vaches (limousine, etc...), ce qui n'interdit pas du tout les croisements (qui existent encore malgré tout pour préserver la richesse génétique et permettre de nouvelles sélections pouvant résister à certaines maladies par exemple). Idem pour bon nombre de cultivars floraux (même si certains hybrides ne sont même pas reproducteurs) et de céréales (la plupart des surfaces cultivées aujourd'hui dans nombre de pays européens et américains sont avec des semences hydrides rendues volontairement infertiles. Cf. Monsanto), ou variétés fruitières et légumières normalisées du catalogue européen autorisé à la vente (tomates, pommes de terre, choux, pommes) au point que les espèces traditionnelles et même les sélections naturelles (non hybrides) se voient retirées des catalogues autorisés à la vente (un comble !) pour le seul motif qu'elles ne sont pas calibrées ou peuvent être habitées par certains insectes (pourtant pas nuisibles du tout à la santé): Ces espèces naturelles (même sélectionnées depuis des siècles pour s'adapter à un terroir de culture) sont pourtant tout à fait vendables en circuit court et bien meilleures (et nutritivement plus riches que les fruits vendus aujourd'hui qui n'ont presque plus rien en vitamines, minéraux, huiles essentielles, arômes, antioxydants...), leur seul défaut étant leur moins grande conservation et moins de résistance au transport (pour la vente internationale en circuit long) ou la réfrigération (afin de permettre de les cueillir avant maturité et les conserver pendant des semaines ou des moins et les faire mûrir artificiellement à la demande et hors saison), mais en revanche alors que les hybrides déclenchent des épidémies d'allergies alimentaires et de nouvelles malnutritions du fait de leur grande pauvreté alimentaire, et épuisent les sols (ou demandent des quantités énormes d'engrais et de traitements chimiques nuisibles à notre santé et à l'environnement). Le 31 mai 2015 01:29, Philippe Verdy verd...@wanadoo.fr a écrit : les cépages ne sont peut-être pas des espaces mais des variétés de type cultivar la hiérarchisation devrait être utilisable, remplacer taxon par cultivar... Le 29 mai 2015 16:11, Francescu GAROBY windu...@gmail.com a écrit : crop=grape http://wiki.openstreetmap.org/wiki/Tag:crop%3Dgrape existe, mais c'est pour du raisin, en général. Donc pas pour spécifier le cépage. Par contre, bien que les cépages ne rentrent pas dans les classifications biologiques http://fr.wikipedia.org/wiki/C%C3%A9page#Classification_botanique, peut-être faudrait-il s'inspirer de cette hiérarchie des tags existante (species, genus, taxon) pour classer les cépages et leur famille d'appartenance ? Francescu Le 29 mai 2015 15:51, dHuy Pierre dh...@yahoo.fr a écrit : Le Tag crop semble correspondre à ton besoin même si actuellement aucun usage n'en ai fait pour cartographier les cépages.L'usage d'un crop:type me paraîtrait bien aussi mais sans aucun fondement. Si tu trouves une solution meilleure tiens nous au courant :) Le Vendredi 29 mai 2015 12h32, Laurent Chiche rop...@gmail.com a écrit : Bonjour, Quelqu'un sait-il s'il est possible d'indiquer les cépages des vignes et quels attributs utiliser ? J'ai cherché, mais rien trouvé à ce sujet dans le wiki. Merci Amicalement Laurent ___ 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 -- Francescu ___ 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
[OSM-talk] Craigslist OpenStreetMap Rendering Issue
I have posted this issue to the Craigslist feedback forum, but I also thought I would post it here to see if anyone has a specific contact at Cragislist that handles their map rendering. They use - and credit - OpenStreetMap (which is wonderful), but I believe they perform their own custom rendering, which seems to be the source of this issue. The issue is that some streets that are not one way in OSM data, are rendered as one way by Craigslist. If you go to this ad and zoom in on the map you will see the arrows designating one way streets, for example on Cliffrose Way ( https://www.openstreetmap.org/way/170048276): https://fortcollins.craigslist.org/gms/4991940913.html Here is the approximate area on the default OSM map: https://www.openstreetmap.org/#map=17/40.51930/-104.85951 I looked at the data and all of the streets in question seem to be tagged oneway=no. Admittedly this tag is rather superfluous in these cases - or at least I believe it is, I am not the one that added it, but it shouldn't be interpreted as indicating a one way street. I could remove this tag, but I feel this would be tagging for the renderer (actually someone else's renderer), and there may be legitimate cases for using oneway=no on a way representing a street somewhere else. Why care? I would imagine to the majority of the users make no distinction between OpenStreetMap and Craigslist's rendering of OpenStreetMap, if the map is wrong, to them that simply means that OpenStreetMap is wrong. Mike ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-ie] Water depth in lake
Could you use height info from the GPS? Would it be good enough to calculate depth below sea level at that point? GPS height might take into account variable water height? ___ Talk-ie mailing list Talk-ie@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ie
Re: [OSM-talk-fr] Cépages ?
les cépages ne sont peut-être pas des espaces mais des variétés de type cultivar la hiérarchisation devrait être utilisable, remplacer taxon par cultivar... Le 29 mai 2015 16:11, Francescu GAROBY windu...@gmail.com a écrit : crop=grape http://wiki.openstreetmap.org/wiki/Tag:crop%3Dgrape existe, mais c'est pour du raisin, en général. Donc pas pour spécifier le cépage. Par contre, bien que les cépages ne rentrent pas dans les classifications biologiques http://fr.wikipedia.org/wiki/C%C3%A9page#Classification_botanique, peut-être faudrait-il s'inspirer de cette hiérarchie des tags existante (species, genus, taxon) pour classer les cépages et leur famille d'appartenance ? Francescu Le 29 mai 2015 15:51, dHuy Pierre dh...@yahoo.fr a écrit : Le Tag crop semble correspondre à ton besoin même si actuellement aucun usage n'en ai fait pour cartographier les cépages.L'usage d'un crop:type me paraîtrait bien aussi mais sans aucun fondement. Si tu trouves une solution meilleure tiens nous au courant :) Le Vendredi 29 mai 2015 12h32, Laurent Chiche rop...@gmail.com a écrit : Bonjour, Quelqu'un sait-il s'il est possible d'indiquer les cépages des vignes et quels attributs utiliser ? J'ai cherché, mais rien trouvé à ce sujet dans le wiki. Merci Amicalement Laurent ___ 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 -- Francescu ___ 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] Craigslist OpenStreetMap Rendering Issue
On 31/05/2015 10:51 AM, Mike Thompson wrote: I have posted this issue to the Craigslist feedback forum, but I also thought I would post it here to see if anyone has a specific contact at Cragislist that handles their map rendering. They use - and credit - OpenStreetMap (which is wonderful), but I believe they perform their own custom rendering, which seems to be the source of this issue. The issue is that some streets that are not one way in OSM data, are rendered as one way by Craigslist. If you go to this ad and zoom in on the map you will see the arrows designating one way streets, for example on Cliffrose Way (https://www.openstreetmap.org/way/170048276): https://fortcollins.craigslist.org/gms/4991940913.html Here is the approximate area on the default OSM map: https://www.openstreetmap.org/#map=17/40.51930/-104.85951 I looked at the data and all of the streets in question seem to be tagged oneway=no. Admittedly this tag is rather superfluous in these cases - or at least I believe it is, I am not the one that added it, but it shouldn't be interpreted as indicating a one way street. I could remove this tag, but I feel this would be tagging for the renderer (actually someone else's renderer), and there may be legitimate cases for using oneway=no on a way representing a street somewhere else. Why care? I would imagine to the majority of the users make no distinction between OpenStreetMap and Craigslist's rendering of OpenStreetMap, if the map is wrong, to them that simply means that OpenStreetMap is wrong. I'd remove it. Redundant information - data base bloat. Like vehicle=yes on a motorway ... Perhaps these could be candidates for a mechanical clean up? ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Craigslist OpenStreetMap Rendering Issue
I've seen this topic being discussed here or elsewhere in the past. I thought that the consensus was that in some area's (a Spanish town I believe), it was ok to leave the oneway=no. The reasoning was that most streets in that town were oneway=yes, and the oneway=no was used to indicate that this road was surveyed and and an exception to the oneway=yes. so a world-wide mechanical edit should not be performed. regards m On Sun, May 31, 2015 at 3:22 AM, Warin 61sundow...@gmail.com wrote: On 31/05/2015 10:51 AM, Mike Thompson wrote: I have posted this issue to the Craigslist feedback forum, but I also thought I would post it here to see if anyone has a specific contact at Cragislist that handles their map rendering. They use - and credit - OpenStreetMap (which is wonderful), but I believe they perform their own custom rendering, which seems to be the source of this issue. The issue is that some streets that are not one way in OSM data, are rendered as one way by Craigslist. If you go to this ad and zoom in on the map you will see the arrows designating one way streets, for example on Cliffrose Way ( https://www.openstreetmap.org/way/170048276): https://fortcollins.craigslist.org/gms/4991940913.html Here is the approximate area on the default OSM map: https://www.openstreetmap.org/#map=17/40.51930/-104.85951 I looked at the data and all of the streets in question seem to be tagged oneway=no. Admittedly this tag is rather superfluous in these cases - or at least I believe it is, I am not the one that added it, but it shouldn't be interpreted as indicating a one way street. I could remove this tag, but I feel this would be tagging for the renderer (actually someone else's renderer), and there may be legitimate cases for using oneway=no on a way representing a street somewhere else. Why care? I would imagine to the majority of the users make no distinction between OpenStreetMap and Craigslist's rendering of OpenStreetMap, if the map is wrong, to them that simply means that OpenStreetMap is wrong. I'd remove it. Redundant information - data base bloat. Like vehicle=yes on a motorway ... Perhaps these could be candidates for a mechanical clean up? ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Keulen (was Re: Can wikidata links help fight name inflation?)
Hi, first of all, I appreciate the ongoing work of the DWG in general and Fredrik in particular to detect, discuss, and handle mass edits resembling mechanical edits. I will get to them in a separate thread. What I would not support in OSM, and like to outsource to Wikidata or other, is if speakers of these 20 languages were to start assigning name tags in their language to thousands of places in, say, the UK. Where do you draw the limit? [...] Yes, I've thought about that; name:en is very useful for me but ultimately, if the locals don't use it, then it isn't on the ground, and then it shouldn't be in OSM really. I happened to drive through Belgium a few days ago, heading home. A good approximation of home in this case is name=Köln. Actually, I found a street sign (150 km away from Köln) that reads Keulen. Should I have followed it or not? Luckily, in the offline database on my device, the object with name=Köln had a tag name:nl=Keulen. So I know that the sign is referring to my desired destination. Please note that - I had no internet connectivity in that situation, hence wikidata, any other external database or even non-copied OSM data was not an option. - I'm not citing the English name of the object in this mail to avoid redundancy. Is it worth it? - No street sign within the extend of the object name=Köln displays Keulen, hence it is not on the [local] ground. - Not even a street sign within the Netherlands does display Keulen (although associated with ISO code nl). They show Köln. - I myself live slightly outside the cultural perimeter of Köln, seen from Köln themselves. Hence, I might be called non-local in a borderline strict sense. So in total: Is it really a gain to remove all name:XX tags from Köln? And do we want to discuss such cases again and again with overzealous self-appointed curators? Please note, the DWG does recognize when the on-the-ground rule is a rule of thumb, but others with an OSM account might not. I opt for: If a human mapper decides that it is worth adding name:XX to an object then let him/her do so. All annoying cases are covered by the mechanical edit policies, we don't need extra strict rules for name tags. Best regards, Roland ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-GB] Data Model for Address
Hi Jerry, ...or we identify use cases we want to handle (and thereby take a conscious decision to de-scope other use cases), and ensure that our model is fit for (our) purpose. Then map the official data model onto the internal model. This mapping will probably be a one-way mapping, i.e. it is unlikely to be possible to go from the (simplified) OSM model back to the standard model in a reliable way. I found this paper (2003) which shows some more of the vagaries of the system. There is a short section on BS7666. It's a few years old now so things have moved on a bit, but I reckon a significant part still holds true. http://www.knowedge.co.uk/Papers/Addressing_in_Britain.pdf [3] Cheers, Colin On 2015-05-30 10:00, SK53 wrote: If the world is complicated it may be necessary to reflect that in the data model (or alternatively make the data model so general that complications are pushed to applications). I think the Royal Mail approach to addresses is already too Procrustean! However, there is a British Standard for addresses, which I'm told by those who know it well provides a high degree of flexibility for the numerous cases which do not reflect housenumber, supplement, street, place model. Jerry On 29 May 2015 at 15:26, Colin Smale colin.sm...@xs4all.nl wrote: If anyone is interested in the data model used by Royal Mail in UK addresses, this will tell you loads: http://www.poweredbypaf.com/wp-content/uploads/2015/02/Latest-Programmers_guide_Edition-7-Version-6.pdf [1] Warning: you may find yourself uttering things in rather unparliamentary language when you read this. Contrast this with the Dutch address model: Street, Housenumber (numeric), Housenumber Extension (alphanumeric), Postcode (XX) and Town. Probably much the same in Belgium and Germany too. //colin ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb [2] Links: -- [1] http://www.poweredbypaf.com/wp-content/uploads/2015/02/Latest-Programmers_guide_Edition-7-Version-6.pdf [2] https://lists.openstreetmap.org/listinfo/talk-gb [3] http://www.knowedge.co.uk/Papers/Addressing_in_Britain.pdf ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [OSM-talk] Keulen (was Re: Can wikidata links help fight name inflation?)
Hi, On 05/30/2015 08:59 AM, Roland Olbricht wrote: Please note that - I had no internet connectivity in that situation, hence wikidata, any other external database or even non-copied OSM data was not an option. Well: The data on your device will most certainly have been preprocessed; you weren't using a raw .osm.pbf file. Whoever does the preprocessing is of course free to join OSM data with any other database; so if for example we agreed that Wikidata was our name repository of choice and we'd reduce our own name:xx tagging to what is used by the people living in a place, then there would have been a wikidata tag on the Köln node and the software that generated your offline database could have made a choice whether, and to what degree, to include the Wikidata name catalogue in your offline data set. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Keulen (was Re: Can wikidata links help fight name inflation?)
2015-05-30 8:59 GMT+02:00 Roland Olbricht roland.olbri...@gmx.de: Hi, first of all, I appreciate the ongoing work of the DWG in general and Fredrik in particular to detect, discuss, and handle mass edits resembling mechanical edits. I will get to them in a separate thread. What I would not support in OSM, and like to outsource to Wikidata or other, is if speakers of these 20 languages were to start assigning name tags in their language to thousands of places in, say, the UK. Where do you draw the limit? [...] Yes, I've thought about that; name:en is very useful for me but ultimately, if the locals don't use it, then it isn't on the ground, and then it shouldn't be in OSM really. I happened to drive through Belgium a few days ago, heading home. A good approximation of home in this case is name=Köln. Actually, I found a street sign (150 km away from Köln) that reads Keulen. Should I have followed it or not? Luckily, in the offline database on my device, the object with name=Köln had a tag name:nl=Keulen. So I know that the sign is referring to my desired destination. The values used in the destination tag ( http://wiki.openstreetmap.org/wiki/Key:destination) should always display the exact name as it is shown on the signpost Please note that - I had no internet connectivity in that situation, hence wikidata, any other external database or even non-copied OSM data was not an option. - I'm not citing the English name of the object in this mail to avoid redundancy. Is it worth it? - No street sign within the extend of the object name=Köln displays Keulen, hence it is not on the [local] ground. - Not even a street sign within the Netherlands does display Keulen (although associated with ISO code nl). They show Köln. - I myself live slightly outside the cultural perimeter of Köln, seen from Köln themselves. Hence, I might be called non-local in a borderline strict sense. So in total: Is it really a gain to remove all name:XX tags from Köln? And do we want to discuss such cases again and again with overzealous self-appointed curators? Please note, the DWG does recognize when the on-the-ground rule is a rule of thumb, but others with an OSM account might not. I opt for: If a human mapper decides that it is worth adding name:XX to an object then let him/her do so. All annoying cases are covered by the mechanical edit policies, we don't need extra strict rules for name tags. Best regards, Roland ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-GB] Data Model for Address
If the world is complicated it may be necessary to reflect that in the data model (or alternatively make the data model so general that complications are pushed to applications). I think the Royal Mail approach to addresses is already too Procrustean! However, there is a British Standard for addresses, which I'm told by those who know it well provides a high degree of flexibility for the numerous cases which do not reflect housenumber, supplement, street, place model. Jerry On 29 May 2015 at 15:26, Colin Smale colin.sm...@xs4all.nl wrote: If anyone is interested in the data model used by Royal Mail in UK addresses, this will tell you loads: http://www.poweredbypaf.com/wp-content/uploads/2015/02/Latest-Programmers_guide_Edition-7-Version-6.pdf Warning: you may find yourself uttering things in rather unparliamentary language when you read this. Contrast this with the Dutch address model: Street, Housenumber (numeric), Housenumber Extension (alphanumeric), Postcode (XX) and Town. Probably much the same in Belgium and Germany too. //colin ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-it] open data comune di Verona
Ho sistemato il problema. Grazie! Ciao, Andrea 2015-05-29 18:20 GMT+02:00 Leonardo kinetocor...@gmail.com: Il validatore di JOSM segnala 4 errori legati al tag addr:postcode vuoto. Ciao! Leonardo ___ 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
[OSM-talk-fr] Besoin d'aide pour WeeklyOSM en français
Bonjour, WeeklyOSM est la revue hebdomadaire de tout ce qui passe dans le monde d'OpenStreetMap, sur le site http://www.weeklyosm.eu/. Ces articles sont écrits par la communauté allemande, puis traduits en anglais, et dans d'autres langues encore. Une édition francophone (http://www.weeklyosm.eu/fr) existe depuis le début de l'année... mais je me trouve maintenant seul à traduire (et relire plus ou moins) ces articles qui paraissent chaque semaine. Cela représente une charge d'environ trois à quatre heures, qu'il m'est difficile d'assumer seul en ce moment (pour cause de déménagement), d'autant qu'en l'absence d'une autre personne pour relire, je perds de ma motivation. Participer à WeeklyOSM n'est pas très compliqué, il faut simplement : * une bonne compréhension écrite de l'anglais * savoir écrire de manière correcte et concise en français * et puis connaitre OpenStreetMap en général (et avoir suffisamment de curiosité pour chercher à comprendre les quelques sujets techniques qui viennent parfois s'insérer) J'aurais aimé être présent au SotM-fr, mais je trouve utile de mettre le sujet sur la table. Vous aurez sans doute l'occasion d'en discuter. Bon week-end à tous. -- View this message in context: http://gis.19327.n5.nabble.com/Besoin-d-aide-pour-WeeklyOSM-en-francais-tp5846564.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: [Talk-de] waterway=riverbank
Am 29.05.2015 um 21:04 schrieb Christoph Hormann: Es geht hier nicht um die Erfassung von Strömungen in einem Gewässer und auch nicht darum, dass irgendjemand behauptet, dass waterway=riverbank ein Tag ohne jede Probleme wäre, sondern darum, dass natural=water + water=river eher einen Rückschritt gegenüber dem riverbank-Tagging darstellt. Die genannten Probleme können aber nur dann auftreten, wenn man natural=water ohne water=* verwendet. Da die Angabe von water=* deutlich differenzierter als das alte Schema ist, werde ich diese Möglichkeiten (zumindest teilweise) nutzen. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[OSM-talk] Mechanical name edit? (was Re: Can wikidata links help fight name inflation?)
Hi, Not only well-known tourist magnets carry foreign names; some dedicated language mappers have gone over and beyond the call of duty and added, for example, name:ru tags even to small villages: [..] (This is a matter currently under investigation by Data Working Group and it is relatively certain that not all 582,653 name:ru tags will remain.) Thank you for informing the community. Do you actually have substantial evidence of a mechanical edit or something similar? When checking e.g. Wales http://overpass-turbo.eu/s/9EQ I found a distribution that rather looks like the result of human activity. Even more, the biggest changeset involved http://www.openstreetmap.org/changeset/24593727 has a full discussion attached to it: https://lists.openstreetmap.org/pipermail/talk-gb/2014-August/016294.html When cross-checking with another region (in Northrhine-Westphalia) I found that the name:ru tags there have been added by an even bigger number of different mappers. For some of them, I know personally that they are locals. For example, the stadium in Cologne seems to have got its Russian name when a football match to a Russian team took place. So, could you please point out a suspicious changeset? Best regards, Roland ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Keulen (was Re: Can wikidata links help fight name inflation?)
On 30/05/2015 6:00 PM, Johan C wrote: The values used in the destination tag (http://wiki.openstreetmap.org/wiki/Key:destination) should always display the exact name as it is shown on the signpost When the 'name on the signpost' changes along the way, or by the direction of travel .. what then? --- The more data that is available the better. Some languages are phonetic (Russian, Arabic for instant) so a name correctly stated maybe of some use to gain verbal directions. I see no reason to remove data unless it is incorrect. Data bloat is a problem ... and as OSM grows it will be an increasing problem. Removing data restricts the future of OSM .. where does it stop? Should all highway=track be removed as 'most' people don't use them? Should the number of nodes in a way be restricted to less than 20 per kilometre? The data base should contain all the data. Post processors can remove (filter) as much as they like but not remove data from the data base. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Keulen (was Re: Can wikidata links help fight name inflation?)
On Sat, 2015-05-30 at 11:05 +0100, SomeoneElse wrote: On 30/05/2015 07:59, Roland Olbricht wrote: I happened to drive through Belgium a few days ago, heading home. A good approximation of home in this case is name=Köln. Actually, I found a street sign (150 km away from Köln) that reads Keulen. Should I have followed it or not? A name:xx that's actually used on signposts on the ground (the name of a place in a neighbouring country on a road in that country going to that place) to guide travellers to a place is clearly on the ground verifiable. I used Abergavenny (in a largely English-speaking part of Wales) as a specific example previously to try and separate the commonly used e.g. on signposts names from the translations. I have certainly used signposts as verification of name:cy=Eglwys Wen, name:cy=Croesoswallt, name:cy=Yr Amwythig and name:cy=Caer. Phil (trigpoint) ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Mechanical name edit? (was Re: Can wikidata links help fight name inflation?)
On Sat, 2015-05-30 at 20:55 +1000, Warin wrote: On 30/05/2015 8:41 PM, Roland Olbricht wrote: Hi, On 05/30/2015 09:48 AM, Roland Olbricht wrote: Thank you for informing the community. Do you actually have substantial evidence of a mechanical edit or something similar? There are a couple individual complaints and license issues (people taking names from a collection of military maps published in Russia in 2008, or from Wikipedia which is CC-BY-SA licensed). Quite a few users have already been blocked about mass-adding name:ru in the past (eg http://www.openstreetmap.org/user_blocks/563). Thank you. Reading the text of this block I too now understand the name:ru 'problem', no so much 'inflation' but possible licence infringement. Many of the places involved are unlikely to be well known in Russia and have a Russian name, some were unknown to most of us in GB. Abergavenny as an example is not a large city, it is a small market town in rural Wales. It is not a major centre of either commerce or international tourism. Phil (trigpoint) ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[Talk-de] Tag für Fahrradzählstellen
Hallo Zusammen, ich wollte fragen, ob ein Tag für Fahrrad-Zählstellen gibt? Ich bin heute mit dem Rad in Berlin unterwegs gewesen und hab einige Zählstellen gefunden, die auf dem Radweg eingelassen wurden. Siehe link: https://www.dropbox.com/s/ifuzc8yd2a5ki5f/IMG_20150530_093503.jpg?dl=0 http://www.rbb-online.de/panorama/beitrag/2015/03/berliner-radfahrer-werden- kuenftig-elektronisch-erfasst.html Könnt Ihr mir da weiterhelfen? Viele Grüße Robert ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-cz] Nove preklady wiki
On 29.5.2015 23:56, Marián Kyral wrote: Dne 29.5.2015 v 23:21 Martin Švec - OSM napsal(a): Ahoj, koukám do Osmose a co nevidím... Najednou se mu nelíbí moje noexit=no tagy. Po chvíli jsem našel, že v [1] byla hodnota noexit=no opravdu už dávno prohlášena za zastaralou, hmmm. Z diskuse na wiki není ten závěr tak jednoznačný, nicméně anglická verze [2] se o možnosti noexit=no taky nezmiňuje. Tušíte někdo kudy se dostávají pravidla do Osmose? Pokud je všeobecná shoda že noexit=no je zastaralé, měla by se upravit i česká wiki. A já se naučím používat jen fixme=continue :-) Commit na githubu: https://github.com/osm-fr/osmose-backend/commit/faf16aebcb2f26e34be04f891504ad1bce02ebb3 A Trac je tady: http://trac.openstreetmap.fr/ticket/608 (bohužel většina je francouzky :-( ) Marián Dík za nasměrování. Chybu noexit=no Osmose tahá přímo z wiki Deprecated_features, viz např. https://github.com/osm-fr/osmose-backend/commit/5acae8f715338f57277265a667da15d1d1c61207 V květnu proběhl úklid stránky Deprecated_features, noexit=no se tam dostal 18.5. prý ze seznamu abandoned a inactive tags: http://wiki.openstreetmap.org/w/index.php?title=Template:Deprecated_featuresdiff=prevoldid=1180184 Dále, nerealizovaný návrh pravidel v JOSM (a výživná diskuse na tagging listu :-)): https://josm.openstreetmap.de/ticket/9895 https://lists.openstreetmap.org/pipermail/tagging/2014-April/017247.html Můj osobní závěr: noexit=no by se neměl používat, preferuje se fixme=continue. Tag noexit=yes na cestách je dlouhodobě sporný, líbí se mi současný výklad na české wiki. Doporučuji upravit wiki ve smyslu, že noexit=no je zastaralé a pro označení nedomapované cesty se má použít pouze fixme=continue na posledním známém uzlu. Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [OSM-talk] Mechanical name edit? (was Re: Can wikidata links help fight name inflation?)
Hi, On 05/30/2015 12:26 PM, Martin Koppenhoefer wrote: as a sidenote for those who plan to study Italian with the aid of osm-talk, München is 'Monaco di Baviera' in Italian ;-) Glad I didn't add that in a name:it tag ;) Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Can wikidata links help fight name inflation?
I find it odd that inaction, incapability or incompetence of local sign installers is a worry for a database of geographical facts, which OSM is. Some roads are hundreds of miles long, at what interval does it need to be signed for it to be considered signed. Beginning and end? Every 100 km? Some streets have signs that are now obscured by trees and bushes. On the ground rule is a rule of thumb, not the entirety of factual truth. People similarly being lax in making sure their homes conform to local rules about address visibility (huge pet peeve of mine since being a paper boy in the 1980s) should not hinder us in giving their homes the proper address in our database of facts. If you wish to use on the ground as the only rule then we can just forget about the whole thing - defeated by inaction of people that should be putting up signs and maintaining them. As for the name inflation, there is no such thing. Illegal imports maybe but name inflation as a problem does not exist. Any talk of too much data by adding an extra name field to a node is defeated soundly by any 3d mapping entity. I've looked at some of the 3D stuff done and it blows my mind how detailed and cool it is, then when I peek at the code behind it I admit defeat in trying to understand it at a glance as it is an intricate series of relations upon relations. A simpler example is Stade de France, fantastic stadium - was there myself at 1998 World Cup. Data bloat can happen, Wikidata is too fragile, we need our own store of data (POI extra details, names, translations etc) that can exchange material with Wikidata but is under full OSMF control - and not controlled by notability deletionists. In 5 years time would we be arguing about bloat in OSMData as someone suddenly purges some section from it? /rambling --Jói / Stalfur Þann 30.5.2015 12:22, skrifaði Martin Koppenhoefer: Am 29.05.2015 um 13:58 schrieb moltonel 3x Combo molto...@gmail.com: That's really neat. How do you know wether a street is signposted or not ? I don't know of any tag that gives that info. there are ~600 visible_name 37000 unsigned_ref 518 unsigned 400 signed 161 name:signed 124 name:sign 86 ref:signed 48 unsigned_name 47 ref:unsigned 16 name:signposted I haven't checked on which kind of objects or which do not refer to highways or names Very likely I also missed some variants It seems that for names nobody cares to say whether they are signposted or not (or maybe only when the sign is different from the actual name), while for ref it seems common practice(?) to use unsigned_ref ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Unsigned road refs (was: Re: Can wikidata links help fight name inflation?)
On 30/05/2015 13:51, Jóhannes Birgir Jensson wrote: I find it odd that inaction, incapability or incompetence of local sign installers is a worry for a database of geographical facts, which OSM is. Why should it be incompetence? Near where I live there's a ring road around a local town. There are no signs indicating the ref of the road because that's not the information that the road planners want to get across. Instead, they'll add the destinations that people actually want to get to, with the ref of that road in brackets. It's not incompetence; it's trying to communicate clearly with road users. Þann 30.5.2015 12:22, skrifaði Martin Koppenhoefer: Am 29.05.2015 um 13:58 schrieb moltonel 3x Combo molto...@gmail.com: That's really neat. How do you know wether a street is signposted or not ? I don't know of any tag that gives that info. there are ~600 visible_name 37000 unsigned_ref 518 unsigned 400 signed 161 name:signed 124 name:sign 86 ref:signed 48 unsigned_name 47 ref:unsigned 16 name:signposted I haven't checked on which kind of objects or which do not refer to highways or names Very likely I also missed some variants It seems that for names nobody cares to say whether they are signposted or not (or maybe only when the sign is different from the actual name), while for ref it seems common practice(?) to use unsigned_ref Looking at the values and distribution, those look to be mainly US-based, where a road can be part of multiple routes. It's a slightly different problem that's being solved there, I think, and again I suspect it's due to the road planners trying to communicate clearly with road users. Cheers, Andy ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Keulen (was Re: Can wikidata links help fight name inflation?)
On Sat, 2015-05-30 at 20:17 +1000, Warin wrote: On 30/05/2015 6:00 PM, Johan C wrote: The values used in the destination tag (http://wiki.openstreetmap.org/wiki/Key:destination) should always display the exact name as it is shown on the signpost I guess it adds verification that the name in another language is valid, in this case name:nl. Phil (trigpoint) ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Mechanical name edit? (was Re: Can wikidata links help fight name inflation?)
On 30/05/2015 8:41 PM, Roland Olbricht wrote: Hi, On 05/30/2015 09:48 AM, Roland Olbricht wrote: Thank you for informing the community. Do you actually have substantial evidence of a mechanical edit or something similar? There are a couple individual complaints and license issues (people taking names from a collection of military maps published in Russia in 2008, or from Wikipedia which is CC-BY-SA licensed). Quite a few users have already been blocked about mass-adding name:ru in the past (eg http://www.openstreetmap.org/user_blocks/563). Thank you. Reading the text of this block I too now understand the name:ru 'problem', no so much 'inflation' but possible licence infringement. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Keulen (was Re: Can wikidata links help fight name inflation?)
Roland, replies in-line On Sat, May 30, 2015 at 2:59 AM, Roland Olbricht roland.olbri...@gmx.de wrote: Luckily, in the offline database on my device, the object with name=Köln had a tag name:nl=Keulen. So I know that the sign is referring to my desired destination. Depending on the device in question, it is probably not actually using OSM data in its pure object form. If you have a Garmin, for example, you're using some Garmin data file. Very few software programs operate on pure OSM data without some additional processing step, even if that step is just to extrapolate things like geometries of objects. Please note that - I had no internet connectivity in that situation, hence wikidata, any other external database or even non-copied OSM data was not an option. Right, but it's likely that your map device had done some pre-processing step. That's where a tool would know how to bring in the Wikidata names and conflate them properly. So in total: Is it really a gain to remove all name:XX tags from Köln? That's a separate issue, I think, from what we're discussing. No one is talking about making a mass edit where all names are removed. Let's imagine another scenario where you were on the same road and the name you wanted was not present. If so, you would be compelled to fix it. But if the map you used didn't need to be updated, it already worked, you would not be thinking about it. And do we want to discuss such cases again and again with overzealous self-appointed curators? Please note, the DWG does recognize when the on-the-ground rule is a rule of thumb, but others with an OSM account might not. I don't understand what you mean here. Can you elaborate? I opt for: If a human mapper decides that it is worth adding name:XX to an object then let him/her do so. All annoying cases are covered by the mechanical edit policies, we don't need extra strict rules for name tags. The line between human and mechanical edit can be thin. If a company uses Mechanical Turk to make OSM edits one at a time, I would argue that this mass edit is the same as a computerized mechanical edit. That's why there are two issues here: 1. Is this a mechanical edit (which the DWG already addresses) 2. Is the data correct? The second point is where Frederik is talking about, and he's simply saying Let's go back to basics and use the on the ground verification as a rule of thumb. - Serge ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Can wikidata links help fight name inflation?
Am 29.05.2015 um 14:05 schrieb SomeoneElse li...@atownsend.org.uk: * I have absolutely no idea what signage is around Haifa - if a name:en for a place does appear on signs and is useful to use to see if you have got there then clearly there needs to be some indicator that says that name:en is useful here, but (say) name:cy is not. why are we focussing only on signs? What kind of signs? There are hundreds of name:en tags in osm for features in the municipality of Rome, but you won't find an official sign that says Rome, you might find quite a lot of touristic information boards with English names at the monuments, usually just English and Italian, but in OSM we do have typically also de, fr, es, ru and some more localized names tagged. All of them are helpful if you speak these languages, naturally, and they are in use - not on signs but in travel guides (books), used by tour guides (humans), tourists etc. If you speak to English folk they will speak about Tuscany rather than Toscana. On the ground truth for me is not just signs, it is also oral knowledge, people talking to each other, stuff that is in books or newspapers talking about the ground, etc Cheers Martin cheers Martin ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Keulen (was Re: Can wikidata links help fight name inflation?)
On Saturday 30 May 2015, Frederik Ramm wrote: Whoever does the preprocessing is of course free to join OSM data with any other database; so if for example we agreed that Wikidata was our name repository of choice and we'd reduce our own name:xx tagging to what is used by the people living in a place, then there would have been a wikidata tag on the Köln node and the software that generated your offline database could have made a choice whether, and to what degree, to include the Wikidata name catalogue in your offline data set. I am all for going strictly by the verifiability principle but this should not require local verifiability. There are many fields where this does not work at all: - maritime features outside territorial waters. - areas without local population or where local population has little contact with the outside world. - touristic areas with little local population like remote high mountain areas. In all of these cases names of features will be very difficult or impossible to verify locally in any language, verifiable names here primarily exist in written records abroad and in the memory of people who have visited the area but who are definitely not locals. And IMO it would be very regrettable if OSM universally referred to an external database for names of such features and specifically excluded them from the scope of the project. The question is also would you leave such features without any name and if not on what basis do you decide which name to tag? My suggestion for the whole issue would be to clarify the verifiability rule w.r.t. names and advise mappers to document sources of non-local names they add in changeset comments and source tags and ultimately in cases of conflicts it would be the burden of proof for the mapper to show the names added are verifiable (like by being consciously and specifically used by several other independent sources). -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Keulen (was Re: Can wikidata links help fight name inflation?)
On 30/05/2015 07:59, Roland Olbricht wrote: I happened to drive through Belgium a few days ago, heading home. A good approximation of home in this case is name=Köln. Actually, I found a street sign (150 km away from Köln) that reads Keulen. Should I have followed it or not? A name:xx that's actually used on signposts on the ground (the name of a place in a neighbouring country on a road in that country going to that place) to guide travellers to a place is clearly on the ground verifiable. I used Abergavenny (in a largely English-speaking part of Wales) as a specific example previously to try and separate the commonly used e.g. on signposts names from the translations. I've mentioned http://www.openstreetmap.org/node/267762522 elsewhere in the thread - if you're getting a bus there from the west it'll certainly have both Doire and Derry on it, and up in the Donegal Gaeltacht if there's a sign it'll almost certainly _only_ say Doire. Cheers, Andy ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Mechanical name edit? (was Re: Can wikidata links help fight name inflation?)
Hi, On 05/30/2015 09:48 AM, Roland Olbricht wrote: Thank you for informing the community. Do you actually have substantial evidence of a mechanical edit or something similar? There are a couple individual complaints and license issues (people taking names from a collection of military maps published in Russia in 2008, or from Wikipedia which is CC-BY-SA licensed). Quite a few users have already been blocked about mass-adding name:ru in the past (eg http://www.openstreetmap.org/user_blocks/563). But without going into details about these, I believe statistics alone tells you that there's something going on: The top 10 name:ru mappers have between themselves added over 150,000 name:ru tags world wide. Approximately 45 people have added more than 1,000 name:ru tags each. That doesn't mean that adding more than 1,000 name:ru tags is wrong; but we'll certainly have a closer look and where this happened over a short time span and in a concentrated fashion we will ask questions, and if we spot cases where it is obvious that names were taken from some sort of dictionary or database and copied into OSM without the requisite local knowledge, we'll revert. This lack of local knowledge does often manifest itself in accidental translations. To give a fictitious example: The German city of München is called Monaco di Bavaria in Italian, and Munich in English. There's also a Munich in North Dakota. Now if suddenly someone were to add name:it=Monaco di Bavaria to Munich, North Dakota, then I could be relatively sure that they did so without local knowledge (in fact, without knowledge about North Dakota and without knowledge about Italian) and that the other 1000 name:it translations they did in the same changeset are as worthless as this one. (For name:uk, the top 10 editors have added 70,000 names, and just 18 people have added more than 1,000.) I'm reluctant to discuss individual users or individual changesets here especially as long as we're still investigating the matter. If you can spare the time though, I'm sure the DWG would welcome an application from someone with your analytical skills! Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Keulen (was Re: Can wikidata links help fight name inflation?)
Another confusing one is Aachen. Depending in which language region of Belgium you are it will be Aken or Aix-la-Chapelle. Anyway, I'm also in favor of keeping most of the name:XX tags + a wikidata Q-number, of course. That's not the kind of redundancy I'm afraid of. In fact it's the kind of redundancy that's helpful for automatic verification of the data. Jo 2015-05-30 12:05 GMT+02:00 SomeoneElse li...@atownsend.org.uk: On 30/05/2015 07:59, Roland Olbricht wrote: I happened to drive through Belgium a few days ago, heading home. A good approximation of home in this case is name=Köln. Actually, I found a street sign (150 km away from Köln) that reads Keulen. Should I have followed it or not? A name:xx that's actually used on signposts on the ground (the name of a place in a neighbouring country on a road in that country going to that place) to guide travellers to a place is clearly on the ground verifiable. I used Abergavenny (in a largely English-speaking part of Wales) as a specific example previously to try and separate the commonly used e.g. on signposts names from the translations. I've mentioned http://www.openstreetmap.org/node/267762522 elsewhere in the thread - if you're getting a bus there from the west it'll certainly have both Doire and Derry on it, and up in the Donegal Gaeltacht if there's a sign it'll almost certainly _only_ say Doire. Cheers, Andy ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Mechanical name edit? (was Re: Can wikidata links help fight name inflation?)
Am 30.05.2015 um 12:13 schrieb Frederik Ramm frede...@remote.org: The German city of München is called Monaco di Bavaria in Italian, as a sidenote for those who plan to study Italian with the aid of osm-talk, München is 'Monaco di Baviera' in Italian ;-) cheers Martin ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Mechanical name edit? (was Re: Can wikidata links help fight name inflation?)
Hi, On 05/30/2015 09:48 AM, Roland Olbricht wrote: Thank you for informing the community. Do you actually have substantial evidence of a mechanical edit or something similar? There are a couple individual complaints and license issues (people taking names from a collection of military maps published in Russia in 2008, or from Wikipedia which is CC-BY-SA licensed). Quite a few users have already been blocked about mass-adding name:ru in the past (eg http://www.openstreetmap.org/user_blocks/563). Thank you. Reading the text of this block and the user's most recent e.g. ten changesets does indeed strongly give the impression of a mechanical edit. I would agree to revert those edits. This is in particular different from the previously discussed changeset in Wales. That one shows reasonable effort to get support from locally active mappers. Bye, Roland ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[Talk-de] Avoid taging with both natural=water + waterway=riverbank
Hi, I have fixed this in a few places in the wiki: the combination of natural=water + waterway=riverbank for a single object is pretty dangerous and should be avoided because it will cause subtle and very hard to find rendering problems. The problem I hit was where someone placed a natural=water on some parent relation whereas the riverbanks were multipolygons of waterway=riverbank. The islands that were correctly mapped using multipolygons were flooded by the inherited natural=water. Similarly the advice which was in wiki to tag the multipolygons with natural=water and the ways with an additional waterway=riverbank might cause the same problem. Richard ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] Can wikidata links help fight name inflation?
Am 29.05.2015 um 13:58 schrieb moltonel 3x Combo molto...@gmail.com: That's really neat. How do you know wether a street is signposted or not ? I don't know of any tag that gives that info. there are ~600 visible_name 37000 unsigned_ref 518 unsigned 400 signed 161 name:signed 124 name:sign 86 ref:signed 48 unsigned_name 47 ref:unsigned 16 name:signposted I haven't checked on which kind of objects or which do not refer to highways or names Very likely I also missed some variants It seems that for names nobody cares to say whether they are signposted or not (or maybe only when the sign is different from the actual name), while for ref it seems common practice(?) to use unsigned_ref cheers Martin ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[Talk-it] Aggiornamento dei controlli sui nomi delle strade, ora con alt_name
Ciao, finalmente ho riaggiornato i controlli per utente che erano fermi da tanto tempo, ho aggiunto gli alt_name e unificato database e interfaccia utente col controllo per comune, che è molto simile a quella del controllo delle DUG: http://www.forsi.it/osm/ la ricerca per nome utente usa un elenco vecchio quindi non trova tutti i nomi e per il momento ho tolto il controllo parola per parola col correttore ortografico perché è già lento così, ma così trova meno errori potenziali solito disclaimer: non tutti questi nomi non sono veramente sbagliati, semplicemente non seguono le regole che ho inserito nel programma quindi bisogna modificare con prudenza e per gli errori non banali conviene conoscere i luoghi o contattare il mappatore (un errore banale potrebbe essere VIAROMA tutto maiuscolo e senza spazio, ma ci sono tanti nomi di persona o di luogo che è meglio lasciare stare se non si conoscono) le way con alt_name sono 6178, 2 in meno rispetto alla settimana scorsa ;-) su 919539 way con name (1730 in più rispetto alla settimana scorsa) -- Daniele Forsi ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
[Talk-at] Versatz geoimage vs. basemap
Hallo, die aktuellen Bilder aus dem Jahr 2014 für den Großraum Linz sind ja auf den Basemap-Orthofoto-Layer bereits vorhanden. Wenn ich diesen Layer mit dem Geoimage-Layer in JOSM vergleiche haben Gebäude teilweise einen Versatz von bis zu zwei Meter. Rein subjektiv schaut es für mich aus, als ob der Geoimage-Layer qualitativ besser wäre, was die Korrekturen betrifft, allerdings sind die Bilder dort noch von 2010. Laut Mail, die ich vom LFRZ bekommen habe, sollen die neuen Bilder bei geoimage aber auch innerhalb der nächsten beiden Wochen zur Verfügung stehen. Fraglich ist, ob die dann besser nachkorrigiert sind. Welches Bildmaterial ist hier aber wirklich exakt? Soll ich jetzt jedes Mal den Basemap-Layer vorher manuell zurechtschieben? Oder besteht die Chance, dass die neuen geoimage-Bilder dann besser sind? Dann würde ich noch mit größeren Änderungen warten... flaimo ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Public Transport Schema und Wien
Am 29.05.2015 um 22:37 schrieb Robin Däneke: Ok. Dann sollten die Plattforms aber auch nicht mit der Linie selbst assoziiert werden oder immer nur dann, wenn sie in Form von Areas oder Linien angezeichnet werden. (Die Platform ist, mit 12-20 Meter, immerhin eine Linie oder eine area... (In den inneren Bezirken sind ohnehin fast alle platforms Linien. @caigner: Meinetwegen ändere ich in Wien die Linien so um, dass sie nur eine Stop position haben... Aber dann bitte keine einzelnen Platform nodes mehr, wenn eh schon ein stop_position da ist... Können wir uns etwa darauf einigen. Ich würde vorerst nur die Tags umsetzen. Das mappen der jeweiligen platforms muss dann warten. Könnte man das (wenn wir uns drauf einigen können) auch irgendwo publizieren? Ich möchte an dieser Stelle auch mal wieder erwähnen, daß wir die Welt symbolisch abbilden, in dem wir Striche für Straßen, Polygone für Gebäudeumrisse zeichnen, Punkte für Mistkübel, Telefonzellen, Bäume etc. Wir verwenden darüber hinaus auch so seltsame Konstrukte wie Relationen, mit denen wir bestimmte Dinge logisch zusammenfassen. Eine Landkarte ist eine symbolische Abbildung der Realität. Friedrich hat natürlich Recht, wenn er meint, eine Plattform sei eine raised structure. In der Realität auf jeden Fall. Aber hier kommt noch etwas anderes ins Spiel, nämlich die Sprache. Im Englischen ist eine Plattform nicht nur ein physikalisches Ding, sondern eben auch ein Ort, an dem man auf ein Verkehrsmittel wartet. Und auf einer Landkarte muß diese Plattform nicht zwingend als Strich oder sogar Fläche eingezeichnet werden, sondern es reicht aus, einen Punkt (Node) zu setzen und damit weiß man dann, wo sich dieser Ort befindet. Um es klar zu sagen: Wir machen nicht Malen-nach-Zahlen. Eine Datenbank für eine Landkarte zu befüllen bedeutet zu abstrahieren. Es ist wichtig, eine Telefonzelle mit einem Node einzutragen. Es ist nicht wichtig, den exakten Umfang der physikalisch vorhandenen Telefonzelle einzuzeichnen. Es ist wichtig, eine Bushaltestelle mit stop_position und platform einzutragen. Es ist nicht wichtig, daß die Platform geometrisch korrekt ist. Hauptsache, sie ist da. Es ist auch nicht wichtig, das Wartehäuschen einzuzeichnen. Es ist aber wichtig, shelter=yes zu setzen, wenn eines vorhanden ist. @Robin: Bevor Du jetzt anfängst, wieder alles mögliche zu ändern, schau Dir doch noch mal korrekt (nach public transport scheme v2) eingetragene Buslinien anzusehen. Es gibt bereits genug Beispiele dafür, und nimm sie Dir als Vorlage. ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-it] Aggiornamento dei controlli sui nomi delle strade, ora con alt_name
2015-05-30 15:04 GMT+02:00 Daniele Forsi dfo...@gmail.com: Ciao, finalmente ho riaggiornato i controlli per utente che erano fermi da tanto tempo, ho aggiunto gli alt_name e unificato database e interfaccia utente col controllo per comune, che è molto simile a quella del controllo delle DUG: http://www.forsi.it/osm/ Grazie Daniele, come sempre utilissimo tool! ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Aggiornamento dei controlli sui nomi delle strade, ora con alt_name
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 30/05/2015 15:04, Daniele Forsi ha scritto: Ciao, finalmente ho riaggiornato i controlli per utente che erano fermi da tanto tempo, ho aggiunto gli alt_name e unificato database e interfaccia utente col controllo per comune, che è molto simile a quella del controllo delle DUG: http://www.forsi.it/osm/ la ricerca per nome utente usa un elenco vecchio quindi non trova tutti i nomi e per il momento ho tolto il controllo parola per parola col correttore ortografico perché è già lento così, ma così trova meno errori potenziali solito disclaimer: non tutti questi nomi non sono veramente sbagliati, semplicemente non seguono le regole che ho inserito nel programma quindi bisogna modificare con prudenza e per gli errori non banali conviene conoscere i luoghi o contattare il mappatore (un errore banale potrebbe essere VIAROMA tutto maiuscolo e senza spazio, ma ci sono tanti nomi di persona o di luogo che è meglio lasciare stare se non si conoscono) le way con alt_name sono 6178, 2 in meno rispetto alla settimana scorsa ;-) su 919539 way con name (1730 in più rispetto alla settimana scorsa) good! :) - -- Simone Girardelli _|_|_|_|_|_|_|_|_|_ |_|_|_|_|_|_|_|_|_|_| -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJVabavAAoJEMTPIIVov0ZtM0AH/il0mnlkexEeK8dy7fpXJ+QH f3l8PR8eKmSmo9m7ODICuoGKj3xCyriWZ/+cv9dTzN7NWM0m+N4aDWytKWjCtYnH N16JgMnmygO9uAWJBqr6FjRiSrk/0LBTuS4WECJE1VVFBVAPOt2cypwdPqB3J/7M axS0Zj6gWQVKuUGsbx8XkLdJL3rGriax1neJ1idsmbwSVeJVTQl9NoCaSBJ0tBo/ 56qNx0WtxNmvl3r4CMTNhHwOKRIcDpQClEZ2DVDM5SDtbz8xI2RaJVaXhb6K2rpa RZWqhEhKqgThQHTE5y8y9JNPcUAKtvDFubl4T5/xWOQv6mnVsbu1PseaA8nMHzw= =2/JI -END PGP SIGNATURE- ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [OSM-talk] Can wikidata links help fight name inflation?
Am 29.05.2015 um 15:55 schrieb Komяpa m...@komzpa.net: What exactly are we trying to save by omitting these locales, what wasn't eaten already by source= on French buildings? :) yes, and there are more tags that are both, used more often and are more questionable than name:ru tags, e.g. tiger:name_base tiger:name_type osak:street_name osak:municipality_name addr:street:name even of tiger:name_base_1 there are more than a million, almost double the amount of all Russian names in osm. These are followed by a lot crap in the same quantity order, like KSJ2:filename (!) ~500K All these came to light by a single taginfo search for name, needless to say similar import crap can be found for different keys as well. Many of them are not even documented. cheers Martin ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[Talk-de] Undiskutierter Import aus Brachenbuch in Deutschland
Hallo, es dürfte bestimmt auch einige Leute hier interessieren. Am Donnerstagabend hat eine Armee (ca. 70 bis 100 Accounts) OSM mit über 15000 neuen Nodes geflutet. Mittlerweile hat sich ein Vertreter der Firma, die dafür verantwortlich ist, im Forum zu Wort gemeldet. erster Post zum Thema: http://forum.openstreetmap.org/viewtopic.php?pid=506170 erster Beitrag des Geschäftsführers: http://forum.openstreetmap.org/viewtopic.php?pid=506138#p506138 Btw, natürlich hat die DWG eingegriffen. Viele Grüße Michael -- Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten ausgenommen) I prefer GPG encryption of emails. (does not apply on mailing lists) signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] Can wikidata links help fight name inflation?
Hi, Komяpa: What exactly are we trying to save by omitting these locales, what wasn't eaten already by source= on French buildings? :) Martin Koppenhoefer: even of tiger:name_base_1 there are more than a million, almost double the amount of all Russian names in osm. Firstly: It is a common fallacy for people in OSM to argue: Someone else is doing stupid things, and while they do that, everyone else should certainly be allowed to do stupid things also. I don't buy into that logic; just because silly (or sillier) stuff happens elsewhere in OSM doesn't mean that lesser problems should automatically be ignored. Secondly: I am less concerned about rubbish remaining from imports because that can be cleaned up without someone complaining. I am more concerned about things that become established and all of a sudden you find there's no way back because people rely on it. KSJ2:filename is not one of these tags. Thirdly: My main problem with name tag inflation is not the data volume (even though I can see this becoming an issue if someone should really argue that each named object has a name in each of the several thousand langauges on the planet!). My problem is that people start labelling places they have zero knowledge of, relying on military atlases from 50 years ago, or dubious travel websites, or transliterated guesswork, or database lookups. In my opinion this is often not verifiable, at least not for the usual sense in which we use verifiable. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-at] Public Transport Schema und Wien
On 30.05.2015 16:03, Christian Aigner wrote: Friedrich hat natürlich Recht, wenn er meint, eine Plattform sei eine raised structure. In der Realität auf jeden Fall. Aber hier kommt noch etwas anderes ins Spiel, nämlich die Sprache. Im Englischen ist eine Plattform nicht nur ein physikalisches Ding, sondern eben auch ein Ort, an dem man auf ein Verkehrsmittel wartet. ...vorausgesetzt es ist eine raised structure. ;-) Es ist immer wieder interessant, wie Deutsche und Österreicher versuchen, englische Begriffe umzuinterpretieren und dabei glauben es besser zu wissen als die Muttersprachler. public_transport=platform ist von railway=platform bzw. highway=platform abgeschaut und war ursprünglich wie diese genau für die physischen Plattformen gedacht. Erst später wurde ins public_transport Proposal der Satz eingefügt: If there is no platform in the real world, one can place a node at the pole. Seither entspricht das Tag nicht mehr genau der Wortbedeutung im Englischen. Es ist wichtig, eine Bushaltestelle mit stop_position und platform einzutragen. Es ist nicht wichtig, daß die Platform geometrisch korrekt ist. Hauptsache, sie ist da. Es ist auch nicht wichtig, das Wartehäuschen einzuzeichnen. Es ist aber wichtig, shelter=yes zu setzen, wenn eines vorhanden ist. Wichtig ist für jeden was anderes. Für manche ist die ganze Openstreetmap nicht wichtig, sondern z.B. etwas zu essen zu haben. -- 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-pe] [talk-latam] State of the Map LatAm 2015
Felicitaciones Julio y la comunidad chilena! El sitio está muy bueno, pronto les haré llegar mas comentarios. Saludos y nos vemos en septiembre! On 29/05/15 14:57, Julio Costa Zambelli wrote: Estimados, Hoy hemos anunciado la realización del primer State of the Map LatAm. El evento tendra lugar entre el 4 y el 6 de Septiembre, en Santiago de Chile. Como muchas personas solicitaron durante el State of the Map de Buenos Aires en Noviembre pasado, el evento se realizara el viernes, sábado y domingo inmediatamente anteriores al AbreLatam (7-8) y el ConDatos (9-10). De forma que puedan postular a las becas que ofrecen esos eventos. De todas maneras hemos abierto un proceso de becas para las entradas y alojamientos en Santiago, las cuales se financiaran con la ayuda de los auspiciadores de nuestra conferencia. Pueden obtener más información en http://sotm.openstreetmap.cl/ y en http://wiki.openstreetmap.org/wiki/ES:State_of_the_Map_Latam_2015 Y también respondiendo a este mensaje. Saludos, Julio Costa Zambelli Fundación OpenStreetMap Chile julio.co...@openstreetmap.cl mailto:julio.co...@openstreetmap.cl http://www.openstreetmap.cl/ Cel: +56(9)89981083 ___ talk-latam mailing list talk-la...@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-latam ___ Talk-pe mailing list Talk-pe@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-pe
Re: [Talk-pe] [Talk-cl] State of the Map LatAm 2015
Buena, participare, se ve muy interesante! slds! El 29 de mayo de 2015, 13:57, Julio Costa Zambelli julio.co...@openstreetmap.cl escribió: Estimados, Hoy hemos anunciado la realización del primer State of the Map LatAm. El evento tendra lugar entre el 4 y el 6 de Septiembre, en Santiago de Chile. Como muchas personas solicitaron durante el State of the Map de Buenos Aires en Noviembre pasado, el evento se realizara el viernes, sábado y domingo inmediatamente anteriores al AbreLatam (7-8) y el ConDatos (9-10). De forma que puedan postular a las becas que ofrecen esos eventos. De todas maneras hemos abierto un proceso de becas para las entradas y alojamientos en Santiago, las cuales se financiaran con la ayuda de los auspiciadores de nuestra conferencia. Pueden obtener más información en http://sotm.openstreetmap.cl/ y en http://wiki.openstreetmap.org/wiki/ES:State_of_the_Map_Latam_2015 Y también respondiendo a este mensaje. Saludos, Julio Costa Zambelli Fundación OpenStreetMap Chile julio.co...@openstreetmap.cl http://www.openstreetmap.cl/ Cel: +56(9)89981083 ___ Talk-cl mailing list talk...@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cl -- David A. Pineda Osorio F:+56 9 82142267 Ingeniero Civil Electricista Universidad de Chile *http://www.cultura-libre.cl/ http://www.cultura-libre.cl/* ___ Talk-pe mailing list Talk-pe@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-pe
[Talk-at] aufgeteilte Straßen wieder vereinen
Hallo! Ich bin gerade dabei, den Liesinger Platz wieder zu reparieren. Dort wurde z.B. die B13a aufgeteilt, obwohl gar keine bauliche Trennung irgend einer Art vorhanden ist. Beim Auftrennen wurden jede Menge Bus-Relationen kaputt gemacht. Ich möchte das jetzt wieder reparieren. Meine Vorgehensweise wäre die folgende: 1) die eine Hälfte der aufgetrennten Straße löschen 2) die Löcher, die dadurch in bestehenden Relationen bestehen, wieder stopfen Kaputte Relationen zu reparieren nimmt einiges an Zeit in Anspruch. Also wird es eine Weile dauern, bis alles, was mit dem Liesinger Platz an ÖPNV zusammen hängt, wieder korrekt funktioniert. Muß ich auf irgend etwas besonders aufpassen? LG, Christian ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-de] Undiskutierter Import aus Brachenbuch in Deutschland
On Sat, 30 May 2015, Michael Reichert wrote: Hallo, es dürfte bestimmt auch einige Leute hier interessieren. Am Donnerstagabend hat eine Armee (ca. 70 bis 100 Accounts) OSM mit über 15000 neuen Nodes geflutet. Mittlerweile hat sich ein Vertreter der Firma, die dafür verantwortlich ist, im Forum zu Wort gemeldet. Sehr interessant! Problematisch duerfte v.a. das Entfernen nicht mehr existierender POIs sein. Normalerweise kuemmert man sich als OSMler um 'seine' Eintraege in regelmaessigen Abstaenden. Aus eigener Erfahrung kann ich beschreiben, wie Google oder andere Firmen das machen: Webseiten werden per Bot durchforstet, die Adresse rausgefiltert und in GoogleMaps eingetragen. Da gibt es Jungunternehmer, die vielleicht in einer Garagenfirma anfangen und dann dreimal umziehen. Da ist dann dreimal das gleiche Geschaeft eingetragen. Ich hab dann mal spasseshalber bei Google beantragt, meinen Firmeneintrag auf GoogleMaps zu loeschen. Das hat fast ein Jahr gedauert! Mit solchen Mechanismen wird OSM dann wie im Thread beschrieben zur Datenmuellhalde. A. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-at] Public Transport Schema und Wien
Im Englischen ist eine Plattform nicht nur ein physikalisches Ding, sondern eben auch ein Ort, an dem man auf ein Verkehrsmittel wartet. Also ich bin in Englisch und allen Eigenarten die die Briten so in der Sprache haben ziemlich vertraut. Aber von einer platform zu sprechen, bei einer Bishaltestelle, das hab ich noch nie gehört. @Robin: Bevor Du jetzt anfängst, wieder alles mögliche zu ändern, schau Dir doch noch mal korrekt (nach public transport scheme v2) eingetragene Buslinien anzusehen. Es gibt bereits genug Beispiele dafür, und nimm sie Dir als Vorlage. Könntest du mir da ein paar Beispiele nennen? Und: Ich werde mal am 33A versuchen, die platform als einfache Node anzulegen, ohne das highway=bus_stop Vielleicht funktioniert es dann AUCH mit OP... Wenn das funktioniert passe ich alles an. Unter beachtung der Beispiele. ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
