OpenStreetMap und externe Datenbanken
Dies ist ein Versuch, die Beziehung von OpenStreetMap (OSM) und externen Datenbanken, bzw. weitere Gemeinschaften zu untersuchen und Verknüpfungmöglichkeiten aufzuzeigen.
OpenStreetMap-Daten können mit anderen (Geo-)Daten verknüpft werden. Diese anderen Daten können einfache Kopien oder Ausschnitte von OSM oder aber eigenständige 'Fachinformationssysteme' (FIS,en: Professional Information System, PIS) sein. Die Mitglieder, die an den FIS beteiligt sind, können 'Fachinformationsgemeinschaften' (FIG, en:Professional Information Community/PIC) genannt werden.
Es muss vorausgeschickt werden, dass die Hauptinfrastruktur von OSM nur auf Webdienste ausgerichtet sind, welche es erlauben, die OSM-Datenbank zu pflegen v.a. mittels Editoren. Sobald ressourcen-intensivere Aufgaben anfallen (wie z.B. Spezialkarten), müssen die Daten von OSM zu sich kopiert werden. Das können vorgefertigte räumliche Ausschnitte davon sein und/oder sog. differentielle Updates.
Man kann folgende externe Datenbanken unterscheiden:
- Externe Datenbanken im engeren Sinne, welche die OSM-Daten zu sich kopieren, filtern und aufbereiten (ohne eigene Daten/Ebenen), z.B. OpenStreetBugs, Lonvia's Wanderkarte, Wheelmap.
- Externe Datenbanken im weiteren Sinne, welche die OSM-Daten zu sich kopieren, filtern und mit eigenen Daten verknüpfen (v.a. mit der OSM-ID). Das Resultat davon muss dann wieder OSM zurückgeben werden und alles als ODbL lizenzieren sein.
- Externe Datenbanken im weiteren Sinne, welche die eigenen Daten mit OSM vergleichen (v.a. mit der OSM-ID), ansonsten aber weitgehend eigenständig sind.
Lösungsansätze aus Sicht externe DB:
- Objekte der externen DB speichern bei sich die OSM-ID. Die OSM-ID der externen DB zeigt auf ein OSM-Objekt (SET OF DB[osmid]->OSM). Die externe DB versucht "synchron" zu bleiben mit OSM.
- In OSM wird eine ID erfasst, die auf ein Objekt der externen DB zeigt (OSM[tags]->DB). Die externe DB versucht "synchron" zu bleiben mit OSM.
- Die externe DB identifiziert eine (möglichst) eindeutige Kombination von Tags (ohne ID) und macht eine Query, um diese zu finden (vgl. dazu die Verknüpfung von Wikipedia mit Objekten und Kartenausschnitten in OpenStreetMap z.B. in 'WIWOSM').
Diskussion der Lösungsansätze:
- Zur Variante 1:
- Für die Verknüpfung bietet sich technisch die OSM-ID an - und das wird auch bei einigen Projekten so ausgenutzt. Die Eindeutigkeit und Unveränderbarkeit von OSM-IDs ist aber nicht garantiert! Dies u.a. um Unabhängigkeit von OSM zu wahren und intern reorganisieren zu können (vgl. dazu einige Diskussionen aut Talk-de).
- Die erste Variante belastet OSM am wenigsten.
- Diese Variante hat aber nebst der OSM-ID auch den Nachteil, dass die OSMler nicht realisieren, dass da etwas "dranhängt" und löschen als Folge davon unbedacht Nodes (und in OSM gibt es kaum ein "Loesch- und Editierverbot"). Es gibt einige Projekte, die das verwendent, z.B. OpenStreetBugs.
- Bei der zweiten Variante könnte man eigene Tags oder Tags z.B. mit Präfix (in der Art "TMC:tmc_id=8326765") angeben bei der der Präfix ein Hinweis auf das Projekt ist. Die Variante soll mit besonderer Zurückhaltung gehandhabt werden, d.h. es sind die OSM-Richtlinien zu konsultieren. Ein akzeptiertes Beispiel dafür ist das Wikipedia-Tag.
- Bei der dritten Variante handelt es sich meist um Datenbanken im weiteren Sinne, die von FIGs verwaltet werden. Dabei müssen die FIGs die Lizenzbestimmungen von OSM beachten. Dies gilt besonders, wenn die OSM-Daten heruntergeladen und zusammen mit anderen in einer Datenbank verwaltet werden. Die dritte Variante eignet sich in Fällen, wo die Beziehung zwischen FIS und OSM "lose" ist. Sie eignet sich nicht gut für die Automatisierung.
- In allen drei Fällen ist es denkbar, dass von den Applikationen auch Daten wieder an OpenStreetMap zurückgegeben werden (z.B. Wheelmap).
Eine Variation der ersten Variante und dem ersten Lösungsansatz ist eine Applikation, die zwischen der externe DB und OSM liegt (ein Webdienst). Die externe DB informiert sich dann via Webdienst bei OSM, wo sich etwas geändert hat. Dies lässt offen, welcher Lizenz die externe Datenbank unterliegt. Man stelle sich eine Art "OSM-ID-Proxy" oder ein "OSM-Alert-Dienst" vor, der mittel Analyse der OSM-'Diffs' eruiert, was sich in OSM geändert hat. Diese Änderungen müssten dann "autonom nachvollzogen" werden. Die Nutzer der externen DB könnten dabei auch etwas an OSM zurückgeben, in sie auch bei OSM beitragen. Natürlich muss dabei beachtet werden, dass die Nutzer ihre Beiträge unter ODbL freigeben und die Daten in OSM richtig integriert sind.
