Also ich meinte folgendes: OpenStreetMap ist die Geodatebank, die im Idealfall normalisierte und separate Daten speichert (multilinguale Namen, Zahlen, Einheiten). Und die Editor-Software schafft einen Layer wo man als normalo Mensch / Mapper diese DB benutzt. Aktuell nutzt man ja quasi direkt die rohe DB und das verleitet dann zu solchen komischen Lösungen wo dann zwar der Mapper checkt was los ist* aber es für die Software schwierig wird. Aber eine DB ist dafür da das Software die Daten darin leicht verarbeiten kann und nicht für Menschen.
(* “DE kommt hier zuerst, aber hier als Zweites im Name” oder “Bindestrich steht hier für das Trennungszeichen der Sprachen, aber hier für den Teil des Namens”)
Das Problem besteht nur, wenn man versucht, ein name:de aus name=* herauszuholen. Wenn es einen name:de gibt, sollte man doch den nehmen.
Der Ausweg wäre also, erstens konsequent alle Sprachversionen in name:xx zu taggen, ggf. sogar in anderer Schrift, und zweitens vorhandene “name=”-Einträge entweder unverändert zu übernehmen oder (für sprachspezifische Anzeige) zu ignorieren.
Dann gerät man auch nicht in Gefahr, sich in die Nesseln lokaler Empfindlichkeiten zu setzen.
Die übliche Praxis (z.B. Mapnik) nimmt zuerst name=* und daher der Anreiz, da alles reinzupacken.
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).
Fußnote unter der Legende.
