Zweisprachige Namen im Siedlungsgebiet der Sorben/Wenden reloaded

Zur Info… heute gesehen:
Ich schätze mal eines der ersten (das erste?) zweisprachige Straßennamensschild in Lübben / Lubin.

Sven

PS: Foto mit Geokoordinaten, leider mit 65m Versatz nach SSW; verdam… Schei…

Dieses Foto, wie auch weitere in der Diskussion vorgebrachten (z.B. von J budissin hier: https://forum.openstreetmap.org/viewtopic.php?pid=592169#p592169 ) und meine Erfahrung beweist, dass die Schilder im sorbischen Sprachraum um den es hier geht immer zweizeilig (die erste Zeile deutsch, die zweite Zeile sorbisch - da gibt es keinen Schrägstrich, keinen Trennstrich und auch nichts anderes außer einem Zeilenumbruch!) sind. Wie soll das in der Datenbank dagestellt werden?

Bei der Suche nach der so korrekten Lösung sollte dies das erste Problem sein, was zur Diskussion stehen sollte.

Gruß Uwe

Mit dem normalen name-Tag wird das wohl nicht gehen. Es gab ja schon öfters mal den Vorschlag, diesen Tag abzuschaffen. Ein Leerzeichen als Trennung zwischen den beiden Straßen geht meiner Meinung nach aber gar nicht. Es gibt dann doch praktisch keine Möglichkeit für den Renderer festzustellen, was jetzt Teil des deutschen und was Teil des sorbischen Namens ist. Beispiel: Groß Särchen - Wulke Ždźary . Woher weiß der Renderer dann ob der deutsche Name “Groß”, “Groß Särchen” oder “Groß Särchen Wulke” lautet? Zumal bei Straßennamen auf Karten sowieso keine Darstellung untereinander möglich ist.

Die einzige brauchbare Lösung ist für mich, dass man konsequent alles mit name:de, name:hsb und name:dsb taggt und wir einen brauchbaren Ansatz für OSM-Renderer in mehrsprachigen Gebieten entwickeln. Das wäre eine positive Entwicklung nicht nur für die sorbischsprachigen Gebiete, sondern für praktisch alle mehrsprachigen Gebiete weltweit.

Derzeit ist das multilinguale Mapping in OSM komplett chaotisch und von Region zu Region unterschiedlich. In Indien verwendet man gleich durchgängig Englisch, alle lokalen Sprachen sind in name:* zu finden, in Sizilien verwendet man mal einen Bindestrich, mal einen Slash (/), in Russland sind Minderheitensprachen grundsätzlich nie im Standardnamen finden, in Usbekistan gibt es eine Region wo im Standardnamen ausschließlich die Minderheitensprache verwendet wird, in Südkorea verwendet man im name-Tag teilweise eine englische Transkription in Klammern, teilweise aber auch nur den koreanischen Namen, in China hat jemand Minderheitensprachen ohne Trennstrich in den Namenstag gepackt… ich glaube wir brauchen eine OSM-einheitliche Methode wie mit sowas umgegangen werden soll.

eigentlich dachte ich das wäre bereits erledigt:


name:de=deutscher Name (erste Zeile)
name:(wen|hsb|dsb)=(westslawischen|obersorbischer|niedersorbischer) Name (zweite Zeile)

Und wenn es jetzt noch darum geht, was in


name=xxx

(Fallback) soll, so würde ich zur ersten Zeile tendieren (*)

ADD: (*) und zwar einfach nur aus Pragmatismus und ohne größeren Überlegungen heraus, was jetzt die Amtsprache sein könnte usw. Wäre in der Region das westslawische wichtiger, würde es wohl auch in der ersten Zeile stehen. Punkt.

+1

+1

+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