OpenStreetMap und externe Datenbanken

Aus Geoinformation HSR
Version vom 21. Mai 2018, 22:38 Uhr von Stefan (Diskussion | Beiträge)

(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)
Wechseln zu: Navigation, Suche

Dies ist ein Versuch, die Beziehung von OpenStreetMap (OSM) und externen Datenbanken, bzw. weitere Gemeinschaften zu untersuchen und Verknüpfungsmöglichkeiten aufzuzeigen.

Einleitung

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 immer wieder daran erinnert werden, dass die Hauptinfrastruktur von OSM v.a. auf Dienste 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:

  1. Externe Datenbanken, die ihre Daten direkt in OSM integrieren wollen (OSM Imports)
  2. Externe Datenbanken, welche die OSM-Daten zu sich kopieren, filtern und aufbereiten (ohne eigene Daten/Ebenen).
  3. Externe Datenbanken, welche die OSM-Daten zu sich kopieren, filtern und mit eigenen Daten verknüpfen (v.a. mit der OSM-ID). Das Resultat davon muss unterliegt typischerweise der ODbL Lizenz (je nach Art der Verknüpfung).
  4. Externe Datenbanken, welche die eigenen Daten mit OSM verknüpfen (v.a. mit der OSM-ID, oder umgekehrt mit zusätzlichen OSM-Tags zur Identifikation) und vergleichen, ansonsten aber weitgehend eigenständig sind (auch lizenzmässig).
Bemerkung zu OSM Imports

Das Importieren ganzer Datenbestände wird restriktiv gehandhabt. So wird z.B. u.a. ein Eintrag auf http://wiki.openstreetmap.org/wiki/Import/Catalogue verlangt und eine Information/Diskussion darüber auf einer Mailingliste. Man beachte hierzu unbedingt die OSM Import Guidelines!

Bemerkung zu OSM Identifikatoren (IDs)

Für viele Anwendungen ist es nützlich, OSM-IDs zu verwalten. Dazu muss man sich aber bewusst sein, dass OSM-IDs primär zu "OSM-internen" Zwecken dienen; sie können irgendwann ändern (z.B. um die OSM-Infrastruktur zu verbessern).

Beispiele externer Datenbanken in OSM

  • OpenGeoDB
  • TMC
  • OpenAdresses.org
  • ...

Synchronisation OSM mit externen Datenbanken

Bei externen Datenbanken im engeren Sinne reduziert sich die Lösung der folgenden Probleme:

  • Synchronisation: Die Synchronisation geschieht mittels Replikation, bzw. differentiellem Update, z.B. jede Minute, Stunde, täglich oder in grösseren zeitlichen Abständen. Vgl. z.B. Osm2pgsql
  • Verwaltung von regionalen Ausschnitten: Die lokale Kopie kann die ganze Welt oder nur einen Ausschnitt davon sein. Dabei ist der lokale Ausschnitt zwar datenmässig handlicher, jedoch schwieriger zu handhaben mit differentiellem Update.
  • Aufbereitung (v.a. Polygone): Die Aufbereitung von OSM-Objekten, v.a. Flächen, zu "echten" (GIS-)Polygonen ist eine weitere Herausforderung.

Beispiele: PostGIS Terminal, OpenPOIMap, OpenStreetBugs, Waymarked Trails/Wanderwege (von Lonvia), Wheelmap, Rollstuhlkarte

Werkzeuge:

  • iD / JOSM
  • http://osmly.com/ - OSMLY - a simple browser based importer for OpenStreetMap. It makes importing easy by presenting each feature one at a time, allowing users to manually review the item, make any needed adjustments to positions or tags, and upload directly to OSM. It also allows for reporting problems that other users can look over and a quality assurance mode where administrative users can confirm everything that has been uploaded.
  • https://github.com/osmlab/changewithin - changewithin - changewithin is a simple script that pulls daily changes from OpenStreetMap with requests, parses them with lxml, finds the ones that are inside of a GeoJSON shape, sorts out the ones that are buildings, and emails a set of users with mailgun.
 >> changewithin und OSMLY <<

Externe Datenbanken, welche die eigenen Daten mit OSM verknuepfen

Varianten:

  1. Variante "Räumliche Beziehung ExtDB->OsmDB" (oder "Koordinatensystem-Beziehung"): Die exterene DB nutzt OSM nur zur Lokalisierung ihrer Objekte und zwar über das gemeinsame bzw. ineinander transformierbare Koordinatensystem (sog. "Georeferenzierung").
  2. Variante "OsmDB[tag_id]->ExtDB": In OSM wird in den Tags eine "Tag ID" ("tag_id") erfasst, die auf die ID eines Objekts der externen DB zeigt.
  3. Variante "OsmDB[SET OF tags]->ExtDB": Die externe DB identifiziert eine (möglichst) eindeutige Kombination von Tags (ohne ID) und macht eine Query, um diese zu finden.
  4. Variante "ExtDB[SET OF osm_id]->OsmDB". Ein oder mehrere Objekte der externen DB speichern bei sich die OSM-ID ("osm_id") - nebst weiteren Sachdaten (und ev. weiteren Objekten mit Geometrie).

Diskussion der Lösungsansätze:

  • In allen Fällen ist nicht ausgeschlossen, dass von der Applikation auch Daten wieder an OpenStreetMap zurückgegeben werden (z.B. Wheelmap).
  • "Allgemeine Prüfung": V.a. in den Varianten zwei und vier muss regelmässig oder periodisch mittels Tag-Regeln überprüft werden, ob ein Objekt in OSM neu eingefügt wurde, welche die externe DB betreffen.
  • Bei der ersten Variante ist die Trennung aller Daten offensichtlich. Für die übrigen drei Varianten macht es die Lösung einfacher, wenn die Geometrie nur in OSM verwaltet wird, wie dies z.B. bei Wheelmap der Fall ist.

Variante 1

Räumliche Beziehung:

  • Das entspricht einem einfache "Layering", d.h. der Anzeige der Objekte in verschiedenen Layers.
  • Eine Lösung dazu bietet z.B. der FeatureServer. Unter Berücksichtigung der ODbL kann man so eigene Geometrien und Sachdaten erfassen.

Variante 2

"OsmDB[tag_id]->ExtDB": Bei dieser 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. Ein akzeptiertes Beispiel dafür ist das Wikipedia-Tag.
  • Diese "leidet" nicht unter der instabilen OSM-ID und ist relativ einfach zu realisieren, denn es können die Werkzeuge rund um OSM genutzt werden. Die eigene Infrastruktur verlangt nicht einmal eine eigene Datenbank; für den Anfang reicht ein einfaches Content Management Systeme, das bis zu Webdiensten ausgebaut werden kann.
  • Die Variante soll aber mit besonderer Zurückhaltung gehandhabt werden, d.h. es sind die OSM-Richtlinien zu konsultieren.
  • Um - nebst der "allgemeinen Prüfung" (vgl. oben) - "synchron" zu bleiben (falls gefordert), muss die externe DB nur dijenigen Änderungen (Update, Delete) von OSM untersuchen, die das "eigene" Tag-ID enthalten.

Variante 3

"OsmDB[SET OF tags]->ExtDB":

  • Hier handelt es sich meist um Datenbanken im weiteren Sinne, die von FIGs verwaltet werden.
  • Um - nebst der "allgemeinen Prüfung" (vgl. oben) - "synchron" zu bleiben (falls gefordert), muss die externe DB periodisch über sämtliche eigenen Daten kontrollieren, ob damit bei OSM noch etwas "gefunden" wird.
  • 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.
  • Diese Variante eignet sich kaum zur Automatisierung und engen Verknüpfung mit OSM. Sie eignet sich in Fällen, wo die Beziehung zwischen FIS und OSM "lose" ist. Vgl. dazu die Verknüpfung von Wikipedia mit Objekten und Kartenausschnitten in OpenStreetMap z.B. in 'WIWOSM'.
  • Anderes Beispiel: Overpass permanent ID.

Variante 4

"ExtDB[SET OF osm_id]->OsmDB":

  • Für die Verknüpfung bietet sich technisch die OSM-ID an - und das wird auch bei einigen Projekten so ausgenutzt. Die OSM-IDs sind aber instabil, d.h. die Eindeutigkeit und Unveränderbarkeit von OSM-IDs ist nicht garantiert! Dies u.a. um die Unabhängigkeit von OSM zu wahren und intern reorganisieren zu können (vgl. dazu einige Diskussionen auf Talk-de).
  • Diese Variante belastet die OSM in Bezug auf die Datenmenge am Wenigsten.
  • Diese Variante hat aber nebst der 'instabilen' OSM-ID 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").
  • Um - nebst der "allgemeinen Prüfung" (vgl. oben) - "synchron" zu bleiben (falls gefordert), muss die externe DB in sämtlichen Änderungen (Update, Delete) von OSM nach den OSM-IDs suchen, die in der externen DB verwaltet werden.
  • Eine Lösung dazu bietet z.B. der FeatureServer (siehe dort die Demoseite mit OpenLayers, welche jedoch keine Daten (keine Einfügungen, Änderungen oder Löschungen) zurückschreibt).

"OSM-ID-Webdienst" oder "OSM-Alert-Dienst"?

Eine Variation einer externen Datenbank im weiteren Sinne ist eine externe DB sowie - neu und zusätzlich - eine Applikation (ein Webdienst), die zwischen ihr und der OSM DB liegt. Die externe DB informiert sich via diesen Webdienst bei OSM, wo sich etwas geändert hat. Es ist dies eine Variante, die sich auf den ersten und vierten Lösungsansatz stützt.

Man stelle sich eine Art "OSM-ID-Webdienst" (Proxy) oder ein "OSM-Alert-Dienst" vor, der mittel Analyse der OSM-'Diffs' eruiert, was sich in OSM geändert hat. Diese Änderungen könnten in einer Webapplikation mit Admistrations-"Frontend" angezeigt und müssten dann "autonom" mit Mitteln der externen DB nachvollzogen werden. Dies lässt offen, welcher Lizenz die externe DB unterliegt.

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 Daten in OSM richtig integriert sind sowie dass die Nutzer nicht nur der Lizen der externen dB zustimmen sondern dort ihre Beiträge auch unter ODbL freigeben.

Beispiele

Von «https://giswiki.hsr.ch/index.php?title=OpenStreetMap_und_externe_Datenbanken&oldid=64058»