OpenStreetMap und externe Datenbanken
OpenStreetMap und externe Datenbanken (Fachinformationssysteme), bzw. weitere Fachinformationsgemeinschaften.
OpenStreetMap-Daten können mit anderen (Geo-)Daten verknüpft werden. Nennen wir diese anderen Geodaten 'Fachinformationssysteme' (FIS,en: Professional Information System, PIS) und die Mitglieder, die an den FIS beteiligt sind 'Fachinformationsgemeinschaften' (FIG, en:Professional Information Community/PIC). 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.
Man kann folgende externe Datenbanken unterscheiden:
- Externe Datenbanken im engeren Sinne, welche die OSM-Daten geschickt filtern und aufbereiten (ohne eigene Daten/Ebenen), z.B. OpenStreetBugs, Lonvia's Wanderkarte, Wheelmap. Datei ist es denkbar, dass von den Applikationen auch Daten wieder an OpenStreetMap zurückgegeben werden (z.B. Wheelmap).
- Externe Datenbanken im weiteren Sinne, welche die OSM-Daten mit eigenen verknüpfen (v.a. mit der OSM-ID), und das Resultat davon dann wieder OSM zurückgeben und alles als als ODbL lizenzieren)
- 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 zeigen mittels OSM_ID auf ein OSM-Objekt (SET OF DB[osmid]->OSM)
- In OSM wird eine ID erfasst, die auf ein Objekt der externen DB zeigt (OSM[tags]->DB).
- 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').
- Dies externe DB informiert sich bei OSM, wo sich etwas geändert hat.
Für die Verknüpfung der Variante 1 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).
Weitere Diskussion der Lösungsansätze:
- 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.
- 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.
Die vierte Variante lässt offen, welcher Lizenz die externe Datenbank unterliegt. Man stelle sich eine Art 'OSM-Alert-Service' vor, wo mittel Analyse der OSM-'Diffs' eruiert wird, was sich in OSM geändert hat. Diese Änderungen müssten dann "autonom nachvollzogen" werden. Das Projekt könnte dabe auch etwas OSM zurückgeben, in dem es erlaubt, dass deren Mitglieder auch wieder etwas in OSM beitragen. Natürlich muss dabei beachtet werden, dass die Nutzer, ihre Daten unter ODbL freigeben und die Daten in OSM richtig integriert sind.
