Ermittlung von lon und lat zu einer Adresse

Hallo,
zu meiner Frage: Ich habe eine Anzahl an Adressen (PLZ,Strasse,Hausnummer) und möchte hierzu die Koordinaten ermitteln.
Ich habe mir die Baden-Württemberg.osm.bz2 heruntergeladen und dieses XML in eine Datenbank importiert.
Soweit hat alles geklappt und ich habe nun 9 Tabellen bekommen.

  • bound
  • member
  • nd
  • node
  • osm_node_tag
  • osm_relation_tag
  • osm_way_tag
  • relation
  • way

In der Tabelle “node” befinden sie die Felder lon und lat, welche ich benötige.
Aus der Tabelle osm_node_tag bekomme ich die PLZ, Strasse und Hausnummer incl. dem Schlüssel node_id mit welchem ich dann die Daten aus der Tabelle node (lon und lat) verknüpfen kann. Das funktioniert soweit auch.

Jetzt kommt der Punkt an dem ich nicht weiter komme.
In der Tabelle osm_way_tag habe ich Adressen, welche in der osm_node_tag nicht vorhanden sind. Leider besitzt die Tabelle osm_way_tag keinen Schlüssel mit welchem ich auf die Tabelle node zugreifen kann, in der die lon, lat Informationen enthalten sind.

Meine Fragen:

  • Kennt jemand einen Weg, wie ich diese Informationen trotzdem verknüpfen kann?
  • Benötige ich hier eine andere *.osm (XML File)?

Über einen kleinen Denkanstoß wäre ich dankbar.

Beste Grüße
DasBlatt2k

Das OSM-Datenmodell kennt Adressen als Tags auf Nodes und auf Ways. Also kannst du deine Adressen u.a. in osm_way_tag finden.

Ich würde jetzt tippen(!), dass du mit osm_way_tag in die Tabelle way indizieren kannst. Wie du dann weiter auf die nodes des Weges kommst (ein Weg besteht aus nodes) musst du gucken. Sieht member oder nd vielversprechend aus?

Ein anderer Weg wäre deine eigene Nominatim-Instanz aufzusetzen. Nominatim kann dir von den ganzen Tabellen abstrahieren und bietet eine komfortable Geocodierungs-API an. Da gibst du dann die Adresse an eine URL und kriegst ein XML/JSON mit den Koordinaten zurück.

http://wiki.openstreetmap.org/wiki/Nominatim/Installation

Erstmal Willkommen im Forum! (*)

Prima - nur was für eine DB?

Gruss
walter

*) Hier werden Sie geholfen, ob Sie wollen oder nicht. :wink:

Nur nodes haben bei OSM konkrete Geokoordinaten. Ways referenzieren auf nodes und sind damit über deren Koordinaten definiert. Da wirst du aus allen Nodes, die einen Way bilden, irnkwie einen Mittelwert, Schwerpunkt oder was auch immer ermitteln müssen. Gebäude sind in der Regel als ways angelegt und die Adressen an den way getaggt, das wird also relativ häufig so sein.

Du wirst wohl auch in der osm_relation_tag noch Adressen finden (Gebäude als Multipolygon angelegt o.ä.), da musst du den Sprung zweimal machen (das MP referenziert nur Ways, und deren Nodes definieren dann die Lage).

–ks

Hallo!

Um wie viele Adressen geht es denn? Und, magst du selbst basteln oder einfach eine fertige Maschine verwenden? Das Zweite ist natürlich einfacher. Hier ist eine Auswahl geeigneter Systeme:

https://wiki.openstreetmap.org/wiki/Search_engines

Recht leistungsfähig und gewissermaßen ein Standard ist Nominatim, welches sich ohne Weiteres auch lokal installieren lässt. Hab das letztes Jahr für Geschwindigkeitsverlgeiche in einer VM gemacht. Wenn es nur um BaWü geht, dauert der Datenimport auch nicht so sehr lange (wahrscheinlich deutlich weniger als einen Tag).

Ansonsten findest du in dem auf dieser Wiki-Seite ganz unten verlinkten Dokument einiges zum Thema Adressdaten in OSM:

https://wiki.openstreetmap.org/wiki/osmgeoref

Wie gormo und kreuzschnabel schon schrieben, ist die Sache nicht immer so einfach. :frowning:

Hallo,

Das ist ein Osmosis-Schema, das zwei große Nachteile hat:

  1. Nur die Nodes haben Koordinaten, was für räumliche Abfragen schlecht ist. kreuzschnabel hat das etwas ausführlicher beschrieben.
  2. Tags liegen in separaten Tabellen → unnötige Joins

Lösung: Datenbank löschen und mit osm2pgsql neu importieren. Der Vorteil von osm2pgsql-importierten Datenbank ist, dass du PostGIS nutzen kannst und in der Polygon- und Linestring-Tabelle direkt ein Feld für Geometrien hast.

Noch bessere Lösung: Einen Geocoder installieren (z.B. Nominatim). Nominatim nutzt zwar osm2pgsql für den Import, hat aber ein anderes Datenbankschema als Datenbanken für Tileserver.

Bitte beachte die Share-Alike-Klausel der Open Database License und prüfe, ob die von dir angedachte Verwendung erlaubt ist. Das ist für dich nur relevant, wenn du die geocodierten Daten an Dritte weitergibst. (Diese Aussage ist keine Beratung und kann falsch sein.)

Viele Grüße

Michael

Hallo und herzlichen Dank für die vielen und schnellen Antworten.

@gormo:
Ein weg von der osm_way_tag über die way Tabelle und dann zur node in welcher lon und lat sind, ist möglich, allerdings werden die total falschen Koordinaten angezeigt. Von daher für mich leider unbrauchbar 

@wambacher:
Ich nutze derzeit eine MSSQL Datenbank. Die XML importiere ich mit Hilfe von BIDS also einem ETL Tool.

@kreuzschnabel:
Danke für die kurze Zusammenfassung der ERM. Allerdings, sind die Ergebnisse für mich leider unbrauchbar.

@Marqqs
Bisher bin ich nur an ca. 10.000 Adressen interessiert, können aber wenn alles klappt auch deutlich mehr werden.
Ich denke der Tipp mit Nominatim werde ich heute einmal ausprobieren. Hatte da schon ein Script gebastelt, allerdings wurden nur ca. 500 Adressen gewandelt bevor es zu einer „Sperre“ für ca. 30 Min gekommen ist.

@Nakaner:
Danke für die ausführliche Beschreibung.
Ich werde osm2pgsql mal ausprobieren und auch das Nominatim noch weiter beleuchten.
Die komplette Datenaufbereitung ist nur für mich, und wird nicht an dritte weitergegeben, aber Danke für den Tipp.

@All: Danke für die zahlreichen Antworten und Tipps um mein „Problem“ zu lösen. Wenn ich zu einem brauchbaren Ergebnis komme, werde ich Euch berichten.

Beste Grüße
DasBlatt2k

Das passiert, wenn man sich nicht an https://operations.osmfoundation.org/policies/nominatim/ hält. Für deine Anforderungen benötigst du eine eigene Instanz.

Erstelle eine kleine PostgreSQL-DB + PostGIS, importiere mit osm2pgsql und dir stehen alle spatialen (geometrischen) Abfragen zur Verfügung. Das ist ein bei OSM verbreitetes Verfahren, bei dem du auf “ausgetretenen Wegen” läufst und viel Support von uns erwarten kannst.

Spatiale Abfragen mit Mysql sind mMn ein Krampf.

Gruss
walter