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.
Nach allem, was ich von den Verhandlungsfortschritten mitbekomme, sollte es das erstmal gewesen sein. Die anderen Gemeinden werden sich vermutlich dagegen entscheiden.
Was anderes: Gab es nicht mal eine Möglichkeit, sich grafisch darstellen zu lassen, wo überall name:hsb-Tags vorhanden sind? Ich meine, mich daran zu erinnern.
overpass turbo wäre geeignet: Für ein kleines Gebiet kann man sich auch alles ausgeben lassen, bei grösseren Gebieten sollte man vielleicht ein bisschen filtern, z.B. nur place=* oder natural=peak.
Ich habe mal ein wenig was zusammengeschrieben…
http://overpass-turbo.eu/s/fPr (Achtung: durch die Grenze dauert die Abfrage etwas)
abgefragt werden alle place-Nodes innerhalb der Grenze des annerkannten sorbischen Siedlungsgebietes und die nicht place=locality sind. Warum die Place-Nodes um Lübben und Calau fehlen, weiß ich nicht, evt. hängt das damit zusammen, daß ich die Grenze ja erst kürzlich aktualisiert habe.
die Farben:
hellblau mit dunkelbauen Rand: vorhanden: name=, name:dsb=, name:hsb=; nicht vorhanden: name:de
rot: vorhanden: name=; nicht vorhanden: name:dsb=, name:hsb=, name:de
schwarz: vorhanden:name=, name:dsb=; nicht vorhanden: name:hsb=, name:de
orange mit rotem Rand: name=, name:hsb=; nicht vorhanden: name:dsb=, name:de
blau: vorhanden: name=, name:hsb=, name:dsb=, name:de
braun: vorhanden: name=, name:dsb=*, name:de; nicht vorhanden: name:hsb
Schwarze Umgrenzung: “anerkanntes sorbisches Siedlungsgebiet”
Leider habe ich Textboxen nicht hinbekommen, die entweder nur name:dsb oder name und name:dsb anzeigen.
Sven
node[!name][!name:de][!name:hsb]
[name:dsb]
{
symbol-size:6;
color:green;
fill-color:green;
width:1;}
node[!name:de][!name:hsb]
[name][name:dsb]
{
symbol-size:6;
color:red;
fill-color:green;
width:1;
}
(nur) name:dsb ist (noch) vernachlässigbar, da es da nix gibt.
http://overpass-turbo.eu/s/fPA
Das ganze mal etwas übersichtlicher (im Code) um Redundanzen eingekürzt und name+name:dsb ergänzt.
edit: sehe grad, dass das schon drin war, nur andere Farbe …
Da hab ich mich missverständlich ausgedrückt… mit text:name erscheint der Wert des name-Tags permanent. Ich will aber den Wert in name:dsb permanent anzeigen. Vergleiche auch mein Extra-Beitrag: http://forum.openstreetmap.org/viewtopic.php?id=54410
Sven
In deiner Abfrage ist noch ein Fehler drin, da fehlt bei der Relation der Name.
Du meinst oben, im Abfrageabschnitt…?
Ja, stimmt… ist aber z.Z. die einzige Grenze, die so ist…
Mir fehlen aber noch ein paar MapCSS - Beispiele.
Sven
Nöö, zoom einfach mal bisschen raus … 
Hier mal ein Blick über den Tellerrand des deutschen Michels, insbesondere die Regelungen in Südtirol scheinen mir - angesichts der historisch belasteten Situation - doch sehr pragmatisch.
http://wiki.openstreetmap.org/wiki/Multilingual_names#Alto_Adige.2FS.C3.BCdtirol_.28South_Tyrol.29
Gruß
Klaus
Also wie schon oben gesagt: das erschwert es der Software das multilinguale Darstellen etc umzusetzen und zweitens, warum ist das Deutsche an erster Stelle und nicht an zweiter ? Evtl. wird ja Deutsch doch bevorzugt? Also wenn man solche ‘Konflikte’ mit in die GeoDB reinholen will, kann man das machen. Aber ‘pragmatisch’ ist das garantiert nicht, man könnte auch inkonsequent sagen
Und Regeln wie die hier machen das ganze dann quasi unmöglich für jede nutzende Software die z.B. nur DE ausspucken soll:
Also mein Argument ist hauptsächlich: warum nicht alle Fähigkeiten der DB auch dafür nutzen und die Daten normalisieren? Und die Tools zum Editieren, Visualisieren und Routen sind davon komplett losgelöst. Aber diese Debatte sollten wir wahrscheinlich noch etwas energischer & länger führen da das schon wichtig für die Zukunft von OSM ist (IMO). So wie auch hier beschrieben, wenn auch in einem anderem Kontext: https://karussell.wordpress.com/2015/11/01/units-in-openstreetmap/