OpenStreetMap und externe Datenbanken: Unterschied zwischen den Versionen

Version vom 4. November 2012, 17:03 Uhr

Dies ist ein Entwurf einer Seite, wo versucht wird, die Beziehung von OpenStreetMap (OSM) und externen Datenbanken, bzw. weitere Gemeinschaften zu untersuchen.

OpenStreetMap-Daten können mit anderen (Geo-)Daten verknüpft werden. Diese anderen Daten können als einfache Kopien 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.

Man kann folgende externe Datenbanken unterscheiden:

1. Externe Datenbanken im engeren Sinne, welche die OSM-Daten geschickt filtern und aufbereiten (ohne eigene Daten/Ebenen), z.B. OpenStreetBugs, Lonvia's Wanderkarte, Wheelmap.
2. 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).
3. 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:

1. Objekte der externen DB zeigen mittels OSM_ID auf ein OSM-Objekt (SET OF DB[osmid]->OSM)
2. In OSM wird eine ID erfasst, die auf ein Objekt der externen DB zeigt (OSM[tags]->DB).
3. 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:

• In allen drei Fällen ist es denkbar, dass von den Applikationen auch Daten wieder an OpenStreetMap zurückgegeben werden (z.B. Wheelmap).
• 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).
• 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.

Eine Variation der ersten Variante ist eine Applikation, die zwischen der externe DB und OSM liegt. Die externe DB informiert sich dann bei OSM, wo sich etwas geändert hat. Dies 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.