Unschön, mag ich gar nicht. Mach ich trotzdem manchmal.

Zum Editieren von Objekten einer Objektklasse muss ich sie identifizieren und unterscheiden können. In den meisten Fällen ist der Name dafür ausreichend. Aber nicht immer. Der Name könnte nicht existieren oder er existiert mehrfach im Editiergebiet. Einfachste Lösung: Namen erfinden bzw. auf Unterscheidbarkeit modifizieren.

Einfach ja, aber unsauber. Grundsätzlich ist hier das Wiki sehr klar: im name-Tag soll nur ein real existierender Eigenname stehen und nur der Eigenname [1].

Beispiele für suspekte Eigennamen

• Wanderweg 786 Viele ÖAV-Wanderwege haben keinen Namen, name=Wanderweg XXX ist sicher kein Eigenname
• Dorfkapelle Krusdorf Kategorie + Ort ist meist kein Eigenname. Hier ist es definitiv nicht korrekt, der Eigenname ist “Maria von den Engeln”
• Bus 600: Leibnitz Postamt => Graz Don Bosco Bahnhof Ein vollständig konstruierter Name. Das Public Transport Schema [2] hat das name-Tag vollständig gekapert
• Murradweg Verbindungsrouten (AT) der Eigenname wird mit der Ergänzung zu einem beschreibenden Namen
• Apotheke, Fußballplatz, Toilette Gattungsnamen sind kaum jemals Eigennamen. Spaßig die Diskussion Is name=Toilet even theorethically valid for amenity=toilets?

Meine konstruierten Namen

Viele Radrouten haben Alternativen, Zubringer und optionale Exkursionen. Nur bei kleinen und einfachen (ohne forward/backward) Routen verwende ich zur Benennung die Rolleneigenschaft [3]. Meist teile ich die Route aber in eine Hauptroute und in eine Alternative Route, mit allen Varianten, Zubringer und Exkursionen, auf. Oft unterteile ich auch die Hauptroute weiter in Etappen, um die Größe der Relationen unter 500 Mitgliedern zu halten.

Zur Unterscheidung der Teilrelationen ergänzte ich bisher die Namen:

Gesamtroute mit: Eigenname + "Master"
    Hauptroute mit: Eigenname

        Hauptroute Teil 1 mit: Eigenname + "Etappe 1"
        Hauptroute Teil 2 mit: Eigenname + "Etappe 2"
        :
    Alternativen, Zubringer ... mit: Eigenname + "Alternative"

Zum Bearbeiten der Relationen sind diese Namen praktisch, aber sauber ist es nicht.

Lösung für namenlose Relationen in JOSM

In der Diskussion zum Proposal [4] hat segubi eine Alternative zu konstruierte Namen vorgeschlagen: die “relation.nameOrder” in JOSM. Mit diesem Schlüssel wird angegeben welche Tags zur Referenzierung der Relationen in Frage kommen. Das erste nicht-leere Element in dieser Liste wird zur Benennung der Relation verwendet.

Zur Liste kommt man im Expert Mode unter Preferences/Advanced Preferences/relation.nameOrder. Die Default Einstellung und meine Änderung ist unten dargestellt:

Anwendungsfall Radweg I1

Der Tipp von segubi kam mir bei der Pflege des I1-Radweges gerade sehr gelegen. Der Betreiber nennt diese Route “I1 - Gardasee-Venedig”. Offensichtlich eine beschreibende Benennung, aber kein Eigenname. Diese Route habe ich in eine Hauptroute und eine Alternativroute aufgeteilt und weiters die Hauptroute in 4 Etappen geteilt.

Relation 1607435: I1 Hauptroute. Superroute mit den 4 Etappen als Mitglieder. Relation 16478126: I1 Alternativen. Varianten und Anbindungen, 269 Mitglieder.

Damit gab es mehrere Relationen ohne Namen, aber mit identischer ref=I1. Für eine leicht erkennbare Unterscheidung in JOSM waren zwei Änderungen nötig:

1. Tag description=<beschreibende Benennung> für die Relationen erstellen
2. Anpassung der relation.nameOrder - Liste

In der relation.nameOrder - Liste verschob ichdescription von der Position 13 auf die 2. Position - nach dem Namen, aber vor der Ref. Damit wird statt der immer gleichen Ref, die unterscheidbaren descriptions zur Benennung der Relationen verwendet. Der geänderte xml-File für JOSM Vers. 18822:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<config>
    <preferences operation="replace">
        <list key="relation.nameOrder" xmlns="http://josm.openstreetmap.de/preferences-1.0">
            <entry value="name"/>
            <entry value="description"/>
            <entry value="ref"/>
            <entry value="amenity"/>
            <entry value="landuse"/>
            <entry value="leisure"/>
            <entry value="natural"/>
            <entry value="public_transport"/>
            <entry value="restriction"/>
            <entry value="water"/>
            <entry value="waterway"/>
            <entry value="wetland"/>
            <entry value=":LocationCode"/>
            <entry value="note"/>
            <entry value="?building"/>
            <entry value="?building:part"/>
        </list>
    </preferences>
</config>

Die umgereihte Liste (erweitern ist möglich!) kann als XML-File direkt geladen werden. So gut diese Lösung in beim I1 funktionierte, es gibt doch einige Probleme:

• Key description - wird häufig zur Beschreibung des Elementes verwendet. Ein Nutzungskonflikt mit der Verwendung als “beschreibenden Namen” ist wahrscheinlich
• funktioniert nicht für benannte Routen - dazu müsste description in der relation.nameOrder-Liste vor dem Namen stehen. Vermutlich wäre das keine gute Idee

Lösung für benannte Relationen in JOSM

Bei benannten Routen habe ich bisher den Eigennamen mit passend Erfundenen ergänzt: Also “Eigenname” + “Hauptroute” oder “Etappe xx” oder “Alternativen” (siehe oben). Alternativ zum hier ungeeigneten description-Tag wäre auch ref_name vorstellbar.

ref_name wird häufig bei Haltestellen verwendet, wenn der Eigenname zur Referenzierung mit externen Datenbanken uneindeutig ist. Z.B: name=”Spielbank” und ref_name=”Bad Wiessee Spielbank”. Von der Struktur her ist es genau das gesuchte: ein beschreibender Name.

Auch die erste Stelle in der relation.nameOrder erscheint mir hier unproblematisch. Die Benennung der Relationen in JOSM mit “ref_name” statt “name” sollte eigentlich immer brauchbar sein.

Nur den ursprünglichen Zweck - die externe Referenzierung - erfüllt es nicht. Stattdessen wird es als eindeutiger Name zur internen Referenzierung verwendet. Der wesentliche Unterschied: die exterene Referenzierung ist offiziell und somit verifizierbar, die interne ist es nicht, da sie meine Erfindung ist.

Eine wirklich total saubere Lösung sehe ich nur mit einem neuen Tag erfüllbar:

descriptive_name = <beschreibender Name>

• Kein Bedeutungskonflikt mit bestehenden Tags

• Verifizierbarkeit ähnlich description

• Kann ohne Nebenwirkungen an erster Stelle in der relation.nameOrder-Liste stehn

Eigennamen wie “Dorfkapelle Krusdorf” wären dann Geschichte. Hoffentlich.

Resümee

Für Relationen ohne Namen ist das Tag description eine akzeptable Möglichkeit, Teilrelation unterschiedlich zu benennen und im Editor zu unterscheiden. Für Relationen mit Namen habe ich mit den bestehenden Tags keine saubere Lösung gefunden. Am besten scheint mir noch ref_name dafür geeignet zu sein.

In beiden Fällen - sowohl bei description als auch bei ref_name - wird die ursprüngliche vorgesehene Bedeutung etwas verschoben. Ich finde es noch akzeptabel, aber das wird vermutlich nicht jeder so sehen.

Eine wirklich saubere Lösung wäre ein neuer Schlüssel, wie z.B. “descriptive_name” um den häufigen Missbrauch der Eigennamen einzudämmen, ohne das Editieren zu erschweren.

[1] OSM Wiki Namen: https://wiki.openstreetmap.org/wiki/DE:Namen

[2] OSM Wiki Public transport: https://wiki.openstreetmap.org/wiki/Public_transport

[3] OSM Wiki Roles for recreational route relations: https://wiki.openstreetmap.org/wiki/Roles_for_recreational_route_relations

[4] Proposal: Use description instead of name for route relations