Zweisprachige Namen im Siedlungsgebiet der Sorben/Wenden reloaded

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 :slight_smile: ? 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 :slight_smile:

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/

Ja, von der Mehrheit der Einwohner dieser Gemeinde. In der Nachbargemeinde kann es andersrum sein. Dass ein italienische Name dabei sein muss, steht im Autonomiestatut, die Reihenfolge steht dort nicht. Deshalb …

Ich finde, für uns wäre es pragmatisch, die Leute da draussen in der echten Welt den Schilderstreit führen zu lassen und einfach das Ergebnis zu übernehmen. Das entlastet uns eher von den Konflikten, finde ich. Jedenfalls die Menschen, die Datenbanken nicht…

Mit automatischen Umrechnen von Fuß in Meter ist das schwer vergleichbar. Ob der Betrachter einer Karte lieber metrische Angaben mag, kann man ihn einstellen lassen oder raten. Wie die lokale Bevölkerung ihren Ort nennt, ist schwer zu sagen. Dafür bräuchten wir entweder ein Tag, das uns den “Ortschildnamen” (für Router: “Wegweisernamen”) aus name:xx zusamenbasteln lässt, oder wir tragen Regionen ein und legen für die fest, welche Sprachen dort bevorzugt werden (entweder per Einzelfallentscheidung anhand politischer Grenzen “in Südirol reicht deutsch”, oder mit diesen Sprachregionen, die Streckenkundler gerade malt). Ich glaube aber nicht, dass sich Regionen durchsetzen werden, bei jedem Namen eine geometrische Abfrage durchzuführen, wird nicht beliebt werden.

Ansonsten bleibt uns nur die Orientierung an der Zielgruppe (“wir nehmen immer metrische Angaben und name:de”), dann kommt sowas wie der deutsche Stil raus, bei dem wir uns dann wieder darum streiten, ob name:de nicht zu revisionistisch klingt :wink:

Grüße, Max

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”)

Sowas?

name:de=Cottbus
name:dsb=Chóśebuz
name:hsb=Choćebuz
name:lt=Kotbusas
name:official_lang=de;dsb
name:official_lang:delimiter=/
name:most_common_lang:de

Von einem recht theoretischen Standpunkt aus gesehen schon schön …

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.

+1
Außer in Bozen und einigen Gebieten im unteren Eisacktal südlich davon, ist Südtirol überwiegend deutschsprachig bzw. im Val Gardena ladinischsprachig, siehe Grafik lt. Zensus-Daten in dem in #50 verlinkten Wiki-Artikel http://wiki.openstreetmap.org/wiki/File:Language_distribution_in_South_Tyrol,_Italy_2001.png

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.

Gruß
Klaus

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.

Sven

Ah, okay. Also mit dem Kompromis kann ich leben. Auch wenn das Datenduplikation ist und m.E. weniger Sinn macht.

Meran ist da übrigens weiße Fläche.

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.

Weil die Sprachgruppenverteilung dort 50/50 beträgt, sehr kleingedruckte :wink: Fußnote unter der Legende.

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 :wink:

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:
Ortstafel

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).

Auf die gleiche Weise auf die sichergestellt wird, dass auf gedruckten Karten die Zweisprachigkeit dargestellt wird. Also gar nicht.

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?

Die nehmen eine Karte, welche sorbische Namen rendert.

PS: Das sage ich, obwohl ich sorbische Wurzeln habe.

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 :wink: )