Es hat vor Kurzem ein bisschen Diskussion in OpenStreetMap zum Thema Namen und Beschriftungen gegeben, da einige Leute den Wunsch geäußert haben, die geographisch neutrale Beschriftung im OpenStreetMap-Standardstil abzuschaffen. Eines der Dinge, die die Diskussion mal wieder gezeigt hat ist, dass die Art und Weise, wie in OpenStreetMap Namen erfasst werden, einige grundsätzliche Probleme mit sich bringt und ich möchte dies hier mal kurz erläutern.

Das System der Namens-Erfassung in OpenStreetMap basiert auf der Idee, dass die Elemente in der Datenbank jeweils einen lokalen Namen haben können, das ist der Name, welcher am häufigsten lokal für das Objekt verwendet wird. Zusätzlich gibt es dann noch eine beliebige Zahl von weiteren Namen in verschiedenen Sprachen. Der lokale Name wird im name-Tag erfasst, die übrigen Namen in name:<language>-Tags wo <language> meist der Zwei-Buchstaben-Code der Sprache des Namens ist. Es gibt daneben noch andere Namens-Attribute wie alt_name (ein anderer lokaler Name, welcher auch verwendet wird) oder old_name (ein historischer Name, welcher nicht mehr in aktiver Verwendung ist).

Der OpenStreetMap-Standardstil stellt den Inhalt des name-Tags dar in der Absicht, den lokal verwendeten Namen darzustellen. Das ist eine der charakteristischen und herausragendsten Eigenschaften der Karte und demonstriert deutlich sichtbar die Verwurzelung von OpenStreetMap in lokalem Wissen und die Wertschätzung für die geographische und kulturelle Vielfalt. Dass es natürlich eine Menge Leute gibt, die mehr Wert darauf legen, dass es noch eine weitere Karte gibt (neben den hunderten kommerziellen Karten auf OSM-Basis, die man finden kann), wo sie die Namen alle lesen können, als darauf, dass es zumindest eine einzige Karte gibt, die für jeden lokalen Mapper auf der Welt im jeweiligen lokalen Gebiet lesbar ist, ist selbstverständlich – das ist aber nicht mein Thema hier.

Das Problem damit, den angezeigten Namen aus einem einzelnen Namens-Attribut für den lokalen Namen abzuleiten, liegt darin, dass es den lokalen Mapper oft in einen Konflikt stürzt zwischen dem Wunsch, tatsächlich den lokal dominierenden Namen einzutragen und dem Wusch, eine bestimmte Beschriftung in der Karte sehen zu wollen. Dies kann beeinflusst werden zum Beispiel von dem Wunsch nach einer Beschriftung in einheitlicher Form oder dem Ziel, die Karte besser für Fremde lesbar zu machen. Als Ergebnis dieses Konfliktes enthält das name-Tag oft zusammengesetzte Zeichenketten aus mehreren Namen in verschiedenen Sprachen, insbesondere in Regionen, wo lokal mehrere Sprachen verwendet werden und es eventuell gar keinen einzelnen lokal dominierenden Namen gibt.

Die Lösung für dieses Problem besteht darin, die Illusion aufzugeben, dass es immer einen einzelnen lokalen Namen gibt, der überprüfbar erfasst werden kann. Stattdessen könnte man einfach wie jetzt auch schon die Namen in den verschiedenen Sprachen erfassen und daneben eine Formatierungs-Formel (format string), welche die lokal übliche Form der Namens-Darstellung wiedergibt. Der Schlüssel ist hier die mehrsprachige Erfassung der Namen von der Information über die lokal übliche Namens-Darstellung zu trennen.

Die Formatierungs-Formel müsste man dabei meist gar nicht für jedes einzelne Objekt angeben, denn meist werden ja die verschiedenen Namen in einem Gebiet alle gleich dargestellt. Die einzelnen Elemente würden also zweckmäßigerweise ihre Formatierungs-Formel von der administrativen Einheit, in der sie sich befinden, erben, es sei denn, es ist eine abweichende individuelle Formel erfasst.

Im Fall von Deutschland würde zum Beispiel die Grenzrelation für admin_level 2 (51477) so etwas wie language_format=$de erhalten – und es gäbe im Wesentlichen keine Notwendigkeit, in Deutschland weitere Objekte mit einer Formatierungs-Formel zu versehen – mit Ausnahme vielleicht einiger kleinerer Gebiete mit abweichender Sprache und einigen einzelnen Objekten, die ausschließlich in anderen Sprachen einen Namen haben. Die Schweiz (51701) bekäme language_format=$de/$fr/$it/$rm und für die verschiedenen Kantone gäbe es unterschiedliche Formeln je nach lokal verwendeten Sprachen.

Der Schlüssel-Wert und die Form der Formatierungs-Formel sind hierbei lediglich Beispiele, um die grundsätzliche Idee zu illustrieren – man könnte diese auch anders wählen.

Ich denke, dass dieses Konzept eine Reihe offensichtlicher Vorteile hätte:

• Die Regeln für die Attribute der Namen in den einzelnen Sprachen sind deutlich klarer und besser definiert, so dass es weniger Raum für Willkür gibt und folglich die Daten verlässlicher für den Datennutzer werden, als wenn man das name-Tag interpretiert.
• Der Wunsch lokaler Mapper nach einer bestimmten Darstellungsform in der Karte würde sich ausschließlich in der Formatierungs-Formel artikulieren und würde nicht auf die eigentlichen Namens-Daten abfärben.
• Die Formatierungs-Formel bietet dem Daten-Nutzer eine deutlich größere Flexibilität – man kann sie komplett ignorieren, modifizieren oder durch eine eigene und global einheitliche Formel oder eine komplexere Funktion mit Fallbacks oder Transliteration ersetzen. Oder der Datennutzer kann sich entscheiden, entweder die individuellen Formatierungs-Formeln zu verwenden oder auschließlich jene, welche von den administrativen Einheiten geerbt wurden.
• Das Problem mit den verschiedenen Schrift-Varianten für die selben Unicode-Zeichen in verschiedenen Sprachen (zum Beispiel bei Chinesisch/Japanisch/Koreanisch) würde ganz nebenbei hierdurch gelöst.
• Die Namen in den einzelnen Sprachen als Datenquelle für die Beschriftung zu verwenden anstatt eines separat erfassten Beschriftungs-Attributes hat den Vorteil, für diese Namen eine Qualitätskontrolle über die Karte zu ermöglichen – was letztendlich zu weniger Fehlern und Inkonsistenzen in den Namens-Daten führen würde.
• Man hätte eine einfache Fallback-Lösung für den Übergang: Wenn es entweder keine gültige Formatierungs-Formel gibt oder irgendeine der Sprachen in der Formel nicht verfügbar ist, könnte man auf das klassische name-Tag zurückgreifen.

Aber ich möchte auch die wichtigsten Nachteile dieses Ansatzes erwähnen:

• Die Datennutzer erhalten keine bereits vom Mapper quasi handgemalte Beschriftung, die sie direkt verwenden können, sondern sie müssen stärker strukturierte Informationen in Form der Namen in verschiedenen Sprachen und der Formatierungs-Formel auswerten.
• Damit die einzelnen Elemente ihre Formatierungs-Formel von den administrativen Einheiten erben können, muss man die räumlichen Beziehungen ermitteln und das ist zu aufwändig, um es jeweils bei Bedarf ad hoc zu machen. Man bräuchte folglich Unterstützung dafür bei den Daten-Konvertierungs-Werkzeugen, insbesondere denen für die Kartendarstellung (wie osm2pgsql, Imposm). Dies ist nicht trivial, insbesondere wenn man berücksichtigen möchte, dass eine Änderung der Formatierungs-Formel einer administrativen Einheit alle Elemente mit Namen innerhalb dieser Einheit potentiell beeinflusst.

Ein anderer möglicher Kritikpunkt wäre, dass die Formatierungs-Formel nicht überprüfbar ist. Aber es sollte recht offensichtlich sein, dass wenn das derzeitige name-Tag diese Anforderung erfüllt, dieses auch für die Formatierungs-Formel gilt, welche ja nur das selbe in abstrakter Form beschreibt.