Den name weglassen, nur weil man sich nicht einigen kann was da rein soll, halte ich für keine gute Idee.
Ist mein österreichisches Deutsch so schwer verständlich? Ich habe Beispiele aus 3 Ländern angeführt, wo Ortsnamen in zweisprachigen Gebieten mit name=Sprache1/Sprache2 erfasst sind. Also schon ein wenig global. Warum soll das nicht auch in den sorbischen Gebieten funktionieren?
Dafür war ja mein Vorschlag mit name_1= und name_2= oder vergleichbarem, official_name_1= und official_name_2= oder so. Ist aber, verständlicherweise nicht beliebt. Aber wie will man anders zwei gleichrangige Namen taggen ohne sie in einen einzigen Tag zu stecken?
Wenn man nur mit name:de und name:hsb oder was auch immer arbeitet hat man spätestens ein Problem, wenn jemand noch ein name:en oder so hinzufügt. Dann weiß der Renderer nicht mehr was er machen soll. Oder auch bei sonstigen Städten, die teilweise ja in Dutzenden name:xx getaggt sind.
Woher weiß man das es funktioniert? Weil man es auf der Karte sieht? Semantisch ist das aber trotzdem leider unsauber. Aber ist wohl derzeit trotzdem der beste Kompromiss. Wenn man sich ein wenig mit seiner Heimat verbunden fühlt, zweisprachig ist, dann will man das auch in der Karte sehen. Das verstehe ich voll und ganz und appelliere diesbezüglich auch ein wenig an die Gegner dieses Taggings, dass sie nicht unsensibel sind. 
Aber am besten wäre natürlich trotzdem eine Lösung, die alle 100%ig zufrieden stellt.
Ein Indiz dafür ist, dass die Namen schon sehr lange so in OSM akzeptiert werden, zumindest in Südtirol, woanders weiss ich es nicht. Viele mehrsprachige Nodes sind recht alt (Ortler, Sterzing, Salurn). Nur gelegentlich, vor allem bei dreisprachigen Orten findet man häufig wechselnde Namensgebungen (St. Ulrich, St. Martin in Thurn).
Von Auswertern zu erwarten, sich den passenden ortsüblichen Namen zusammenzusuchen, halte ich für völlig illusorisch. Dazu würde Wissen über die regionale Mehrheitssprache gehören. Bestenfalls bekommt man sowas wie den deutschen Stil, der sich halt den deutschesten und kürzesten Namen aus name und name:de raussucht, aber das funktioniert dann nur in eine Zielsprache, nicht in die vor Ort verwendete.
ich bin auch für die südtiroler Lösung, dort sind auch die meisten Orte mit name=it - de getaggt und dann jeweils einzeln nochmal als name:de sowie name:it.
Den Ansatz mit name_1 name_2 oder Variationen desselben mit official_name halte ich für nicht zielführend.
Wenn man wollte könnte man sich aus diesen Daten somit auch rein deutschsprachige Karten erzeugen, man muss ja nur den name lokal mit name:de überschreiben.
Was eventuell noch eine Idee für eine Taggingkombination wäre um alle glücklich zu machen: name_setup (erstbeste Idee die mir für den Key eingefallen ist), im Beispiel südtirol wäre die value hier meist "it - de, dies enthält alle Sprachen sowie Trennzeichen zwischen den Sprachen, und auch die Prioritäten der Sprachen.
Ist aber eher ein nice-to-have, da man sich diese Informationen selbst aus den Values von name:it und name:de herleiten kann, was nicht durch die beiden Values abgedeckt wird muss logischerweise der Rest sein…
Diese Frage aus #1 ist verlorengegangen und würde mich auch interessieren:
Das stört in Südtirol nämlich echt: Ansagen wie “Links Abbiegen in Viale Amedeo Duca D’Aosta - Duca-D’Aosta-Allee” kommt etwas holprig rüber 
Werden in Chóśebuz auch Strassenschilder zweisprachig? Oder Seen?
Ohne Dir widersprechen zu wollen klingt mir das eher arg nach inkonsistenten Taging.
In Südtirol sind alle Straßenschilder, inzwischen sogar die Wanderwegweiser zweisprachig (die Ladiner Gebiete kenne ich nicht).
Der offizielle Name ist zweisprachig, wer da eine der Versionen als name=* auswählt, begibt sich auf brisantes Terrain.
Es ist mMn Aufgabe des Routers, aus den Angaben name:de=, name:it= und name= - die geeignete für Ansagen auszuwählen, am Tagging liegt das nicht.
Wenn es tröstet: Auch professionelle Navis bringen da z.B. die italienischen Namen in fürchterlicher Aussprache.
Eine Möglichkeit die ich noch sähe, aber sicherlich auch eher kontrovers gesehen wird: man taggt mit name:de und name:hsb (und name:en, usw. usf.) und ins name macht man dann die Varianten die man da haben möchte. Also bspw. name=name:de;name:hsb. Dann kann der Renderer/Router wissen, dass es 1. ein zweisprachiges Gebiet ist (kann man natürlich auch dreisprachig, viersprachig machen…) und 2. weiß er welche Namen er zu verwenden hat und kann sich aussuchen wie er es macht.
Da mit dem auf andere Tags verweisen aber wohl ein Novum hier in OSM wäre, mache ich mir keine große Hoffnung, dass dies umsetzbar ist. Aber so vom Prinzip her wäre das doch fast schon die ideale Lösung oder?
Das geht etwa in die Richtung meiner Idee… Den name-Tag würde ich aber auf keinen Fall dafür misbrauchen.
Auf Basis einer Grenze des Gebietes mit Mehrsprachigkeit (z.B. https://www.openstreetmap.org/relation/6001479#map=10/51.7338/14.2496&layers=N oder ähnlich: z.B. boundary=offical_language)
ein Zusatztag: official_language:iso=yes
iso zeigt den Sprach-ISO-Code an.
…oder in einem Feld: official_language=de;dsb (als Beispiel für Deutsch und Niedersorbisch)
Alle name-Tags innerhalb dieser Grenze werden anhand des erfassten name:iso=* benammst. (setzt natürlich voraus, daß die Namen auch erfasst sind.
Sven
Ich verstehe die Verkomplizierung der Sache nicht.
Warum nicht einfach name=Bautzen und name:hsb=Budyšin? Hier spricht m.M. nach auch das “ground truth” dagegen: die Ortsschilder sind immer zuerst Deutsch und dann unten drunter Sorbisch: http://www.t-online.de/regionales/id_77241706/domowina-will-mehr-jugendliche-ansprechen.html
Also das ist nicht “ein” Name oder so etwas was name=Bautzen/Budyšin impliziert. Und was passiert wenn ein Ortsname einen Slash enthält? Dafür gibts in der Lausitz Beispiele “Halbendorf/Spree” oder “Halbendorf/Gebirge” … https://de.wikipedia.org/wiki/Halbendorf/Spree
und für den Bindestrich ist das ja noch schlimmer.
Nebenbei: Das tagging in Südtirol halte ich für falsch, auch wenn es auf dem Boden wahr sein mag, was unlogisch ist (s.u.). Die I18N Tags sind dafür da genützt zu werden. Klar man soll nicht für die Karte oder den Router mappen aber eine künstliche Abweichung vom ‘Standard’ macht doch nur Probleme und kann nicht im Interesse der Vielsprachigkeit sein
Der offizielle Name ist zweisprachig, wer da eine der Versionen als name=* auswählt, begibt sich auf brisantes Terrain.
Also das “ein” Name offiziell “zwei” Sprachen enthält macht für mich keinen Sinn. Werden dann in Israel alle 3 Sprachen in name reingemischt :)?
Und woher weiß man denn dann eigentlich welche Sprache an welcher Stelle kommt? Ob das wirklich jeder Mapper konsistent machen würde?
Siehe z.B. folgende Region: nicht nur 3 Sprachen, auch 3 Schriften: http://www.openstreetmap.org/#map=11/31.6768/-8.0255
Auch ich finde das recht unlogisch, in einer idealen Welt würde ich diese 3 Schreibweisen auch eher in einen name_official-Tag reinschreiben, aber auch wiederum grundsätzlich diesen Tag zum Rendern einer “offiziellen” Karte verwenden. Traum: Wenn die osm.org-Karte nur diesen name_official-Tag rendern würde, wäre dieser wohl ganz schnell super gepflegt.
Viele Grüße,
Kay
Straßenschilder sind definitiv zweisprachig. Bei Seen weiß ich nicht, wo deren Namen aufgeschrieben sind. Auf Verkehrsschildern werden aber auch Flüsse und Seen mit beiden Namen angegeben, wenn du das meinst.
Das ist der Status quo. Warum nicht? Weil dann auf der Karte nur der deutsche Name angezeigt wird, was weder der “ground truth” noch der Rechtslage entspricht. Denn auf den Ortsschildern haben nun einmal beide Namen zu stehen, weil beide Namen offiziell sind. In Brandenburg steht es in der von mir verlinkten Kommunalverfassung seit 2014 sogar explizit drin, dass der amtliche Name aus den Namen in beiden (!) Sprachen besteht. Dass Sorbisch drunter steht, ist einfach eine Verwaltungsvorschrift. Irgendwo muss es ja stehen. Im Übrigen gibt es – ich erwähnte es schonmal – durchaus Orte, in denen die Straßenschilder oben den sorbischen und darunter den deutschen Namen nennen. Was kommt dann als “ground truth” in den name-Tag? Nur der sorbische Name?
Weil dann auf der Karte nur der deutsche Name angezeigt wird, was weder der “ground truth” noch der Rechtslage entspricht.
Man mappt doch nicht für die Karte oder etwas doch ?
Es macht alles später, wenn die Technik soweit ist, extrem komplex und wie ich via Bindestrich und slash gezeigt habe sogar unmöglich das zu trennen. Eine simple Navigation sagt dann immer alles zweisprachig an, was für Sorben und Deutsche etc einfach nur nervt und diese werden dann irgendein Navi nehmen was einfach nur deutsch ansagt.
Was kommt dann als “ground truth” in den name-Tag? Nur der sorbische Name?
Ja, genau. Das ist extrem einfach & konsistent & funktioniert für Karten und Router, falls beide ein ‘locale’ switch unterstützen. Wenn man das nicht macht wird es wie gesagt ziemlich sperrig (und unübersichtlich für Karten) für 3 Sprachen
Edit: Außerdem wer sagt das ist der Status quo? Der Status quo für Straßen etc ist das definitiv nicht. Siehe: https://graphhopper.com/maps/?point=51.161261%2C14.628296&point=51.218712%2C14.666233&locale=hsb&vehicle=car&weighting=fastest&elevation=true&layer=Sorbian%20Language
Was Straßenschilder und Ortschilder anbelangt… ja… ist so!.
Das für viele Ortsnamen bereits der sorbische Name erfasst ist, haben wir schon festgestellt. Für Straßennamen sieht das schon anders aus… Da helfen (leider 
) selbst die Amtsblätter nichts, wenn da fragmentarische Straßenlisten enthalten sind, z.B. in Zusammenhang mit Straßenreinigung oder ähnlichem.
Ich meine aber, daß es aber datentechnisch keine saubere Lösung ist, vor allem bei Namen ist, alles in einen Wert zu schreiben. Das ist für mich Sache des Renderers. Daher muß dem Renderer gesagt werden: "Hey Renderer, bename für den Bereich xy die Objekte mit einem name:xy=* und einem name:ab=* Tag in der Form, daß name:xy=* und name:ab=* übereinander stehen. name:xy=* wäre in unserem Fall der Deusche Name; ableitbar aus der DE-Grenze.
Grundsätzlich ist die OnTheGround-Regel eine exellente Sache. Man muß aber immer im Hinterkopf haben, daß OSM eine Geodatenbank ist. …und Datenbank hat für jede Sache immer ein Schlüssel-Wert-Paar. So sehe ich das auch bei Namen in unterschiedlichen Sprachen. Ein Ort hat nun mal unterschiedliche Schreibweisen des Namens je nach Sprache. Beispiele brauche ich nicht zu bringen… Nur wenn eine Region den Status einer Zweisprachigkeit hat, ist das eine weitere Geo-Information, für die es in OSM noch keine zufriedenstellende Lösung haben, auch wenn zu mindestens ein Teil der Grundinformation (der Name in den verschiedenen Sprachvarianten) vorhanden ist. Es fehlen nun Grenzen, die die zweisprachigen Gebiete definieren, mit der Angabe (ISO-Code), welches die Sprachen sind (fürs Kartenrendering) und vor allem auch der Wille der Kartenersteller/-renderer, dieses auch umzusetzen.
Sven
Probier das nochmal von Bautzen nach Crostwitz, da sieht die Sache schon anders aus. Doch, nur de im name-Tag ist Status quo.
Edit: Stimmt gar nicht, weil der Graphhopper auch da die sorbischen Namen nicht anzeigt, selbst wenn ich hsb als Locale auswähle. Und nun?
@J busissin: ich meinte nur die Karte. GraphHopper selbst liest aktuell nur das name tag: https://github.com/graphhopper/graphhopper/issues/259
Aber genau das meine ich: nur weil die meiste Software aktuell noch limitiert ist, sollten wir nicht für diese Karten- oder Routenplanersoftware die Datenbank falsch füttern, weil es der ‘korrekten’ Software dann das Leben schwer bzgl. unmöglich macht.
Ich meine aber, daß es aber datentechnisch keine saubere Lösung ist, vor allem bei Namen ist, alles in einen Wert zu schreiben. Das ist für mich Sache des Renderers. …
Man muß aber immer im Hinterkopf haben, daß OSM eine Geodatenbank ist.
Danke & Genau !
Dazu eine Anmerkung: Lübben/Lubin und Calau/Kalawa sind ab sofort Teil des amtlichen Siedlungsgebietes und müssten dementsprechend ergänzt werden: http://www.rbb-online.de/politik/beitrag/2016/04/luebben-und-calau-offiziell-sorbisches-siedlungsgebiet.html
Postrow/Gruß,
j.
Ah… Sehr schön…
Ich schaue mal was das Amtsblatt Brandenburg sagt und passe die Grene Zeitnah an…
Sven
Dobry wjacor!
so… Gemeinden Lübben, Calau und Wiesengrund zur Relation https://www.openstreetmap.org/relation/6001479#map=10/51.7338/14.2496&layers=N hinzugefügt… mal sehen, welche noch hinzu kommen…Es gibt ja noch ein paar Kandidaten.
Quelle: http://service.brandenburg.de/lis/detail.php/bb3.c.279168.de und http://www.mwfk.brandenburg.de/media_fast/4055/PM%2038%20Siedlungsgebiet%20Sorben.pdf
Postrow/Gruß,
Sven, der leider aber kein sorbisch kann.