Und genau damit es nicht ausstirbt, ist es so wichtig, präsent zu sein!
Grüße von Lutz
Nur noch zwei Anmerkungen dazu:
Das ist kein großes Wunder, wir sind kein großes Volk. Auf einer Rückseite in irgendeinem Forum wird man kaum erwarten können, dass zufällig fünf Sorben vorbeischneien. Die zweisprachige Darstellung offiziell zweisprachiger Orte liegt natürlich unabhängig davon im ureigensten sorbischen Interesse und wird auch von der Domowina (unserer anerkannten Interessenvertreterin) konsequent angemahnt.
Zudem bringt es auch keine Punkte, diese Entscheidung vom Juli letzten Jahres mir als Einzelnem anzulasten. Die Diskussion hier ist öffentlich einsehbar und Zuspruch gab es – neben Widerspruch – auch von zahlreichen anderen Mappern. Wir müssen das hier nicht alles noch einmal wiederkäuen, letztlich wurde die OSM-Sprachpolitik für die Lausitz nach dieser Diskussion lediglich der Realität vor Ort (zweisprachige Beschilderung), der rechtlichen Situation (Sorbengesetze der beiden Länder) und dem Vorbild anderer mehrsprachiger Regionen in Europa hier auf OSM (Kärnten, Südtirol, Slowenien, Belgien etc.) angepasst.
Ganz genau. Und genau aus diesem Grund gibt es dazu auch Regelungen und eine amtliche Praxis. Das mag nicht jeder gut finden, es ist allerdings Tatsache.
Nebenbei: Wie erkennst Du einen Sorben? Weil er sich sorbisch im Forum gibt? Weil er sorbisch spricht? Weil er sorbische Eltern hat? Weil er sorbisch fundamentalistisch redet?
Die Diskussion hatten wir zwar schon, aber nocheinmal: zweisprachige Darstellung heißt nicht, dass es im Datenbankfeld “name” zweisprachig rein sollte/muss!
Ich meinte das anders. Minderheiten werden immer etwas machen was der Mehrheit nicht gefällt. Sonst wären sie ja in der Mehrheit. Aber natürlich sollten und werden beide Seiten ordentlich miteinander reden (können).
Sind eigentlich in den sorbischsprachigen Gemeinden die Straßennamen offiziell nur Deutsch? Immerhin scheinen ja auch viele Straßen mit sorbischen Namen getaggt worden zu sein - im Gegensatz zu Ortsnamen wird da aber nur der deutsche Name verwendet.
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 
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