Zweisprachige Namen im Siedlungsgebiet der Sorben/Wenden reloaded

+10

Was die Ortsnamen anbelangt, dürften so ziemlich alle Ortsnamen (zu mindestens im Niedersorbischen Sprachgebiet) unabhängig vom Tage name=xy auf jeden Fall auch name:de=x sowie name:dsb vorhanden sein. Nur innerhalb des amtlichen Niedersobischen Siedlungsgebiets (Grenze hab ich mehrfach verlinkt) taucht derzeit name=deutsch - niedersorbisch auf. Eine automatisierte Lösung vor allem auf Basis einer Grenze würde ich noch immer begüßen. Das hatte ich ganz zum Anfang irgendwann mal geschrieben. Darum hatte ich ja diese Grenze seinerzeit mal erstellt.
Was die Straßennamen anbelangt, so sind bereits eine ganze Reihe sorbischer Straßennamen erfasst (soweit vor Ort vorgefunden und daran gedacht, vom Schild ein Foto zu machen). Hier aber stets ohne name=deutsch - sorbisch. Die Abfrage

[out:json][timeout:100];
{{nominatimArea:"anerkanntes sorbisches Siedlungsgebiet"}}(._; )->.boundaryarea;
(
  way(area.boundaryarea)["highway"~"primary|secondary|tertiary|unclassified|residential|service"];
);
// print results
out body;
>;
out skel qt;
{{style:
way{
  color:yellow;
  width:1;
  opacity:1;
  fill-opacity:0;
  }

way[name:dsb][!name:hsb]
{color:blue;width:3;opacity:1;fill-color:blue;fill-opacity:1;}
way[name:hsb][!name:dsb]
{color:red;width:3;opacity:1;fill-color:red;fill-opacity:1;}
way[name:dsb][name:hsb]
{color:green;width:3;opacity:1;fill-color:black;fill-opacity:1;}
}}

liefert diese. Eine ähnliche Abfrage für Ortsnamen hatte ich mehrfach hier schon verlinkt. Ich hab bloß noch keinen gescheiten Weg gefunden, per Overpass nur name:de und z.B. name:dsb als Textbox darzustellen.

Sven


[bbox:{{bbox}}];
node[place=village];
out;

{{style:
node{
  text: eval('tag("name:de") . " - " . tag("name:dsb")');
}

}}

Weil turbo gerade ein Problem damit hat, hier noch ein Screenshot von der schweizer Instanz :sunglasses:

Eieiei…

Vielen Dank… Das probiere ich heute aben mal.

Sven

Auf overpass-turbo.eu wird das heute Abend evtl. noch nicht funzen, es gibt da eine kleine Regression

Kleiner Schnelltest eben… Geht in die Richtung, wie ich mir es vorstelle. Kann man auch einen Zeilenwechsel machen? also

{{style:
node[name:de][name:dsb]{
  text: eval('tag("name:de") . *zeilenwechsel* . tag("name:dsb")');
}

}}

mit dem Ergebnis das name:dsb stets unter name:de steht?

Sven

So, der Fix ist da, Testen ist unter http://overpass-turbo.eu/master möglich.

Ich glaube, das geht nicht.

Hm. Und was ist mit Gemeinden, in denen die sorbischen Namen oben und die deutschen unten stehen? Was machst du da?

Generell zur Frage von zweisprachigen Straßennamen: Die Benennung ihrer Straßen regelt – im Unterschied zur Benennung von Gemeinden und Ortsteilen – jede Gemeinde für sich. Es gibt Gemeinden, die haben ein offizielles zweisprachiges Namensverzeichnis, es gibt Gemeinden, die haben zwar zweisprachige Straßenschilder, aber nie ein Verzeichnis angelegt, und es gibt auch Gemeinden im Siedlungsgebiet, die es bisher versäumt haben, zweisprachige Straßenschilder aufzustellen. D.h. eine einheitliche Regelung wie bei den Ortsnamen gibt es hier nicht. Daher halte ich es nicht für sinnvoll, hier irgendetwas am name-Tag zu ändern.

Auch bei den drei Gemeinden, in denen grundsätzlich das Sorbische oben steht, würde ich aus Gründen der Einheitlichkeit darauf verzichten wollen, den name-Tag zu ändern.

Wie würde so ein Ansatz denn Deiner Meinung nach aussehen?

ich sehe da nämlich keine einfache Lösung.

Ich habe mir bei der Lokalisierung im deutschen Kartenstil sehr viel Gedanken gemacht und ich verwende immer dann “name” unverändert, wenn name:de Bestandteil von name (als ganzes Wort ist). Die Sache mit dem ganzen Wort ist z.B. bei “Rom / Roma” notwendig.

Machen tue ich das genau wegen den mehrsprachigen Gebieten und/oder Städten an Sprachgrenzen. Es wäre IMO schlichtweg unschön dort name:de und name zu rendern und damit name:de doppelt.

Ich freue mich sehr über bessere Vorschläge, am besten gleich als pull-request. Mir sind nämlich keine eingefallen.

https://github.com/giggls/mapnik-german-l10n/blob/master/plpgsql/get_localized_name.sql

Funktion osml10n_gen_combined_name

Gruss

Sven

eine fertige Lösung kann ich leider nicht anbieten. Ich hätte aber einen Diskussionsvorschlag.

Wie wäre es die Bildungsvorschrift für den zu rendernden Namen an geeigneter Stelle, beispielsweise als neuen tag zu speichern. In diesem ist abgelegt aus welchen Namensbestandteilen der zu rendernden Namen bestehen soll.

In meiner unbeschreiblichen Naivität stelle ich mir das etwa so vor

Beispiel für die sorbischen Namen in Deutschland:
name:build:de = name:de + Trennzeichen + name:dsb + Trennzeichen + name:hsb

Beispiel für die deutschen und italienischen Namen in Südtirol
name:build:it = name:it + Trennzeichen + name:de

Trennzeichen soll in meinem Beispiel für ein beliebiges Trennzeichen aus dem Unicode-Zeichensatz einschließlich des Zeilenumbruchs bestehen. Das “+” soll hier im Beispiel die Textverknüpfung symbolisieren.

Ist kein name:build:xx vorhanden könnte die Darstellung wie bisher erfolgen.

so ich ducke mich jetzt mal weg

Eisenspleiszer

Nachtrag:
für den Fall, dass mehrere Bildungsvorschriften in einem Land benötigt werden, sollte vielleicht nicht das Länderkürzel - in den beiden oben stehenden Beispielen de und it - sondern auch ein beliebiger way verwendet werden können.

Hm und wie bekommt man das dann mit der Absicht unter einen Hut bevorzugt in einer bestimmten Sprache rendern zu wollen wie ich das eben zum Beispiel beim deutschen Kartenstil mit deutsch mache?

Im Prinzip sind das ja keine Eigenschaften von Objekten. Was Du eigentlich haben möchtest sind Polygone mit Sprachgebieten.

Was mich ja ehrlich gesagt bei Städten wie Bozen und Bauzen stört ist nicht die Zweisprachigkeit im name tag sondern die Uneinheitlichkeit von deren Trennung (Klammern, Bindestriche etc.) und Reihenfolge.

Ein Beispiel:

Normal hätte ich in der deutschen Karte z.B. folgendes:
Mailand
Milano

Getrennt durch einen Zeilenumbruch (bzw. im Code einstellbaren anderen Zeichen oder Klammern).

Bei Bozen und Bautzen wäre also um der Einheitlichkeit Willen folgendes schön:
Bozen
Bolzano

Bauzen
Budyšin

Durch die Logik bei Vorkommen von name:de in name aber letzteres zu verwenden wird folgendes draus:
Bolzano - Bozen
Bauzen - Budyšin

Das gibt ein unschönes Kartenbild und eine uneinheitliche Beschriftung.

Nun könnte ich natürlich so was in der Art machen:

Suche alle name:* tags durch und sehe nach ob sie in name vorkommen. Wenn das der Fall ist, dann rendere diese tags zusätzlich zur Zielsprache.

Um die Rechenzeit nicht all zu sehr aufzublasen macht man das natürlich nur, wenn der name in der Zielsprache in name vorkommt und dieser nicht identisch mit name ist.

Dadurch wäre ich die falschen Feldtrenner und Sprachreihenfolgen los.

Was haltet ihr denn davon?

Gruss

Sven

Moin,

das wäre eigentlich die “einzig wahre Möglichkeit” - die Mehrsprachigkeit in name=* ist eigentlich nur eine Krücke, um auch ‘einfachen’ Renderern die Info zu bieten.

Das wäre das Optimum - und ist (eigentlich *) nur durch obige Sprachgebiete erreichbar, denn …

dieses Vorgehen stört ja Deine eigene sinnvolle Logik - und ersetzt sie durch das Fehleranfällige in name=*.

(*) Das wäre zwar immer noch ein ziemlicher Würgaround (zudem mit erheblichem Aufwand) - käme aber einer Sprachregion ja schon sehr nahe und würde das Erscheinungsbild deutlich verbessern.

Grüße, Georg

Jo, aber mir ist halt wie gesagt nichts wirklich sinnvolles eingefallen wie ich die lokale Alternativsprache rausfinden kann. Dass ist halt alles extrem inkonsistent. das liegt aber gar nicht mal an OSM sondern an der realen Welt.

Bei den Ländernamen hat das dazu geführt, dass ich eine eigene Liste der Amtssprachen pro Land verwende und den name Tag komplett ignoriere.

Ich glaube ich werde das mit der Suche der Alternativnamen im generischen name mal implementieren, das erscheint mir echt noch am sinnvollsten zu sein.

Was ich halt unter allen Umständen vermeiden möchte sind doppelte Namen.

Der Ländercode verwendet da sogar die Levenshtein Distanz zwischen Namen damit da nicht sowas steht wie:
Ísland
Island

Das ist alles furchtbar kompliziert. Wenn es eine einfache Lösung gäbe hätte ich die schon implementiert.

Gruss

Sven

Das es zu mindestens für das Niedersorbische erst mal gibt…

Was jetzt noch fehlt, ist die Angabe für welche Sprachen diese Mehrsprachigkeit gilt…

mir schwebt schon lange ein Tag wie

multilingual=de;dsb

im Kopf herum. Die Ländercodes stehen in der Reihenfolge des Anteils der Sprache bei amtlich festgelegten mehrsprachigen Gebieten.

Eine einfachere Variante könnte ich mit auch vorstellen, daß wie hier multilingual=de;dsb an das Place-Node gehängt wird und danach name:de und name:dsb gerendert wird.

Sven

+1

+10

+10

Bei der konsequenten Speicherung der entsprechenden Sprachversion des Namens im dazugehörigen name-Tag (name:de = Bautzen, name:hsb = Budyšin?, name:dsb = Budyšin?, name:de =Bozen, name:it = Bolzano, …) dürfte das Problem mit dem unschönen Kartenbild nur in der Übergangszeit auftreten. Die bisherige Schreibweise mit Bindestrich, Schrägstrich, … rührt ja nur aus den Unzulänglichkeiten des bisherigen Systems.

Im übrigen ist “Schönheit des Kartenbildes” Aufgabe des OSM-Renderers. Die Datenbank stellt nur die Daten in hoffentlich geeigneter Struktur zur Verfügung.

Heißt konkret: Wenn es DEN Namen nicht gibt müssen die Namen nach Sprachen :de etc. erfasst werden und der Renderer bestimmt, welche Namen er anzeigt und wie.

Ich denke als erstes müsste man “Sprachgebiete” mal definieren. In der OSM-Datenbank könnte man das beispielsweise mit Polygonen/Relationen machen, die manuell gepflegt werden und Informationen zu den dort gesprochenen Sprachen enthalten. Vorher müsste man aber Regeln definieren, was zu diesen Sprachgebieten gehört, und was nicht.

Der Status als Amtssprache sagt oft gar nichts über die Bedeutung einer Sprache für eine Region aus. Es gibt genug Fälle von Gebieten, in denen Sprachen keine Amtssprache sind, aber von der Mehrheit der Bevölkerung gesprochen werden. Beispiele wären Kurdisch in der Türkei, Russisch in der Süd- und Ostukraine, Armenisch in Südgeorgien, diverse einheimische Sprachen in Afrika oder Südamerika, etc. Allerdings gehört das für mich trotzdem nicht in ein Standard-Rendering, da Edit-Wars dann praktisch vorprogrammiert sind. Es ist praktisch unmöglich, sowas objektiv festzulegen, daher können wir uns eigentlich nur nach dem offiziellen Status richten, als einzigem objektiven Kriterium um “Sprachgebiete” abzugrenzen.

Oft ist in offiziell bilingualen Ländern eine Amtssprache aber von wesentlich geringerer Bedeutung als die andere, z.B. Irisch vs Englisch in Irland oder Schwedisch vs Finnisch in Finnland. Obwohl es in diesen Ländern offiziell zwei Amtssprachen gibt, wird aktuell nur eine davon im Standardnamen verwendet.

Eine praktikable Lösung wäre es für mich, bei den Relationen zu Staaten zusätzlich die Amtssprachen anzugeben. Innerhalb der Staaten kann man dann Subrelationen für kleinere Sprachgebiete anlegen, z.B. die sorbischen Gemeinden in Deutschland. Standardmäßig erben diese Gebiete dann die Amtssprache des enthaltenden Staats und fügen ihre eigene Sprache hinzu. In Südtirol würde dann Italienisch von Italien geerbt und zusätzlich Deutsch hinzugefügt. (Für Teilregionen wie Québec, die explizit nicht die Amtssprache des “Mutterlandes” übernehmen, sollte das “Erben” auch abstellbar sein). Unter Umständen kann es bei den Relationen zu Sprachgebieten noch ein Attribut wie “showperdefault”=“yes”/“no” und “mainlanguage”=“sprachcode”. geben. Manchmal ist es wichtig, eine Sprache im Kartenbild explizit als “primär” erkennbar zu machen, manchmal hat eine offizielle Sprache explizit einen weniger privilegierteren Status als andere.

Wie man zwei Sprachen optisch schön auf eine Karte bringt, zeigt z.B. Yandex.Maps ganz schön: https://yandex.ru/maps/145/odesa/?ll=30.735935%2C46.474995&z=15

Das entspricht exakt der Lösung, die ich bei der Lokalisierung im deutschen Kartenstil gewählt habe.

Gedankenstriche oder Klammern sind aus vielen Gründen keine gute Idee.

Ich habe nochmal über meinen Vorschlag nachgedacht und bin zum Ergebnis gekommen, dass es keine gute Idee ist
da eine Lösung für den Super Sonderrfall einzubauen, dass “name” sowohl die Zielsprache als auch andere Sprachen enthält.

Das kommt letztendlich nur in Gebieten vor, in denen Ortsnamen innerhalb von name sowohl in der Zielsprache (deutsch) als auch in anderen Sprachen erfasst sind.

Die bisherige Lösung in diesem Fall einfach die Finger weg zu lassen und name unverändert zu verwenden führt im allgemeinen vermutlich zum besseren Ergebnis.

Ich rede hier ja von weltweitem Rendering und eben nicht nur von einer Karte der deutschen Sprachgebiete.

Eigentlich bräuchte man “name” als Liste, dann wäre es den Datennutzern überlassen wie sie die Liste dann darstellen.

Gruss

Sven

So, ich habe gestern meine Idee nun doch mal in den Lokalisierungscode des deutschen Kartenstils eingebaut.

So richtig elegant ist die Technik mit dem string match in name aber nicht.

Bei zweisprachigen Gegenden im Ausland wird nämlich nach wie vor “name” gerendert weil ich derzeit gar keine Möglichkeit habe herauszufinden welche Sprachen die dort lokal üblichen sind.

Das sieht man beispielsweise in Südtirol, wenn die Zielsprache auf englisch steht statt auf deutsch.

Spontan wäre mir noch Koriska eingefallen, aber dort ist es anscheinend derzeit nicht üblich den name-tag zweisprachig in französisch und korsisch zu erfassen.

Hier sind ein paar links.

Karte mit deutscher Lokalisierung:
https://tile.openstreetmap.de/#map=12/51.1755/14.434/2
https://tile.openstreetmap.de/#map=10/46.6447/11.3846/2

Die selben Gebiete mit englischer Lokalisierung:
https://tile.iosb.fraunhofer.de/#map=12/51.1755/14.434/2
https://tile.iosb.fraunhofer.de/#map=10/46.6447/11.3846/2

Gruss

Sven