Imagico.de

blog

Namen und Beschriftungen in OpenStreetMap

| 1 Kommentar

Deutscher Text auf Grundlage einer automatischen Übersetzung mittels deepl.

Vor mehr als fünf Jahren habe ich hier einen Blogbeitrag über das Problem der Namenserfassung und der mehrsprachigen Namen in OpenStreetMap geschrieben. Ich möchte jetzt ein Update der Situation aus meiner Sicht geben und ein wenig darüber nachdenken, was sich seither geändert hat und was nicht. Außerdem soll dies ein wenig als Einleitung für einen folgenden Blogbeitrag dienen, den ich über Änderungen bei der Darstellung von Beschriftungen in meinem Kartenstil plane.

Was ich vor fünf Jahren erklärt habe, ist im Wesentlichen, dass die primäre Art und Weise, mit der Mapper in OpenStreetMap Namen aufzeichnen, das name-Tag, eine zentrale Rolle bei der Etablierung der Idee gespielt hat, dass OpenStreetMap das lokale Wissen seiner Mitwirkenden aufzeichnet, weil es nach allgemeinem Konsens explizit dazu gedacht ist, den lokal verwendeten Namen von geografischen Objekten aufzuzeichnen. Da jeder Mapper überall auf der Welt dies auf genau die gleiche Weise tut und diesen lokalen Namen direkt auf der Karte so sieht, wie er erfasst wurde, repräsentiert diese Praxis gut die Idee der gemeinsamen Kartierung des Planeten in all seiner Vielfalt.

Andererseits – und das habe ich auch schon vor fünf Jahren erwähnt – ist diese Praxis leider mit verschiedenen Problemen verbunden:

  • Sie beruht auf der Illusion, dass es immer nur einen einzigen lokalen Namen gibt.
  • Die Aufzeichnung des lokalen Namens ohne Informationen über die Sprache dieses Namens führt in einigen Fällen zu ernsthaften Problemen (insbesondere bei dem, was gemeinhin als the Han unification problem bekannt ist).
  • Was die Mapper als Beschriftung der Elemente in der Karte sehen wollen, ist sehr oft nicht der lokal verwendete Name.

Die damals von mir vorgeschlagene Lösung für die Beschriftung sowie

verschiedene andere Versuche, Ideen für die Beschriftung zur Lösung der ersten beiden Probleme vorzuschlagen, fanden keine breitere Unterstützung. Sowohl Mapper als auch Datennutzer schienen mit dem Status quo weitgehend zufrieden zu sein.

Die Situation heute

Kurz und bündig: Die heutige Situation ist im Wesentlichen unverändert. Die bereits 2017 sichtbaren Probleme haben sich jedoch verschärft und es ist mittlerweile recht deutlich sichtbar, dass die derzeitige Praxis nicht nachhaltig ist. Wenn ich versuche, die Verwendung des name-Tags heute zu kategorisieren, komme ich zu folgendem Ergebnis.

Die überwiegende Mehrheit der name-Tags enthält einen einzelnen Namen. In den meisten Fällen handelt es sich dabei um den lokal verwendeten Namen. Es gibt jedoch auch einen beträchtlichen Prozentsatz von Fällen, in denen ortsfremde Kartierer Namen, die sie verwenden oder mit denen sie vertraut sind, in das name-Tag eintragen, obwohl es sich offensichtlich nicht um den lokal gebräuchlichen Namen handelt (z. B. weil es sich um eine Sprache handelt, die lokal nicht weit verbreitet ist). In anderen Fällen verwenden lokale Mapper einen per Schild ausgewiesenen oder offiziellen Namen (d. h. einen Namen, der von einer Autorität, entweder einer offiziellen Stelle oder dem Eigentümer des betreffenden Merkmals, verwendet wird) und nicht den Namen, der vor Ort in der praktischen Kommunikation verwendet wird.

Alle diese Varianten der Aufnahme eines einzelnen Namens, der nicht der lokal verwendete Name ist, in das name-Tag, sind weitgehend durch die Tatsache motiviert, dass viele Datenbenutzer das name-Tag entweder nur direkt als Label-Tag interpretieren oder ihm bei der Auswahl zur Beschriftung Vorrang vor anderen Tags mit Namen geben. Dies ist ein Anreiz für die Kartierer, den Namen zu erfassen, den sie auf der Karte sehen wollen – was je nach dem einzelnen Mapper und den lokalen kulturellen Konventionen bei der Kartengestaltung unterschiedliche Dinge bedeuten kann.

Der zweit-häufigste Anwendungsfall für das name-Tag nach der Aufnahme eines einzelnen Namens ist die Aufnahme von etwas, das überhaupt kein Name ist. Diese Praxis wird teilweise durch denselben Mechanismus angetrieben, den ich bereits erörtert habe. Der andere Grund dafür ist, dass das Konzept von Namen (oder genauer: Eigennamen) eine sehr abstrakte Angelegenheit ist, mit der viele Mapper Schwierigkeiten haben. Ein beträchtlicher Prozentsatz der Verwendungen des name-Tags für Dinge, die keine Eigennamen sind, sind Fälle, in denen Mapper eine Beschriftung aus der realen Welt aufzeichnen, die keinen Eigennamen für das Feature darstellt. Oft handelt es sich dabei um eine Marke (wie bei Geschäften usw.), den Namen einer Person, die ein Feature betreibt (was normalerweise mit operator gekennzeichnet wird), Adressbestandteile oder eine Klassifizierung (man denke an einen Spielplatz, an dem ein Schild mit Nutzungsbeschränkungen angebracht ist: Spielplatz: Nutzung nur für Kinder unter 14 Jahren erlaubt – und der Mapper interpretiert den Spielplatz als den Namen des Objekts).

Mehrere Namen

Der dritt-häufigste Anwendungsfall für das name-Tag – und hier sind wir bei einem einstelligen Prozentsatz angelangt, obwohl dieser bei bestimmten Objekt-Typen und in einigen Regionen viel größer ist – ist die Aufnahme von mehreren Namen in das name-Tag. Dies ist ebenfalls weitgehend dadurch motiviert, dass die Datennutzer das name-Tag als Beschriftung anzeigen und die Mapper in einigen Fällen die Anzeige mehrerer Namen in der Karte als die wünschenswerteste Form der Beschriftung ansehen.

Es gibt zwei grundlegend verschiedene Varianten der Aufnahme mehrerer Namen in das name-Tag. Die eine (und weitaus verbreitete von beiden) ist die Aufnahme von Namen in verschiedenen Sprachen. Wenn es nicht nur eine einzige lokal verwendete Sprache gibt, sondern mehrere, hat ein Objekt in der Regel verschiedene Namen in diesen verschiedenen Sprachen und dementsprechend keinen eindeutigen lokal verwendeten Namen. Die andere (viel seltenere) Variante ist, wenn es in der einzigen lokal verwendeten Sprache mehr als einen lokal verwendeten Namen gibt und es nicht möglich ist, nachprüfbar festzustellen, welcher der lokal weiter verbreitete Name ist.

Ich möchte hinzufügen, dass es für beide Varianten auch den recht häufigen Fall gibt, dass ein einziger lokal am weitesten verbreiteter Name bestimmt werden kann, die Mapper dies aber – aus sozialen oder politischen Gründen – nicht angeben wollen und es vorziehen, mehrere Namen so zu erfassen, als ob sie lokal gleich weit verbreitet wären, auch wenn sie es nicht sind.

In letzter Zeit gab es in der OSM-Community ein erneutes Interesse am Thema der Erfassung mehrerer Namen im name-Tag, aber die meisten Diskussionen drehten sich um die eher oberflächliche und unbedeutende Frage, wie man die verschiedenen Namen in diesem Fall trennen kann. Das ist in etwa so, als ob man plant, ein paar Risse in einer Wand zu übermalen und darüber diskutiert, welche Farbe man dabei verwenden sollte.

In der Praxis sind die gebräuchlichsten Trennzeichen für mehrsprachige zusammengesetzte Namen ' / ' und ' - ' (d.h. Schrägstrich oder Bindestrich/Minus mit Leerzeichen drumherum) und – bei zusammengesetzten Namen, bei denen die Komponenten durch verschiedene Schriften unterschieden werden – ist es auch üblich, überhaupt kein Trennzeichen zu verwenden (nur ein Leerzeichen, das auch zwischen verschiedenen Wörtern der einzelnen Namen verwendet wird). Das Semikolon (;) wird in gewissem Umfang verwendet, allerdings meist in nicht mehrsprachigen Situationen, insbesondere in Fällen, in denen sich die verschiedenen Namen auf unterschiedliche Objekte der realen Welt beziehen.

Trotz all dieser Ungereimtheiten und widersprüchlichen Praktiken gibt es einen breiten Konsens über mehrsprachige Namen: Wenn Namen mehrerer Sprachen in zusammengesetzten name-Tags enthalten sind, sollte jede der Komponenten auch separat in dem jeweiligen name:<lang>-Tag erfasst werden. Diese Regel wird zwar nicht durchgängig befolgt, aber es besteht eindeutig ein breiter Konsens darüber, dass dies wünschenswert ist.

Das Dilemma bei der Kartendarstellung

Der Kern des Problems auf der sozialen Ebene (und der Grund, warum in diesem Bereich in den letzten fünf Jahren nichts Substanzielles passiert ist) liegt darin, dass die Illusion des name-Tags, das den einzigen lokal verwendeten Namen aufzeichnet, für die Datennutzer recht bequem ist, weil sie damit ihre Karte auf sehr einfache Weise beschriften können, und gleichzeitig ist die Möglichkeit, die Beschriftungen in Karten direkt zu kontrollieren, etwas, das die Mapper zu schätzen gelernt haben, und viele Mapper haben nicht das Vertrauen

  • in die Fähigkeit und Bereitschaft der Datennutzer, klarer strukturierte Informationen so zu interpretieren, dass sie zu guten Karten führen.
  • in ihre Mapper-Kollegen, damit sie die sauberer strukturierten Informationen zu den Namen gewissenhaft aufzeichnen (und die uneinheitliche Verwendung des name-Tags bestätigt diesen Verdacht direkt).

Was ich (und andere) in der Vergangenheit versucht haben, ist, Ideen zu präsentieren, wie das Problem von der Kartierungsseite her angegangen werden kann. Aber weder die Datennutzer noch die Mapper zeigten sich sehr interessiert daran, den Status quo zu ändern.

Außerdem sind die einflussreichsten Kreise in der OSM-Gemeinschaft – sowohl auf der Seite der Mapper als auch auf der Seite der Datennutzer – aus Westeuropa und Nordamerika und in erster Linie an Sprachen mit lateinischer Schrift interessiert, so dass sie nur wenig Interesse an der Lösung der Probleme haben, die der Mangel an Informationen über die Sprache(n) des name-Tags verursacht.

Das Dilemma für Kartengestalter, insbesondere in OSM-Carto, besteht darin, dass mittlerweile völlig klar ist, dass die primitive direkte Verwendung des name-Tags als Beschriftung für viele Features in OpenStreetMap einen großen Anteil an der oben skizzierten schlechten Situation hat. Mit anderen Worten: Wir als Kartendesigner sind Teil des Problems und es wäre daher in gewisser Weise klug, damit aufzuhören. Da wir aber – aus den oben und im Blogpost von 2017 genannten Gründen – weiterhin daran interessiert sind, überall auf der Welt lokale Namen in der jeweiligen Landessprache darzustellen und es keine andere etablierte Möglichkeit gibt, diese Information in OSM zu erfassen, haben wir keine andere Möglichkeit, als das name-Tag anzuzeigen. Und wir wollen (aus sehr guten Gründen, die ich kürzlich noch einmal erläutert habe) die Mapper nicht aktiv dazu bringen, ihre Kartierungspraxis in einer Weise zu ändern, die wir für wünschenswert halten.

Ein Ansatz, um diese Pattsituation zwischen Mappern und Datennutzern zu überwinden, könnte darin bestehen, ein funktionierendes Konzept zu präsentieren, das sowohl die Vorteile einer tatsächlichen Lösung des Problems aufzeigt (anstatt nur die Risse ein wenig zu übertünschen – siehe oben) als auch, wie ein reibungsloser Übergang vom Status quo zu einer solchen Lösung aussehen könnte. Und vor allem – um zu zeigen, dass ein solcher Weg es nicht erfordert, dass die Mapper die Kontrolle über die Kartierungspraxis an eine kleine Elite von technischen Gatekeepern abgeben, sondern dass er es ihnen erlaubt, weiterhin selbstbestimmte Entscheidungen zu treffen, und der die wenigen beschriebenen Punkte, wo Mapper tatsächlich einen Konsens darüber haben, wie Dinge kartiert werden sollten, respektiert und darauf aufbaut. Darum wird es im nächsten Blogbeitrag gehen.

Ein Kommentar

  1. Erst mal danke für den Beitrag, der mal wieder meine Sicht erweitert hat und zu Ideen anregte.

    Zuerst einige Ergänzungen, hoffentlich nicht zu off topic:

    * Man kann auch bei Personen-Namen viele Fehler begehen:
    https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/
    (Darunter hab ich schon selbst gelitten, weil mein Name in Katakana-Transkription zu lang ist für das Namen-Eingabefeld bei der Fluggesellschaft ANA. 🙂 )

    * Etwas unterhalb der Ebene Ihres Artikels: Die Mapper wollen ihre Arbeit in der Karte sehen (anders, als immer wieder behauptet, sind die aus unserer DB erzeugten Karten und die damit betriebenen Dienste unser eigentliches Produkt). Das Name-Element wird oft missbraucht, um eine Anzeige in der Arte zu bewirken, das sowohl Ihnen als auch den Suchmaschinen die Arbeit erschwert.

    Ich denke, wir sollten ein Element unterhalb der Ebene „Name“ einführen, z.b. „Label“, das in kleinerer Schrift und mit niedriger Priorität gerendert wird und aus der Suche ausgeschlossen. Das würde „Namen“ wie „Sandkasten“, „Schaukel“, „Löwen“, „Fischteich“ usw. vermeiden und Ihnen wie auch den Suchmaschinen die Arbeit erleichtern.

    * Das fehlende Vertrauen ist oft gerechtfertigt. Wenn z. B. bessere Datenerfassung (Gebäude als Fläche wie auch das Restaurant an die Fläche) dazu führt, dass das Label verschwindet, weil es nur gezeichnet wird, wenn es in die Fläche passt.

    Oder wenn man dafür geschimpft wird, unscharfe Regionen (Schwarzwald) trotz der Unschärfe als Fläche zu zeichnen, was dem Kartendesigner viele Gestaltungsmöglichkeiten für die Beschriftung erlaubt, und stattdessen ein Label-Node empfohlen wird, das der Ersteller an eine Stelle platziert, auf der auf seiner Lieblingskarte Platz dafür ist, was den Kartendesigner aber aller Gestaltungsmöglichkeiten beraubt und möglicherweise zum Verschwinden der Beschriftung führt.

    Ich möchte aber auch ein paar Gedanken zu einer Lösung anbieten. Für den Hintergrund muss ich kurz ausholen: Ich bin selbst auf das „name=”-Problem gestoßen, als ich die Alpenvereinseinteilung der Ostalpen erfasst habe, in denen Sie unterschiedliche Sprache und auch mehrsprachige Gebiete finden. Ich hab natürlich alle Gebiete mit “name:{lc}”versehen für die in den Ostalpen gesprochenen Sprachen und zusätzlich mit „name:en“. Das „name=“ war klar für die (mehr oder weniger) einsprachigen Gebiete. Aber eben nicht für die Mehrsprachigen. Zum Glück hatte ich Kontakt mit jemanden aus einem der extrem mehrsprachigen Gebiete, und dessen Antwort war: trag ein, was Dir am besten passt, da ist hier keiner sauer, **wir ändern das ab, wenn es so besser passt**.

    Die Gedanken:

    1. Wir brauchen in unserer Datenbank „Sprachbereiche“ (die nicht mit Ländergrenzen übereinstimmen müssen).

    2. Wir brauchen für jeden Sprachbereich einen Arbeitskreis/Kommission/Stammtisch/younameit *aus Locals*, der für die Beschriftungen eine sortierte Liste von (sortierten) Sprach-Mengen erarbeiten, die Sie als Vorgabe beim Labeln der Karte nutzen können. Eine Liste könnte so aussehen: (de+it, de, it, en). Wenn eine Region eine Sprache und deren Transkription will, ist auch das ok.

    3. Sie ignorieren beim Labeln das „name=”-Element, schauen stattdessen in die Prioritätenliste, wählen das erste Element, für das Sie alle Komponenten als “name:{lc}” finden und nutzen diese. Bei „+“ labeln Sie zweisprachig.

    Da die Prioritätenliste ausgelagert wird, bleibt dem Datenerfasser kein Spielraum zur Manipulation der Anzeige. Das „name=“ wird für die Darstellung ignoriert, und die “name:{lc}” fehlzuerfassen ist offensichtlicher Vandalismus.

    Damit könnte eine erste internationale Karte so beschriftet werden, dass alle vor Ort zufrieden sind.

    Eine zweite internationale Karte würde die Beschriftungen aus der ersten internationalen Karte nutzen, jeweils erweitert um eine Transkription (von den Locals ausgewählt) in lateinischer Schrift. Auch diese Karte würde allen Menschen nutzen, insbesondere erlaubte sie das Sprechen über Geografie. (Wobei durch den Platzbedarf Label unterdrückt werden, aber so ist es nun mal beim Hobeln.)

    Bei allen weiteren Karten kann man auf das Do-it-yourself verweisen: „Wenn Du eine japanische Karte haben willst, dann render Dir eine.“

    Gruß Wolf

Hinterlassen Sie eine Antwort

Pflichtfelder sind mit * markiert.



Durch das Abschicken Ihres Kommentars stimmen Sie der Datenschutzrichtlinie zu und erlauben, dass die eingegebenen Informationen (mit Ausnahme der eMail-Adresse) in diesem Blog veröffentlicht werden.