-
Notifications
You must be signed in to change notification settings - Fork 4
OSM Import
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). |
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). |
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). |
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.
-
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