-
Notifications
You must be signed in to change notification settings - Fork 4
OSM Import
Sourcecode des Imports auf GitHub
Es gibt einen zweiten Importer für OSM-Daten.
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 |
Initialer Import basierend auf OSM-File
-
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.
Update basierend auf OSM-File Ü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.