Dauerhafte Links nach OSM

Ein einzelnes Objekt (Knoten, Weg oder Relation) in OSM lässt sich zwar über seine ID identifizieren, aber diese ID kann kurzlebiger als das Objekt sein. Ein Beispiel dafür sind im Wiki Links der Form http://www.openstreetmap.org/browse/relation/23092.

Aktuell erhalten viele Objekte im Rahmen des Lizenzwechsels eine andere ID. Aber auch das Aufspalten eines Weges in zwei Teilwege führt dazu, dass die eine Hälfte nicht mehr über die alte ID auffindbar ist.

Mit Hilfe der Overpass API können in OpenStreetMap jetzt auch semantische, permanente Links gesetzt werden. Aus einem Link wie oben wird dann ein Link auf die Relation, die das Tag “ref” mit dem Wert “A 555″ und das Tag “network” mit dem Wert “BAB” hat:
http://overpass-api.de/api/interpreter?data=[out:custom];rel[ref="A 555"][network=BAB];out;
Ein solcher Link ist nun tatsächlich gültig, so lange das beschriebene Objekt existiert, egal mit welcher ID. Gibt es genau eine Relation mit diesen Eigenschaften, wird auf die entsprechende Seite http://www.openstreetmap.org/browse/relation/23092 weitergeleitet. Gibt es mehr als eine Relation oder keine Relation, wird eine Auswahlseite angezeigt.

Ein Beispiel für das Verlinken befindet sich auf der Seite WSW_mobil#CityExpress. Die Links dort sind mit dem Template Template:PTRoute erzeugt. Die Identifikation der gesuchten Relationen erfolgt hier über die beiden Tags _network_ und _ref_. Dabei erfüllen die Templates nun auch eine wichtige semantische Aufgabe: Sie drücken aus, welche Tags für eine bestimmte Kategorie von Objekten (z.B. Autobahnen oder Buslinien) sinntragend sind.

Dabei lässt sich auch das Linkziel und das Aussehen der Suchergebnisseite frei einstellen. Ebenso lassen sich auch geographische Begrenzungen zur Identifikation des Objekts verwenden. Details hierzu sind auf der Wikiseite Overpass_API/Permanent_ID (in Englisch) erläutert.

Damit können tote Links im Wiki mit einmaligem Ändern durch dauerhaft aktuelle ersetzt werden.

Roland

Roland mappt unter Roland.olbricht und hat seinen Schwerpunkt auf die Entwicklung der OSM-Infrastruktur gelegt. Beruflich ist er am Fraunhofer-Institut SCAI in St. Augustin bei Bonn als Software-Entwickler (ohne Bezug zu OSM) tätig.

Kategorie: Gastblog

  1. Simon Poole

    Sehr schön, nur … was passiert wenn du Morgen z.B. vom Bus überfahren wirst? Dann ist wohl die Dauerhaftig vorbei (Domainnamen etc). Ich würde deshalb das ganze erst propagieren, wenn durch geeignete Massnahmen tatsächlich darauf gezählt werden kann, dass der Dienst langfristig betrieben werden kann.

  2. Beat

    Cool, so was hab ich schon lange gesucht!
    Gibt es eine Möglichkeit, statt auf http://www.openstreetmap.org/browse/relation/23092 direkt auf http://www.openstreetmap.org/?relation=23092 weiterzuleiten, d.h. nur die Karte ohne all die Tags und Id’s?

  3. Stefan

    Ich finde die Overpass-Syntax allgemein ziemlich verkorkst: Warum braucht es “;out” und beim XML und ? Das scheint mir eine Vermischung von deklarativer (das “Was” wie bei SQL) und prozeduraler (das “Wie”) Art&Weise zu sein. Warum nicht gleich SQL (bzw. OGC’s CQL) oder XQuery verwenden? Oder warum nicht wenigstens das XAPI erweitern? Gibt es z.B. eine Compiler-taugliche Definition vom Overpass API, wie es dies sogar vom einfachen XAPI gibt (vgl. http://bit.ly/wqswV7 )?

  4. Roland

    Overpass API folgt rein dem imperativen Paradigma. Das mag für eine Abfragesprache überraschend sein, erleichert aber z.B. die Sicherheitsprüfung. Im Kontext einer imperativen Sprache ist dann auch “out;” nichts anderes als eine Ausgabeanweisung einer imperativen Sprache. Einfache Beispiele enden mit einer einzelnen Ausgabe, komplexere nicht unbedingt.

    Entscheidend ist aber ein anderer Vorteil: künftige, noch komplexere Skripte auf Overpass API, können dann potentiell mehr Nutzer nachvollziehen, weil mehr Nutzer Vorkenntnisse in C++, Java, JavaScript oder einer der anderen zahllosen imperativen Sprachen mitbringen. Die Subtilitäten fortgeschrittener Programmierung wären sonst eine unnötige erhebliche Hürde für potentielle Nutzer.

    Bei der Wahl, Zeit in eine formale Definition oder ein umfassendes Testbed zu stecken, habe ich mich lieber für das Testbed entschieden – der durchschnittliche Nutzer profitiert von einer fehlerarmen Software mehr als von einer hypothetischen Verarbeitbarkeit mit Yacc und Lex.

Kommentieren

Deine E-Mail-Adresse wird nicht veröffentlicht.