Zweisprachige Gebiete

Also ich kann Julians Meinung nachvollziehen und meine, man sollte einen datentechnisch sauberen Weg finden, in Fällen wie diesem, eine zweisprachige Ortsbezeichnung hinzubekommen.

Generell ist es in Hinblick auf verschiedene Kartenanwendungen aber schwierig… Die Daten sind da, aber die Entwickler des Rendering-Stils entscheiden, welche Objekte wie benamt werden.

So werden auf dem deutschen Stil http://www.openstreetmap.de/karte.html in Polen z.B. deutsche und darunter amtliche Polnische Namen gerendert. So in der Art würde ich mir das auch für die sorbischen Namen wünschen. Villeicht solltet ihr mit den Entwicklern der deutschen Karte mal dahingehend Kontakt aufnehmen.

Das aber auf allen Karten versuchen zu wollen, halte ich für ein hoffnungsloses Unterfangen.

@stoecker: vielleicht ließe sich diese Variante der Zweisprachigkeit, in deine Karte einbauen? http://www.openstreetmap.de/germanstyle.html

Sven

Dieser Stil würde Julian sicher nicht gefallen. Der ist so sehr eingedeutscht, dass er aus (name=“Cottbus/Chóśebuz” + name:de=“Cottbus”) nur das “Cottbus” zur Anzeige rausucht. Grund dafür waren die unschönen Dopplungen, die Tordanik in #7 erwähnt hat.

Grüße, Max

Das brächte aber wieder das Problem mit sich, dass wir den Bereich, in dem auf die Art und Weise gerendert wird, abgrenzen müssten. Sonst haben wir dann auch bei Leipzig, Dresden und München die sorbischen Namen drunterstehen, was sogar ich für ein wenig übertrieben hielte.

Stoeckers verlinkte Karte ist als sorbisch einsprachige Ausgabe gedacht gewesen, die können wir also erstmal aus der Betrachtung rausnehmen. Das funktioniert ja.

Ich will aber nochmal folgendes festhalten:

  1. Der name-Tag ist sprachlich undefiniert. Nach meinem Verständnis soll er den amtlichen Namen des Ortes beinhalten. Im OSM-Wiki heißt es: “For disputed areas, please use the name as displayed on e.g. street signs for the name tag.” Das wären in unserem Fall beide.

  2. Die Orte im offiziellen sorbischen Siedlungsgebiet haben zwei amtliche Namen, jeweils einen deutschen und einen sorbischen. Welche Orte das in Sachsen betrifft, steht sogar im entsprechenden Gesetz: http://domizna.org/fileadmin/domizna/upload/software/serbscinu_nalozowac/1999_saechs_sorbg.pdf In Brandenburg ist die Situation sogar so, dass laut Kommunalverfassung des Landes § 9, Absatz 4, die Orte im Sorbischen Siedlungsgebiet “einen zweisprachigen Namen in deutscher und niedersorbischer Sprache” tragen. (http://www.swg-brandenburg.de/index.php/psawniske-teksty-rechtstexte/238-komunalna-wustawka-kommunalverfassung) Hier gibt es also nicht zwei offizielle Namen, sondern einen zweisprachigen, was im name-Tag berücksichtigt werden müsste.

  3. Bisher enthält der name-Tag bei uns nur einen dieser zwei amtlichen Namen, nämlich den deutschen.

  4. Es gibt vergleichbare Gegenden in Europa, wo man offenbar anders verfährt. Kärnten (sehr gut vergleichbare Situation) und Südtirol sind oben schon erwähnt. Ein anderes Beispiel ist das Slowenische Küstenland (http://www.openstreetmap.org/#map=12/45.5357/13.6433), wo Italienisch als regionale Minderheitensprache anerkannt ist. Vergleichbar ist auch die Situation auf Sardinien.

Ich würde schon gerne einen vernünftigen Grund dafür wissen, warum wir in der Lausitzer name-Tags auf je einen von zwei Namen verzichten sollten? Dass die eine Sprache subjektiv “wichtiger” sein soll als die andere, kann man als Begründung nicht gelten lassen. Dann müsste der name-Tag für Crostwitz oder Ralbitz der sorbische Name sein, weil das dort objektiv die Mehrheitssprache ist.

Die amtliche Gültigkeit der Zweisprachigkeit lässt sich für Brandenburg an Grenzen festmachen. Das hatte ich oben schon geschrieben. Das Problem ist aber, daß im derzeitigen Stand der Grenzerfassung für die Niederlausitz sich keine Grenze ermitteln läßt, da z.B. für Forst die Ortsteilgrenzen fehlen. Analog ist es bei 2 oder 3 weiteren Gemeinden so.
Gäbe es diese Ortsteilgrenzen, wäre eine Grenze längst drin.

Andererseits werden z.B. auch z.B. im Brandenburg-Viewer die Ortsnamen nicht immer gerendert:
http://bb-viewer.geobasis-bb.de/?zoom=4&lat=5743523.23779&lon=443039.31477&layers=B000FFFFF0000FFFFTFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFTTTF

Zu den Namensdopplungen… Aus datentechnischer Sicht ist es unschön, wenn ein Feld mit zwei verschiedenen Werten gefüllt ist. Gerade Namen sind da ein schönes Beispiel. Wenn man z.B. eine Namensauswertung in Hinblick auf die Herkunft des Namens machen will stößt man auf grundsätzliche Probleme, wenn zwei verschiedene Werte (in dem Fall Namen unterschiedlicher Sprachherkunft) vorfindet. Einen für solche Auswertung verwendbaren Namen findet man z.B. am ehesten im sorbischen Namen, der Deutsche interessiert da meist nicht: mal ein paar deusche Namen als Stichworte: Jessern, Dubrau, Briesen, Burg…

Da ich auch mit offiziellen digitalen Daten des Landes Brandenburg dienstlich zu tun habe, kann ich dir versichern, daß in deren Datenbanken die sorbischen Namen auch in getrennten Feldern stehen. Die Zusammenführung beider amtlichen Namen passiert erst beim Kartenrendering durch Darstellungsregeln.

Sven

Das halte ich für falsch. Der name-Tag ist als “the common default name” definiert. Also handelt es sich eben nicht um den amtlichen Namen, sondern den gängigen. (Auch die Einzahl beachten!) Von daher schießen deine Erklärungen über die amtlichen Vorgaben am Ziel vorbei.

Bei den sorbischen Siedlungsgebieten handelt nicht um den typischen Fall von “disputed areas”. Dabei geht es um Fälle, wo z.B. mehrere Länder den Anspruch auf ein Gebiet erheben. In dem Fall wird auf die örtliche Beschilderung als Indiz der tatsächlichen Herrschaft über das Gebiet zurückgegriffen.

Was du auch weggelassen hast, ist der nächste Satz: “Put all alternatives into either localized name tags […] or the variants”. Das ist für mich schon ein starker Hinweis, das eben nur ein Name in name soll, und der Rest in andere Tags.

Hallo,

die Versuche von Jochen Topf bzgl. mehrsprachiger Karten, bei denen ein User auswählen, welche Sprache er sehen möchte, kennt ihr? Das Projekt wurde von Wikimedia Deutschland finanziert, wurde aber (vermutlich mangels weiterer Finanzierung) nicht weitergeführt.

http://blog.openstreetmap.de/blog/2012/03/wikipedia-projekt-multilingual-maps/
https://wiki.openstreetmap.org/wiki/Multilingual_maps_Wikipedia_project
http://mlm.jochentopf.com/
https://lists.openstreetmap.org/pipermail/talk-de/2012-November/099903.html

Die Zukunft liegt aber nicht in der Welt der Rasterkacheln, auch wenn dieses System mittlerweile ausgereift ist. Stattdessen heißt die Zukunft wohl eher Vektortiles (oder eine Mischung aus beidem). Dort erhält der Client Vektordaten (ggf. generalisiert und meistens thematisch gefiltert). Das Rendering erfolgt im Browser, so kann man dann auch einer großen Anzahl an Clients für wenig Geld (d.h. mit weniger Servern) zig verschiedene Dienste anbieten. Als Vektorrenderer fallen mir gerade Kothic.js (von der OpenRailwayMap früher und bald wieder produktiv eingesetzt [1]) und Mapbox GL ein. Bei letzterem weiß ich aber nicht, ob das auch nutzbar ist. Zu Kothic.js sei angemerkt, dass die Daten als unkomprimiertes, ungeneralisiertes GeoJSON über die Leitung gehen und daher niedrige Zoomstufen sehr lange zum Download brauchen. Das Rendering selbst geht recht fix.

Viele Grüße

Michael

[1] Vektortilerendering-Demo, produktives Rastertile-Rendering

Ja, das kenne ich. Aber auch da lässt man sich ja am Ende eine einsprachige Karte ausgeben. Die Möglichkeit, mir eine einsprachig deutsche oder einsprachig sorbische Karte ausgeben zu lassen, habe ich ja so auch schon.

Was Brandenburg angeht (Sven): Die Regelung in der Kommunalverfassung gibt es so erst seit letztem Jahr. Seitdem sollen die Ortsnamen tatsächlich zweisprachig geführt werden, so dass nach dieser Regelung “Cottbus/Chóśebuz” der amtliche Name der Stadt ist.

Die MLM kann auch zweisprachig: “You can also add a second language in parentheses by writing something like “fr|de” or “fr|_”.”

Ok, dann habe ich das falsch interpretiert. Was bedeutet das für folgende Fälle (es geht um die Straßennamen):

https://commons.wikimedia.org/wiki/File:Rosenthal_Stra%C3%9Fenschilder.JPG
https://commons.wikimedia.org/wiki/File:Serbske_Pazlicy_-_Njebjel%C4%8Danska.JPG

Was ist da der “common default name”?

Ich will dieses Thema noch einmal aufgreifen. Ich bin seit einiger Zeit wieder mal hier in der Lausiitz unterwegs und habe festgetsellt, dass verschiedene Navigatoren den (deutsch sorbischen Doppel-)Namen ansagen, die Namen aber sehr lustig klingen. Das ist sicher nicht im Interesse unserer sorbisch-sprachigen OSM-ler, denn damit wird die Sprache eher entstellt und lächerlich gemacht als gefördert.

Außerdem gebe ich zu bedenken, dass zum Beispiel die Stadt Bautzen nach dem amtlichen Gemeindeverzeichnis Sachsens (https://www.lds.sachsen.de/index.asp?art_param=155&NR_KRS=14625) “Bautzen” heißt und den Präfix “Große Kreisstadt” trägt. Auch wenn die Stadt sich per Satzung verpflichtet, die sorbische Sprache und Kultur zu fördern (http://www.bautzen.de/dokumente/sorbischeSatzung.pdf) und den sorbischen Namen parallel zu tragen, ist “(Große Kreisstadt) Bautzen” der offizielle Name. Deshalb sollte “name=Bautzen” ausreichend sein. Dies trifft ausnahmslos auf alle Ortsteile und Orte der näheren Umgebung zu.

Anmerkung: Ich kenne auch das Wiki, kann mich aber (unter Verweis auf das tatsächlich amtliche Gemeindeverzeichnis) damit nicht anfreunden. Denn m.E. ist amtlich richtig.

Auch in anderen Regionen Deutschlands werden im übrigen Minderheiten mit ihren sprachlichen Besonderheiten gefördert (zb. das Friesische), die Orte tragen Namen parallel. Dort gibt es aber nicht solche entstellenden Kuriositäten.

Beste Grüße
Uwe

edit: Rechtschreibung

Diese Doppelnamen sind also eher für die visuelle Kartendarstellung geeignet. Navigatoren werden davon ausgehen, einen deutschsprachigen Namen auszulesen. Weiß jemand, wie die Sprachausgabe genau funktioniert?

Nach wie vor denke ich, dass Mehrsprachigkeit in OSM eher über Wikidata gelöst werden kann. Dort können nicht nur Namen in verschiedenen Sprachen strukturiert eingepflegt und ausgelesen werden, sondern auch deren Aussprache gemäß dem Internationalen Phonetischen Alphabet.

Bitte mal hier bis zur Rubrik “IPA transcription” scrollen: https://www.wikidata.org/wiki/Q64

Scheint so, also: Mapping für den Renderer (in diesem Falle OSM.org).

Da sollten doch besser OSM.org oder openstreetmap.de anhand einer Grenze des sorbischsprachigen Gebietes wissen: Hier muss ich auch name:hsb parallel anzeigen. Sonst wird es Murks. Denn Openstreemap.de zeigt nur (richtig, weil in name:de) “Bautzen” und das ist ja bestimmt auch nicht im Interesse des Themenerstellers und der “Förderung der sorbischen Sprache und Kultur”.

Gruß Uwe

Für Ansagen wird genau der Text verwendet, welcher in der Karte am jeweiligen Element hinterlegt ist. Der landestypische(!) Name muss also schon bei der Kartenerstellung ausgewählt sein. (Vielleicht ein klareres Beispiel: Die “Topo Deutschland” navigiert mit den deutschen Namen, obwohl der Tourist vielleicht Englisch am Navi eingestellt hat, was sich nur auf’s Menü und die Anweisungen “left turn to Schulstraße” auswirken darf.)

In Osmand kann man die bevorzugte Sprache für a) Anwendung und b) Kartendarstellung separat voneinander einstellen. Natürlich könnten anderen Systeme noch flexibler sein und bei englischer Oberfläche einen deutschen Namen französisch in die Karte setzen und in der Abbiegeanweisung italienisch aussprechen, sofern diese Versionen alle im Kartenmaterial vorliegen.

Solche Diskussionen ergeben nur Sinn, wenn man dazusagt, welche Anwendung genau man meint. „Navigatoren werden davon ausgehen“ ist zu unscharf, die ticken zu unterschiedlich.

–ks

Ich habe die Frage maßgeblich deshalb noch einmal aufgeworfen, weil amtlich eben nicht der Doppelname richtig ist, auch wenn er am Ortseingangsschild so steht. Alles andere (zum Beispiel Kuriositäten bei der Ansage) sind dann (nicht nur bei Ortsnamen, sondern auch bei Straßennamen) Folgeerscheinungen, die bei einer klaren richtigen Regelung (angelehnt an die amtlich richtigen Bezeichnungen) vermeidbar wären.

Am allgemeinen glaube ich auch, dass sorbischsprachige Anwender der OSM.org und auch von Navigatoren (zb. OSMAND) durchaus mit den deutschen Bezeichnungen der Straßen- und Ortsnamen etwas anzufanngen wissen, sonst wären sie ja in der Landeshauptstadt Dresden auf einen Übersetzer angewiesen.

Gruß Uwe

Ja, denn es sind zwei Namen.

Ja. Generell halte ich mehr von der strukturierten Variante, also name:LC=* Uwe hat dafür ein Argument mehr geliefert.

Danke für den Einblick. Kreuzschnabel hat ja schon davor gewarnt, nicht zu sehr zu verallgemeinern. Prinzipiell lassen sich doch auch mehrsprachige digitale(!) Karten realisieren?

Edit: neuere Diskussion: http://forum.openstreetmap.org/viewtopic.php?id=54294

Namen haben viel Symbolkraft. Das ist schön richtig.

Das ändert aber nichts an dem grundsätzlichen Problem das Landkarten nur dann Sinn machen, wenn sie Informationen komprimieren. Und daher muss man sich logischerweise überlegen, was weggelassen wird.

Der generelle Vorteil von Karten ist die grafisch kompakte Darstellung. Symboler wie picknicktisch haben einen unheimlich Höhe Informationsdichte verglichen mit Text.

Namen haben die unangenehme Eigenschaft dass sie sich nicht in die Kartenspezifische Stärcke einbetten lassen, sondern mit der Kulturtechnik Text dargestellt werden müssen, was viel Platz wegnimmt. Wir fahren ja nicht von blauweisser Raute nach rotem Rechteck sondern von München nach Hamburg.

Daher meine klare Meinung: Namen Und deren rendering sollte immer so einfach wie nötig sein.

Also etwas salopp formuliert beteenden die meinten Karten eine eigene Kartensprache Und Text ist darin ein notwendiger Fremdkörper. Und es ist diese Kartensprache die wir entwickeln Und pflegen sollte.

Kein Problem aufgrund name:de, name:en, name:cz etc…
Seit heute weiß ich, dass OSMAND flexibel ist und eine “Jederzeit-Sprachauswahl” auch beim Kartenmaterial ermöglicht. Allerdings finde ich persönlich es nicht hilfreich für den “inneren Abgleich”, in nichtdeutschsprachigen Ländern - abweichend von der Beschilderung - deutsche Namen angesagt zu bekommen.

Die Diskussion zielt auf das Endprodukt Karte, aber setzt schon weiter vorne bei der Datenbank an. Daher der Streit um name=*

Wahrscheinlich, sofern name:LC=* getaggt ist. Hast Du die Sprachausgabe mal getestet?