Zur Reihenfolge der Sprachen gibt es in Südtirol die Konvention, die lokal dominante Sprache in name=* zuerst zu setzen - wie auf den Straßenschildern!
In name=* werden alle amtlichen Sprachen deutsch - italienisch (und ggf.) - ladinisch abgebildet. Zusätzlich wird name:de, name:it und name:lld erfasst.
Eben… Das setzt aber voraus, daß die Editor-Software weiß, welche in diesem Fall name-Tags sie darstellen soll…
Wir habe doch die ganzen name:xy=* Tags… Wenn ich nun für Südbrandenburg eine Grenze erstellen würde, die aussagt: ‘Das ist die offizielle zweisprachige Grenze mit name:de und name:dsb’, dann gebe ich dem Renderer das notwendige Mittel dazu, dann kann ein Renderer genau für diesen Bereich die Namen entsprechend rendern und muß nicht Tags dazu verbiegen. Daß es für angrenzende Orte außerhalb dieser Grenze auch einen Namen in der betreffenden Sprache gibt ist da erst mal unerheblich.
Das ist mMn der einzig gangbare Weg in Gebieten mit mehreren Amtssprachen. Ich hätte sogar nichts dagegen, name=* dann wegzulassen, aber da spielen die meisten Anwendungen nicht mit. Dann fiele nur die Information weg, was offizielle Namen sind. Damit muss man das arme name=*-Tag aber nicht unbedingt überladen.
Interessantes Detail.
Nach meiner Erinnerung ist die Abfolge auf Schildern in Meran de - it, aber da kann ich mich bei meinem nächsten Besuch mal umsehen, vielleicht wechselt das je nach Stadtviertel
Deshalb halte ich die Angabe der Sprachkürzel für wichtig: a) Sie können gezielt ausgelesen werden. b) Andere OSMler wissen, welche Sprache überhaupt gemeint ist, um Fehler korrigieren oder weitere Varianten ergänzen zu können.
Edit: Bevor man hier lange Listen erstellt, könnten OSM-Anwendungen die Informationen wahrscheinlich aus Wikidata abfragen?
An welche Art von Listen denkst du? In Wikidata haben wir an Namen ja nur die Orte zur Verfügung, die in den drei fraglichen Wikipedien bereits mit Artikeln bedacht wurden. Da sieht es insbesondere in der dsb.wp allerdings noch sehr dünn aus. Ansonsten gäbe es sowas: https://de.wikipedia.org/wiki/Deutsch-Obersorbische_Ortsnamensliste
Es scheint, als sei die Diskussion erneut eingeschlafen, ohne dass wir zu einem klaren Ergebnis gekommen wären. Einige stimmen mir offenbar zu, andere eher nicht. Deshalb noch einmal die Frage: Wie wollen wir in Zukunft gewährleisten, dass die gesetzlich garantierte Zweisprachigkeit im amtlichen Siedlungsgebiet der Sorben/Wenden in Brandenburg und Sachsen sowie der Umstand, dass alle dort befindlichen Orte laut Brandenburgischer Kommunalverfassung von 2014 offiziell einen zweisprachigen Doppelnamen tragen, auf OSM-Karten dargestellt standardmäßig dargestellt werden? Die Lösung, dass vom Wohlwollen/Wissen des Renderers abhängig zu machen, halte ich für keine praktikable Lösung. Ich gehe davon aus, dass dann weiterhin – wie ja auch jetzt im Moment – die zweite amtliche Sprache hinten runterfällt und ignoriert wird. Finde ich nicht akzeptabel. Fakt ist, dass wir es mit einer amtlich und auch “on the ground” zweisprachigen Gebiet zu tun haben, was sich aber bisher auf OSM-Karten nicht niederschlägt.
So sieht übrigens die Realität “on the ground” aus:
Aus Anwendersicht: Für mich ist und bleibt es Cottbus. Mit dem anderen Namen kann ich nichts anfangen. Genauso, wie ich mit den meisten Namen in anderen Schriften nichts anfangen kann (da hilft mir auch mein Altgriechisch nichts).
Mit dem anderen Namen kannst du (!) als deutscher Anwender nichts anfangen, ok. Was ist mit dem sorbischen Anwender? Es sollte doch nun wirklich kaum eine Rolle spielen, ob der eine oder andere individuell etwas mit dem zweiten Namen anfangen kann.
Woher nimmst du diese Behauptung? Je nach Verlag werden in der betreffenden Region durchaus beide Namen angeführt. Davon abgesehen: Wäre das für dich ein Argument? Ich höre hier immer wieder, entscheidend sei die Situation vor Ort, also etwa auf Ortsschildern. Die ist eindeutig. Auf einmal sollen nun wieder gedruckte Karten maßgeblich sein. Die sind nicht eindeutig. Was tun?
Sicherstellen kannst du tatsächlich gar nichts. Ich kann ja auch eine nur-deutsche Karte rendern und Du kannst nichts dagegen unternehmen.
Die Diskussion über “sicherstellen” können wir uns aber sparen. Das name-Tag hat schon eine recht grosse Chance, unverändert auf einer Karte zu landen, jedenfalls viel grössere Chance als irgendein name:xx. Das muss als Sicherstellen reichen.
Ich frage mich auch, wie wir weiter kommen wollen. Argumente und Meinungen sind getauscht, Meinungswechsel scheinen kaum stattzufinden…
Grüße
Max (immer noch Anhänger des südtiroler Mappens, auch wenn ich da auf meinen Karten bevorzugt name:de rendere )
Auf einer internationalen Karte ist es wohl besser, wenn es so steht, wie in der Realität auf den Schildern. Daran können sich Touristen orientieren. In solchen mehrsprachigen Fällen halte ich es aber für umso wichtiger, zusätzlich die name:* Tags zu verwenden.
Das ist ja auch vollkommen in Ordnung. Ich kann mir schließlich auch eine nur-sorbische Karte rendern. Es geht quasi um die “Standard-Darstellung”, auch wenn das manche nicht für die passende Bezeichnung halten. Und da hast du nun mal Recht, dass es in den meisten Fällen das name-Tag sein wird, was übernommen wird. Alle technischen Überlegungen in Richtung “man könnte in einem festgelegten Gebiet anders rendern, nämlich zweisprachig” sind einzig und allein vom Renderer abhängig.
Dann haben sie eine rein sorbische Karte. Gibts auch, ist aber hier nicht das Thema. Ich stelle die Frage noch einmal anders: Aus welchem Grund sollte der name-Tag eines Ortes, der offiziell zwei Namen trägt, nur einen davon enthalten?
Weil es kein Doppelname sondern zwei Namen in zwei Sprachen ist. Es wird wohl keine zufriedenstellende Lösung nur mit dem name-Tag geben. Aber ich kann mich damit abfinden, wenn name=* genau das beinhaltet, was auf dem Schild steht, sofern name:= mit gesetzt ist (und auch nur dann).
Sorry, ich habe Deine Antwort erst heute gesehen! Ich habe überlegt, inwiefern es die Möglichkeit gibt, die anderen Namen über wikidata=x von dort automatisiert zu beziehen.
Ja, für mich klingt diese Lösung nach einem Kompromiss der aber suboptimal ist, gerade wenn man etwas in die Zukunft blickt.
@J budissin: Deine Meinung ist zu stark geprägt von der aktuellen Renderingsoftware
In der Zukunft wird es nur noch vektorbasierte Karten geben und dort nimmt man einfach vom User die language Einstellungen aus dem Browser. Und dann ist ein name=“deutscher name / sorbischer name” und name:de=“deutscher name” und name:hsb=“sorbischer name” schon okay, aber es hat einige Nachteile:
Datenduplikation, Dateninkonsistenzen (slash vs. komma?), …
mehr Aufwand beim Mappen
Es gibt kein eindeutiges bzw. einfaches Fallback. Also z.B. für einen Engländer der navigieren will und eigentlich name:en braucht aber dann auf “name” zurückfällt. Der muss sich dann immer 2 oder gar 3 Sprachen anhören bevor er abbiegen kann. Aber das ist natürlich auch mit einer Präferenz auf z.B. DE zu lösen.
Also alles lösbar und “okayish”. Aber m.M. nach zu viele Probleme die man sich hier einfängt …
Fußnote unter der Legende.
