Zweisprachige Namen im Siedlungsgebiet der Sorben/Wenden reloaded

In Südtirol sind alle Straßenschilder, inzwischen sogar die Wanderwegweiser zweisprachig (die Ladiner Gebiete kenne ich nicht).
Der offizielle Name ist zweisprachig, wer da eine der Versionen als name=* auswählt, begibt sich auf brisantes Terrain.
Es ist mMn Aufgabe des Routers, aus den Angaben name:de=, name:it= und name= - die geeignete für Ansagen auszuwählen, am Tagging liegt das nicht.
Wenn es tröstet: Auch professionelle Navis bringen da z.B. die italienischen Namen in fürchterlicher Aussprache.

Eine Möglichkeit die ich noch sähe, aber sicherlich auch eher kontrovers gesehen wird: man taggt mit name:de und name:hsb (und name:en, usw. usf.) und ins name macht man dann die Varianten die man da haben möchte. Also bspw. name=name:de;name:hsb. Dann kann der Renderer/Router wissen, dass es 1. ein zweisprachiges Gebiet ist (kann man natürlich auch dreisprachig, viersprachig machen…) und 2. weiß er welche Namen er zu verwenden hat und kann sich aussuchen wie er es macht.

Da mit dem auf andere Tags verweisen aber wohl ein Novum hier in OSM wäre, mache ich mir keine große Hoffnung, dass dies umsetzbar ist. Aber so vom Prinzip her wäre das doch fast schon die ideale Lösung oder?

Das geht etwa in die Richtung meiner Idee… Den name-Tag würde ich aber auf keinen Fall dafür misbrauchen.

Auf Basis einer Grenze des Gebietes mit Mehrsprachigkeit (z.B. https://www.openstreetmap.org/relation/6001479#map=10/51.7338/14.2496&layers=N oder ähnlich: z.B. boundary=offical_language)

ein Zusatztag: official_language:iso=yes

iso zeigt den Sprach-ISO-Code an.

…oder in einem Feld: official_language=de;dsb (als Beispiel für Deutsch und Niedersorbisch)

Alle name-Tags innerhalb dieser Grenze werden anhand des erfassten name:iso=* benammst. (setzt natürlich voraus, daß die Namen auch erfasst sind.

Sven

Ich verstehe die Verkomplizierung der Sache nicht.

Warum nicht einfach name=Bautzen und name:hsb=Budyšin? Hier spricht m.M. nach auch das “ground truth” dagegen: die Ortsschilder sind immer zuerst Deutsch und dann unten drunter Sorbisch: http://www.t-online.de/regionales/id_77241706/domowina-will-mehr-jugendliche-ansprechen.html

Also das ist nicht “ein” Name oder so etwas was name=Bautzen/Budyšin impliziert. Und was passiert wenn ein Ortsname einen Slash enthält? Dafür gibts in der Lausitz Beispiele “Halbendorf/Spree” oder “Halbendorf/Gebirge” … https://de.wikipedia.org/wiki/Halbendorf/Spree

und für den Bindestrich ist das ja noch schlimmer.

Nebenbei: Das tagging in Südtirol halte ich für falsch, auch wenn es auf dem Boden wahr sein mag, was unlogisch ist (s.u.). Die I18N Tags sind dafür da genützt zu werden. Klar man soll nicht für die Karte oder den Router mappen aber eine künstliche Abweichung vom ‘Standard’ macht doch nur Probleme und kann nicht im Interesse der Vielsprachigkeit sein :slight_smile:

Der offizielle Name ist zweisprachig, wer da eine der Versionen als name=* auswählt, begibt sich auf brisantes Terrain.

Also das “ein” Name offiziell “zwei” Sprachen enthält macht für mich keinen Sinn. Werden dann in Israel alle 3 Sprachen in name reingemischt :)?

Und woher weiß man denn dann eigentlich welche Sprache an welcher Stelle kommt? Ob das wirklich jeder Mapper konsistent machen würde?

Siehe z.B. folgende Region: nicht nur 3 Sprachen, auch 3 Schriften: http://www.openstreetmap.org/#map=11/31.6768/-8.0255

Auch ich finde das recht unlogisch, in einer idealen Welt würde ich diese 3 Schreibweisen auch eher in einen name_official-Tag reinschreiben, aber auch wiederum grundsätzlich diesen Tag zum Rendern einer “offiziellen” Karte verwenden. Traum: Wenn die osm.org-Karte nur diesen name_official-Tag rendern würde, wäre dieser wohl ganz schnell super gepflegt.

Viele Grüße,
Kay

Straßenschilder sind definitiv zweisprachig. Bei Seen weiß ich nicht, wo deren Namen aufgeschrieben sind. Auf Verkehrsschildern werden aber auch Flüsse und Seen mit beiden Namen angegeben, wenn du das meinst.

Das ist der Status quo. Warum nicht? Weil dann auf der Karte nur der deutsche Name angezeigt wird, was weder der “ground truth” noch der Rechtslage entspricht. Denn auf den Ortsschildern haben nun einmal beide Namen zu stehen, weil beide Namen offiziell sind. In Brandenburg steht es in der von mir verlinkten Kommunalverfassung seit 2014 sogar explizit drin, dass der amtliche Name aus den Namen in beiden (!) Sprachen besteht. Dass Sorbisch drunter steht, ist einfach eine Verwaltungsvorschrift. Irgendwo muss es ja stehen. Im Übrigen gibt es – ich erwähnte es schonmal – durchaus Orte, in denen die Straßenschilder oben den sorbischen und darunter den deutschen Namen nennen. Was kommt dann als “ground truth” in den name-Tag? Nur der sorbische Name?

Weil dann auf der Karte nur der deutsche Name angezeigt wird, was weder der “ground truth” noch der Rechtslage entspricht.

Man mappt doch nicht für die Karte oder etwas doch :slight_smile: ?

Es macht alles später, wenn die Technik soweit ist, extrem komplex und wie ich via Bindestrich und slash gezeigt habe sogar unmöglich das zu trennen. Eine simple Navigation sagt dann immer alles zweisprachig an, was für Sorben und Deutsche etc einfach nur nervt und diese werden dann irgendein Navi nehmen was einfach nur deutsch ansagt.

Was kommt dann als “ground truth” in den name-Tag? Nur der sorbische Name?

Ja, genau. Das ist extrem einfach & konsistent & funktioniert für Karten und Router, falls beide ein ‘locale’ switch unterstützen. Wenn man das nicht macht wird es wie gesagt ziemlich sperrig (und unübersichtlich für Karten) für 3 Sprachen

Edit: Außerdem wer sagt das ist der Status quo? Der Status quo für Straßen etc ist das definitiv nicht. Siehe: https://graphhopper.com/maps/?point=51.161261%2C14.628296&point=51.218712%2C14.666233&locale=hsb&vehicle=car&weighting=fastest&elevation=true&layer=Sorbian%20Language

Was Straßenschilder und Ortschilder anbelangt… ja… ist so!.

Das für viele Ortsnamen bereits der sorbische Name erfasst ist, haben wir schon festgestellt. Für Straßennamen sieht das schon anders aus… Da helfen (leider :frowning: ) selbst die Amtsblätter nichts, wenn da fragmentarische Straßenlisten enthalten sind, z.B. in Zusammenhang mit Straßenreinigung oder ähnlichem.

Ich meine aber, daß es aber datentechnisch keine saubere Lösung ist, vor allem bei Namen ist, alles in einen Wert zu schreiben. Das ist für mich Sache des Renderers. Daher muß dem Renderer gesagt werden: "Hey Renderer, bename für den Bereich xy die Objekte mit einem name:xy=* und einem name:ab=* Tag in der Form, daß name:xy=* und name:ab=* übereinander stehen. name:xy=* wäre in unserem Fall der Deusche Name; ableitbar aus der DE-Grenze.

Grundsätzlich ist die OnTheGround-Regel eine exellente Sache. Man muß aber immer im Hinterkopf haben, daß OSM eine Geodatenbank ist. …und Datenbank hat für jede Sache immer ein Schlüssel-Wert-Paar. So sehe ich das auch bei Namen in unterschiedlichen Sprachen. Ein Ort hat nun mal unterschiedliche Schreibweisen des Namens je nach Sprache. Beispiele brauche ich nicht zu bringen… Nur wenn eine Region den Status einer Zweisprachigkeit hat, ist das eine weitere Geo-Information, für die es in OSM noch keine zufriedenstellende Lösung haben, auch wenn zu mindestens ein Teil der Grundinformation (der Name in den verschiedenen Sprachvarianten) vorhanden ist. Es fehlen nun Grenzen, die die zweisprachigen Gebiete definieren, mit der Angabe (ISO-Code), welches die Sprachen sind (fürs Kartenrendering) und vor allem auch der Wille der Kartenersteller/-renderer, dieses auch umzusetzen.

Sven

Probier das nochmal von Bautzen nach Crostwitz, da sieht die Sache schon anders aus. Doch, nur de im name-Tag ist Status quo.

Edit: Stimmt gar nicht, weil der Graphhopper auch da die sorbischen Namen nicht anzeigt, selbst wenn ich hsb als Locale auswähle. Und nun?

@J busissin: ich meinte nur die Karte. GraphHopper selbst liest aktuell nur das name tag: https://github.com/graphhopper/graphhopper/issues/259

Aber genau das meine ich: nur weil die meiste Software aktuell noch limitiert ist, sollten wir nicht für diese Karten- oder Routenplanersoftware die Datenbank falsch füttern, weil es der ‘korrekten’ Software dann das Leben schwer bzgl. unmöglich macht.

Ich meine aber, daß es aber datentechnisch keine saubere Lösung ist, vor allem bei Namen ist, alles in einen Wert zu schreiben. Das ist für mich Sache des Renderers. …
Man muß aber immer im Hinterkopf haben, daß OSM eine Geodatenbank ist.

Danke & Genau :slight_smile: !

Dazu eine Anmerkung: Lübben/Lubin und Calau/Kalawa sind ab sofort Teil des amtlichen Siedlungsgebietes und müssten dementsprechend ergänzt werden: http://www.rbb-online.de/politik/beitrag/2016/04/luebben-und-calau-offiziell-sorbisches-siedlungsgebiet.html

Postrow/Gruß,
j.

Ah… Sehr schön…

Ich schaue mal was das Amtsblatt Brandenburg sagt und passe die Grene Zeitnah an…

Sven

Dobry wjacor!

so… Gemeinden Lübben, Calau und Wiesengrund zur Relation https://www.openstreetmap.org/relation/6001479#map=10/51.7338/14.2496&layers=N hinzugefügt… mal sehen, welche noch hinzu kommen…Es gibt ja noch ein paar Kandidaten.

Quelle: http://service.brandenburg.de/lis/detail.php/bb3.c.279168.de und http://www.mwfk.brandenburg.de/media_fast/4055/PM%2038%20Siedlungsgebiet%20Sorben.pdf

Postrow/Gruß,

Sven, der leider aber kein sorbisch kann.

Nach allem, was ich von den Verhandlungsfortschritten mitbekomme, sollte es das erstmal gewesen sein. Die anderen Gemeinden werden sich vermutlich dagegen entscheiden.

Was anderes: Gab es nicht mal eine Möglichkeit, sich grafisch darstellen zu lassen, wo überall name:hsb-Tags vorhanden sind? Ich meine, mich daran zu erinnern.

overpass turbo wäre geeignet: Für ein kleines Gebiet kann man sich auch alles ausgeben lassen, bei grösseren Gebieten sollte man vielleicht ein bisschen filtern, z.B. nur place=* oder natural=peak.

Ich habe mal ein wenig was zusammengeschrieben…
http://overpass-turbo.eu/s/fPr (Achtung: durch die Grenze dauert die Abfrage etwas)

abgefragt werden alle place-Nodes innerhalb der Grenze des annerkannten sorbischen Siedlungsgebietes und die nicht place=locality sind. Warum die Place-Nodes um Lübben und Calau fehlen, weiß ich nicht, evt. hängt das damit zusammen, daß ich die Grenze ja erst kürzlich aktualisiert habe.
die Farben:
hellblau mit dunkelbauen Rand: vorhanden: name=, name:dsb=, name:hsb=; nicht vorhanden: name:de
rot: vorhanden: name=
; nicht vorhanden: name:dsb=, name:hsb=, name:de
schwarz: vorhanden:name=, name:dsb=; nicht vorhanden: name:hsb=, name:de
orange mit rotem Rand: name=
, name:hsb=; nicht vorhanden: name:dsb=, name:de
blau: vorhanden: name=, name:hsb=, name:dsb=, name:de
braun: vorhanden: name=
, name:dsb=*, name:de; nicht vorhanden: name:hsb

Schwarze Umgrenzung: “anerkanntes sorbisches Siedlungsgebiet”

Leider habe ich Textboxen nicht hinbekommen, die entweder nur name:dsb oder name und name:dsb anzeigen.

Sven


node[!name][!name:de][!name:hsb]
[name:dsb]
{
  symbol-size:6;
  color:green; 
  fill-color:green;
  width:1;}

node[!name:de][!name:hsb]
[name][name:dsb]
{
  symbol-size:6;
  color:red; 
  fill-color:green;
  width:1;
}

(nur) name:dsb ist (noch) vernachlässigbar, da es da nix gibt.

http://overpass-turbo.eu/s/fPA

Das ganze mal etwas übersichtlicher (im Code) um Redundanzen eingekürzt und name+name:dsb ergänzt.

edit: sehe grad, dass das schon drin war, nur andere Farbe …

Da hab ich mich missverständlich ausgedrückt… mit text:name erscheint der Wert des name-Tags permanent. Ich will aber den Wert in name:dsb permanent anzeigen. Vergleiche auch mein Extra-Beitrag: http://forum.openstreetmap.org/viewtopic.php?id=54410

Sven

In deiner Abfrage ist noch ein Fehler drin, da fehlt bei der Relation der Name.