Was meinst du? Der Vorschlag, den @dieterdreist meint ist kein name zu taggen, wenn ein Objekt nicht einen Namen hat. Sondern name:de und name:dsb=* und evtl. auch noch weitere name:* und zusätzlich ein default_language=de;dsb. Damit hast du explizit erfasst, was die lokalen Sprachen sind. Ein Renderer/Auswerter kann das dann interpretieren oder darstellen. Bspw. die Verbreitung einer Sprache flächig darstellen, oder simple den Namen rendern mit einheitlichen Trennzeichen zwischen den Namen oder, oder, oder
1 Like
Ich habe gerade das noch in der Hilfe von Keep Right gefunden:
" Der name-Tag ist laut OSM-Wiki so definiert, dass man den gebräuchlichen Namen in einen einfachen name-Tag setzen kann, ohne ein Sprachkürzel verwenden zu müssen. Dazu heißt es im OSM-Wiki auch: „Wenn der name-Schlüssel ohne eine Sprache angegeben wird, so bezeichnet die Variable dahinter grundsätzlich den offiziellen Namen in der Landessprache.“ (vgl. DE:Names).
Das bestehende name-Tag (ohne Sprachkürzel) soll jedenfalls erhalten bleiben."
Bin darauf gestoßen, weil KeepRight Fehler beim Namen der Neiße (Grenzfluss) meldet.
Da steht z.Bsp. auch in namen=Lausitzer Neiße / Nysa Łużycka aber in name:de=Lausitzer Neiße und in name:pl=Nysa Łużycka. Deswegen gibt es auch die Fehlermeldungen, weil Name mit name:de und mit name:pl nicht identisch sind.
Ist das gleiche Problem, wie gestern mit der Insel Usedom. Da müsste eigentlich auch nur Usedom in name drin stehen und nicht Usedom - Uznam.
Übrigens steht in Swinemünde auch nur Świnoujście in seinem Namenstag drin, also in der Landessprache. Aber vielleicht kann man das nicht miteinander vergleichen…
Warum, Usedom gehört nunmal sowohl zu DE als auch zu PL?
Dann wäre es ja korrekt, wenn man beide Namen auch in name:de und name:pl einträgt?
Nein, natürlich nicht. name:de = Usedom, name:pl = Usnam.
Na, Keep Right ist dort ganz einfach im Unrecht 
Bitte beachte, dass solche Einträge in name=* Ausnahmen sind, berechtigte Ausnahmen.
1 Like
Ob es berechtigt ist, da scheiden sich die Geister wie gesagt. Es wird praktiziert, weil es dann auch OSMCarto “entsprechend” dargestellt wird. Datentechnisch ist das nachteilig, weil der Renderer keine Informationen zu den lokalen Namen enthält. Nur ein Text, der irgendwie von irgendeinem Mapper so formatiert wurde.
Es gibt aber keine Information, ob jetzt name=Frankfurt / Oder eine Sprache ist oder zwei Sprachen. 
2 Likes
Diese Namesgeschichte in OSM ist solange ich bei OSM dabei bin, kompliziert… Irgendwie in diese Richtung gehen meine Gedanken, ja!
Wenn ich z.B. hier bei anhand von Straßennamensschildern eine Zweisprachigkeit des Straßenamens feststelle, dann kommt der sorbische Name nach name:dsb=xy; der deutsche Name nach name:de=xy; name=xy ignoriere ich dann, ist gedanklich nicht mehr existent, ich lösche es aber nicht vorsätzlich…
Wegen der besonderen Situation des sorbisch-wendischen Siedlungsbebietes hier in der Lausitz wäre es meinem Verständnis nach zulässig den deutschen, als auch sobischen Namen dann in name=xy zu erfassen… Ich verzichte kulanterweise darauf, da das dann per name:xy=xy jeweils abgedeckt ist.
zurück zur Neiße… Die Neiße hat diverse Namen: was davon wie im name:xy=xy - Tag alles schlußendlich korrekt ist, wird keiner von uns sagen können… Da ist Akzeptanz des Erfassten zwingend erforderlich, wie so bei vielem anderen auch!
Ich vermute, daß für deutsche Namen das name:de=xy unterrepäsentiert ist. Ich meine, OSM hatte mal vor Generationen Karten mit sprachspezifischen Darstellungen der Namen allgemein…
Ich bin Müde, das Bett ruft…
Sven
erhält er doch, also dass man weiß, was die lokalen Namen sind, aber bisher kann man allgemein nicht erfahren, in welcher Sprache die sind, man kann es lediglich “raten” wenn es die Schreibweise nur in einer Sprache gibt (die Liste könnte aber auch unvollständig sein).
Wie erhält er das denn?
Nimm name=Usedom - Uznam woher soll man wissen ob in name jetzt ein oder zwei Sprachen drin sind? In dem Fall könnte es evtl. gehen… Man könnte errechnen, dass die Insel in Deutschland und Polen ist und dann prüfen ob name:de oder name:pl in name enthalten ist und wüsste dann, dass name zwei Sprachen enthält. Das ist aber eher ein Sonderfall, weil es sich um zwei Länder handelt. Typischerweise ist das ja nicht der Fall. Usedom könnte aber genau so gut Englisch sein. Also ja, man kommt mit Raten zu einem Ergebnis, ob es gut ist lasse ich mal dahingestellt.
die Regel ist, " - " um Sprachen zu trennen, bzw. " / ", beides kommt vor, je nach Gegend, also jeweils mit einem Leerzeichen getrennt vom Wort.
Man weiß aber bei “Usedom” trotzdem nicht, ob das deutsch oder italienisch oder französisch ist. Bzw. hier ist die Lage derzeit noch halbwegs klar, weil es von den getaggten Namen nur dem deutschen entspricht, aber wenn dann mal jemand vorbeikommt, der weitere 89 Namen in anderen Sprachen aus der Wikipedia kopiert, und 60 davon “Usedom” sind, dann nicht mehr. Und das ist nicht hypothetisch sondern bei den meisten Städten schon der Fall…
Also in der Schweiz und Nordirland scheint es “/” zu sein, in Belgien " / ", im Baskenland kann ich " / " und “/” finden, in Tirol und in den sorbischen Gebieten " - ". “/” wird dagegen in Deutschland als anderweitiger Trenner verwendet. Und das ist jetzt nur West- und Mitteleuropa.
Mehr als raten kann da ein Auswerter da nicht, es sei denn man schreibt Regeln für jede Region und hofft, dass die zumindest innerhalb der Region einheitlich sind.
1 Like
stimmt schon dass es weder einheitlich ist, noch in allen Fällen konsistent was die Anwendung von Leerzeichen zwischen dem Trenner angeht, aber bisher hat sich dieses “System” als verträglichstes erwiesen wo mehrere default-Names in Benutzung sind (es finden sich diese oder ähnliche Trenner in solchen Gegenden oft auch vor Ort). Wenn die Sprachen unterschiedliche Zeichen verwenden, ist ggf. auch gar kein Trennzeichen vorhanden (soweit ich das beurteilen kann) https://www.openstreetmap.org/node/25730724
Also, some regions use a hyphen both as a value separator and as something else:
Ja wie ich sagte: Das ist funktional wenn der Mapper das irgendwie ein gibt und der Renderer einfach nur stupide name darstellt. Mehr Informationen bekommt der Auswerter nicht und kann dementsprechend auch nicht viel mehr machen.
Sollte man evtl. überdenken, ob das mit den zukünftigen Vectortiles dann noch so sinnvoll ist.
1 Like
Vielleicht kann man auch hier noch einmal nachlesen. Allerdings hatte ich diesen Topic irgendwann nicht mehr verfolgt, fragt mich also bitte nicht nach einem Kompromiss, Konnsens oder Ergebnis.
Multiple delimited names in the name tag
Ist schon ein bissle was her, aber wenn ich mich erinnere gibt es die Ansicht name=* enthält nur einen Namen, keine Liste von Namen und negieren, dass es mehrere gleichwertige Namen an einem Objekt geben kann. Dazu gehören u.a. auch die Macher hinter OSMCarto. Weshalb OSMCarto auch einfach stupide name rendert. Mapper passen sich dem an und schreiben einfach eine “hübsch getrennte” Liste in name. Die dann (s.o.) aber nicht mehr von Maschinen gelesen werden kann.
Dann gibt es die Idee name kann auch Listen enthalten und wie bei anderen Value-Listen in OSM sollte ; der Trenner sein. Wäre dann maschinenlesbar, weil eindeutig trennbar. OSMCarto würde weiterhin alle Namen rendern, aber nicht mehr ganz so hübsch getrennt oder sich halt anpassen. Hat den Nachteil, dass man immer noch nicht weiß, welche Sprache lokal gesprochen wird. Ist dafür aber im Prinzip kein Mehraufwand für den Mapper. Eine ;-getrennte Liste wird bspw. von OSM Americana unterstützt und reicht für dynamische Namen in einer Karte aus.
Die andere Idee ist einen Tag wie default_language zu verwenden, um die lokalen Sprachen zu erfassen. Hat den höchsten Informationsgehalt, aber ist halt auch Aufwändig in der Umsetzung.
Die andere Idee ist einen Tag wie
default_languagezu verwenden, um die lokalen Sprachen zu erfassen. Hat den höchsten Informationsgehalt, aber ist halt auch Aufwändig in der Umsetzung.
wenn ich das richtig in Erinnerung habe, war der Vorschlag zu default_language ziemlich aufwendig, weil dabei diese Defaultsprache vererbt werden sollte, d.h. man hätte sich alle umschließenden Polygone ansehen müssen bis eines kommt das einen default_language tag hat. Wenn man einfach statt “name” (nach einer Übergangszeit) sagen würde, lokal ist hier “de” und “pl” (als Beispiel), dann wäre das einfacher auszuwerten. Noch einfacher als “name” geht es natürlich nicht.
Genau. Der Text oben ist nur meine Zusammenfassung aus dem ganzen Thread.
Sehe das ansonsten wie du. default_language anstatt name oder zusätzlich zu name an jedes Objekt zu taggen wäre an dann wieder sehr einfach in der Umsetzung und hat auch keinen “single point of failure”.
Erinnere mich aber nicht mehr, ob das damals diskutiert wurde und wenn, warum es verworfen wurde.
1 Like
@Jochen_Topf hatte das meine ich mal zu Testzwecken mit transparenten Kacheln umgesetzt. Hier der damalige Vortrag auf der Fossgis: https://av.tib.eu/media/15836