-
Notifications
You must be signed in to change notification settings - Fork 4
OSM Import
Der Sourcecode liegt hier in Github.
Achtung: Das ist ein Skizze des Algorithmus - wir arbeiten dran...
Wir setzen eine Datenbank auf, im folgenden OSM-ImportDB mit folgenden Tabelle:
Nodes
| Name | Type | Bedeutung |
|---|---|---|
| ID | PRIMARY KEY | primary key |
| Long | Longitude | |
| Lat | Latitude | |
| Tags | Referenz zu einer Tag-Tabelle oder hstore | enthält alle Tags, die im OSM-File gefunden werden. |
| OHDM-Geom-ID | Fremdschlüssel | ID der Geometrie (kann nur ein Punkt sein), die in OHDM gespeichert wurde - kann leer sein. |
| OHDM-Object | Fremdschlüssel | Verweis auf OHDM Objekte, dass wegen des Imports in OHDM angelegt wurde (kann leer sein). |
| valid | boolean | Wird beim Update benötigt, um zu prüfen, ob ein Element in OSM seit dem letztem Update gelöscht wurde |
Ways
| Name | Type | Bedeutung |
|---|---|---|
| ID | PRIMARY KEY | primary key |
| NodeIDs | hstore ? | Liste aller Node-ID aus OSM-File, die den Way beschreiben - als hstore beschreiben oder aber weitere Tabelle anlegen, die Zugehörigkeit Nodes zu Ways speichert. |
| Tags | s.o. | s.o. |
| OHDM-Geom-ID | Fremdschlüssel | ID der Geometrie, die in OHDM gespeichert wurde - kann leer sein. |
| OHDM-Geom-Type | Typ der Geometrie in OHDM (Linestring, Polygone) | |
| OHDM-Object | Fremdschlüssel | Verweis auf OHDM Objekte, dass wegen des Imports in OHDM angelegt wurde (kann leer sein). |
| valid | boolean | Wird beim Update benötigt, um zu prüfen, ob ein Element in OSM seit dem letztem Update gelöscht wurde |
Relations
| Name | Type | Bedeutung |
|---|---|---|
| ID | PRIMARY KEY | primary key |
| IDs | hstore ? | Liste aller Node- und Way-IDs aus OSM-File, die die Relation beschreiben - als hstore beschreiben oder aber weitere Tabelle anlegen, die Zugehörigkeit Nodes / Ways zur Relation speichert. |
| Tags | s.o. | s.o. |
| OHDM-Object | Fremdschlüssel | Verweis auf OHDM Objekte, dass wegen des Imports in OHDM angelegt wurde (kann leer sein). |
| valid | boolean | Wird beim Update benötigt, um zu prüfen, ob ein Element in OSM seit dem letztem Update gelöscht wurde |
-
Alle Informationen einer Node werden in die Node-ImportDB übertragen.
-
Alle Informationen eines Way werden in die Ways-ImportDB übertragen.
-
Alle Informationen eines Relations werden in die Relations-ImportDB übertragen. Damit ist das Parsen beendet.
-
Für alle Einträge in Nodes, die Tags enthalten: a) Erzeuge ein Geografisches Objekt in OHDM. b) Erzeuge eine Geometrie in OHDM. c) Erzeuge einen Eintrag in -Zeit-Objekt-Tabelle mit aktuellem Datum und unendlichem Endedatum, die Objekt und Geometrie in Relation setzen. d) Speichere alle Tags in Tags-Tabelle und setze Objekt mit den Tags in Relation (via Tag-Zeit-Objekt-Tabelle) e) Speichere OHDM-Objekt ID in Nodes Tabelle.
-
Für alle Einträge in Ways: Schritte analog zu 4 a) - e)
-
Für alle Einträge in Relations: a) Erzeuge ein OHDM-Objekt. b) Setze neues OHDM Objekt in Relation zu den anderen OHDM-Objekten, die basierend auf den Nodes / Ways bereits erzeugt wurden. c) analog zu 4 d) - e)
Damit ist der initiale Import beendet.
Vorbedingung: Die Zwischendatenbank enthält OSM-Daten
Der Import ist über eine Pipeline organisiert, die von allen OSM-Objekten (Nodes mit Tags, Ways und Relations) durchlaufen wird. Einige Pipeline-Stages behandeln je nach angegebener Prozessbedingung nur bestimmte Objekte. Alle ankommenden Objekte, für die die Prozessbedingung nicht gilt, werden unbehandelt an die nächste Stage weitergeleitet.
###Auslesen der OSM-Objekte
Das Auslesen der OSM-IDs hängt von der Art der zu verarbeitenden Objekte ab. Die Folgenden Unterpunkte dienen alle als Einstieg in die Verarbeitungspipeline.
Für den Node-Import werden zunächst alle Node-Ids inklusive der Zugehörigen Long-Lat-Werte aus der Zwischen-Datenbank ausgelesen. Mit den ausgelesenen Daten werden anschließend OHDM-Objekte erzeugt, die die entsprechende Osm-Node-Id und die geografischen Koordinaten enthalten.
Für den Way-Import werden zunächst alle Way-IDs aus der Zwischen-Datenbank ausgelesen. Mit den ausgelesenen IDs werden anschließend leere OHDM-Objekte erzeugt, die ausschließlich die entsprechende Osm-Way-Id enthalten.
- TODO -
Datenbasis: OHDM-Objekte mit OSM-IDs
In der 2. Stage werden alle Tags aus der Zwischendatenbank ausgelesen, die zu den in der Pipeline ankommenden OHDM-Objekten gehören. Die ausgelesenen Tags werden den einzelnen OHDM-Objekten zugeordnet und anschließend werden diese zur nächsten Stage weitergereicht.
Prozessbedingung: OHDM-Objekt ist ein Way
Datenbasis: Way-Objekte mit OSM-IDs und Tags
Diese Stage liest alle Nodes aus der Zwischendatenbank aus, die zu den ankommenden Way-Objekten gehören. Jedem Way-Objekt wird eine Node-Liste zugeordnet, aus der später eine Multilinestring- bzw. Multipolygon-Geometrie erzeugt werden kann.
###Datenspeicherung in OHDM
Im Folgenden werden die Pipeline-Stages zur Speicherung der OSM-Objekte in OHDM erläutert.
Datenbasis: OHDM-Objekte mit OSM-IDs
In dieser Stage werden zu den einzelnen OHDM-Objekten geografische Objekte in OHDM angelegt. Die erzeugten Geo-Objekte erhalten eine Gültigkeit vom 1.1.1970 bis zum 1.1.8099 (PgSQL-Maximum). Die neu generierten Geo-Objekt-IDs werden den OHDM-Objekten zugeordnet, diese werden anschließend an die nächste Stage weitergeleitet.
Prozessbedingung: Objekt besitzt Tags
Datenbasis: OHDM-Objekte mit Geo-Objekt-ID
Hier werden die Tags der OHDM-Objekte in OHDM eingefügt und über die Geo-Objekt-ID mit den Geo-Objekten verknüpft. Die OHDM-Objekte werden unverändert an die nächste Stage weitergeleitet.
Prozessbedingung: OHDM-Objekt ist ein Node Datenbasis: OHDM-Node-Objekte mit Geo-Koordinaten
Hier werden zu den ankommenden OHDM-Node-Objekten Multipoint-Geometrien in OHDM erzeugt. Die Node-Objekte werden um die entsprechende Geometrie-ID erweitert. Anschließend werden sie zur nächsten Stage weitergeleitet.
Prozessbedingung: OHDM-Objekt enthält einen Linestring Datenbasis: OHDM-Objekte mit Nodelisten
Hier werden die Multilinestring-Geometrien der OHDM-Objekte in OHDM erzeugt. Die erzeugte Geometrie-ID wird dem OHDM-Objekt zugeordnet, anschließend wird es an die nächste Stage weitergeleitet.
Prozessbedingung: OHDM-Objekt enthält ein Polygon Datenbasis: OHDM-Objekte mit Nodelisten
Hier werden die Multipolygon-Geometrien der OHDM-Objekte in OHDM erzeugt. Die erzeugte Geometrie-ID wird dem OHDM-Objekt zugeordnet, anschließend wird es an die nächste Stage weitergeleitet.
Datenbasis: OHDM-Objekte mit Geo-Objekt-IDs und Geometrie-IDs
Hier werden Geo-Objekte mit ihren Geometrien in OHDM verknüpft. Dies ist die letzte Pipeline-Stage, der Import der OSM-Objekte ist hiermit abgeschlossen.
Überlegungen auf den der folgende Algorithmus beruht:
-
Es gibt einen Update-Tag in OHDM. Wir definieren hiermit: Daten in OHDM können nur geändert werden, wenn sie vor dem letzten Update Tag entstanden. D.h.: angenommen ein Import fand statt am 1.6.2015. Danach kann man nur Daten ändern, die vor dem 1.6.2015 lagen. Es ist nicht möglich Daten einzubringen, die in der Gegenwart und Zukunft von OHDM liegen, das sind alle Zeiten nach dem letzten Import/Update.
-
Das impliziert für OHDM 1.0: OHDM-Daten gelten nicht für die Zukunft. OHMD-Daten sind gültig frühstens bis zum letzten OSM-Import. Die Reichweite in die Vergangenheit ist unbeschränkt..
-
Mit Geometrien (Nodes, Ways, Relations) in OSM kann in Bezug auf OHDM folgendes geschehen sein: Sie können
- unverändert geblieben sein,
- komplett neu sein,
- verändert worden sein oder
- gelöscht worden
Aktionen, die sich daraus ergeben sind offensichtlich:
| unverändert | Dauer wird erhöht, d.h. das Gültigkeitsdatum Zuordnung von Geometrie zum geografischen OHDM-Objekt wird verlängert. |
| neu | Hier wird wie im initialen Import gearbeitet: Objekte und Geometrien werden neu angelegt. |
| verändert | Die Gültigkeit der Geometrie zum Objekt wird beendet, d.h. das Endedatum wird festgelegt. Eine neue Geometrie wird angelegt und mit aktuellen Datum mit dem OHDM-Objekt verknüpft. |
| gelöscht | Wie _neu_ - es wird aber keine neue Geometrie angelegt. |
Der Update-Algorithmus wird (etwa) wie folgt arbeiten:
-
Valid-Spalte in alle Import-DB Tabelle auf false setzen. Dann läuft der Parser dreimal durch das OSM-File, um Nodes, Ways und Relations zu parsen - in der Reihenfolge.
-
Node aus OSM - File in ImportDB suchen per OSM-ID. Wenn gefunden: Werte geändert? Gleiche Werte, dann ist die Node unverändert. Wenn Wert geändert, dann ist die Node geändert. Wenn Node nicht gefunden, dann ist die Node neu. Verhalten:
| unverändert | valid auf true setzen. |
| geändert | Hat die Node Tags? Wenn ja: OHDM-Objekt finden. Objekt-Zeit-Geometrie auf beenden. Neue Geometrie anlegen und mit dem OHDM-Objekt verbinden. Analog mit den Tags verfahren. valid auf true setzen. |
| neu | Wie beim initialen Import, s.o. valid auf true setzen. |
Nach dem Parser Durchlauf: Für alle Einträge in Nodes mit valid == false gilt: Sie sind im Zustand gelöscht. Verfahren:
| gelöscht | Objekt-Geometrie Relation in OHDM-DB beenden. Eintrag aus der ImportDB löschen. |
- Parsen nach Ways - Verfahren analog zu Nodes.
- Parsen nach Relation - Verfahren analog zu Nodes.