[Talk-de] LinkedOSMDB (War: "Permanente/stabile OSM IDs!")

[Stefan Keller]

Ich möchte den Diskussionsfaden von "Permanente/stabile OSM IDs!"
zusammenfassen wie folgt:

Den Anwendungsfall, den ich einem Lösungskonzept zuführen möchte, sind
Nachnutzer und (OSM-)externe Datenbanken (nennen wir es
"Fachinformationssystem X", das z.B. Schlafbänke als Objekte der
Realität verwaltet).

Das Fachinformationssystem X verwaltet eigene, zusätzliche
Eigenschaften eines Objekts der Realität jemand hat Schlafbänke
vorgeschlagen :->) und möchte sich mit der OSM DB verknüpfen. Dazu
kann sie sich - wie von Frederik skizziert - auf eine externe
Datenbank verlassen, nennen wir sie "LinkedOSMDB" (siehe auch z.B.
OpenMetaMap, die sich noch auf OSM IDs stützt).

Die LinkedOSMDB bietet in Richtung Fachinformationssystem X hin eine
eindeutige und stabile ID (z.B. ein URI à la Linked Open Data, oder
ein TOID à la UK's MasterMap oder die "Swiss OID" à la Interlis:
http://www.interlis.ch/oid/oid_d.php). Dazu gehört natürlich auch eine
schnelle API. Und Richtung OSM Datenbank hin zeigt sie auf
OSM-Objekte.

In OSM geht es nun darum, einen Ansatz zu finden, um eine ID eines
OSM-Objekts zu gewährleisten, die zusammen mit dem Objekt der Realität
eindeutig ist und stabil bleibt. Genau genommen, ist mit eindeutig "im
Rahmen eines bestimmten Kontextes" gemeint. Und ich spreche bewusst
von stabil und nicht von permanent, denn es ist nicht das oberste
Ziel, IDs auf gelöschte Objekte - die auch in der Realität gelöscht
wurden - zu erhalten - das wäre eine zusätzliche
Historisierungs-Dienstleistung. Die Meldung "Objekt bzw. ID nicht
(mehr) vorhanden" genügt.

Die OSM ID ist es nicht und soll es auch nicht werden, wie Frederik
das beschrieben hat.

Ein Vorschlag geht offenbar in Richtung "fuzzy links" bzw.
"semantische ID". Dabei "spielt" ein Mapper den Identifizierer und
definiert und speichert eine Query (z.B. ref+network) auf OSM Objekte
(vgl. dazu  http://wiki.openstreetmap.org/wiki/Query-to-map). Das ist
schon mal ein guter Ansatz (z.B. ist "name=Matterhorn" weltweit wohl
eindeutig für ein bestimmtes Objekt der Realität). Er ist gut und
genügt ev. für "query-to-map"-Anwendungen. Er ist aber für die oben
erwähnten Anwendungsfälle nicht hinreichend, denn er deckt nur einen
Teil von OSM Objekten ab: Was ist mit Parkbänken und Briefkästen.

Als Verbesserung schlage ich vor, dass die ID potentiell für jedes OSM
Objekt einsetzbar ist und als ID erkennbar sein soll. Vorschlag:
"linkedosmdb_id=..."! Man beachte, dass damit nicht automatisch
sämtliche OSM-Objekte damit "aufgebläht" werden und dass es keine UUID
sein muss, die "universumweit" eindeutig ist (das geht auch kürzer als
mit 64 Zeichen, wie TOID und Swiss OID zeigen).

Diese ID ist nicht zusammengesetzt (bei "network+ref" sieht man dem
Key "network" alleine keine ID-Eigenschaft an und man "sieht" auch
nicht, dass sie "zusammengehören"!). Und Koordinaten inkl. BoundaryBox
kommen auch nicht in Frage, denn das Objekt ist ja immer noch
dasselbe, wenn deren Lage ein paar Koordinatenstellen weniger hat oder
wenn es verschoben wird, weil jemand die Bushaltestelle an den
"richtigeren" Ort schiebt, die Orthophotos falsch georeferenziert
waren oder Koordinaten sich ändern, weil Kontinente herumdriften!!!

Eine offene Frage bleibt für mich: Was als Projekt-ID sinnvoller ist:
Sollen nebst "linkedosmdb_id=..." weitere Keys zugelassen sein
(gegeben sie sind ebenfalls nicht-zusammengesetzt und als ID erkennbar
und erheben ebenfalls den Anspruch, stabil zu sein, wie eben bestimmte
Objekt mit "name=...") ?

LG, Stefan