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_language zu 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.