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 _______________________________________________ Talk-de mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-de
