Wer in Deutschland, Österreich und der Schweiz vernünftig geocodieren will, kommt in der Regel nicht an der OpenGeoDB vorbei. Google Maps ist da zwar ganz nett, aber OpenGeoDB verbindet Orte nicht nur mit einer Postleitzahl, sondern strukturiert ganze Landstriche in Hierarchieebenen.
Allerdings (und gerade hier liegt die Tücke von OpenGeoDB) sind die Suchergebnisse von Google bzgl. eines Downloads der Datenbank sehr bedenklich. Anstatt sich hier auf Google zu verlassen, benutzen wir die aktuelle Version von OpenGeoDB, die hier zum Download bereitsteht, bzw. verwenden dieses Wiki. Alles was Google zu diesem Thema mitzuteilen gedenkt ignorieren wir geflissentlich!
Auf der Download-Seite selbst kann die OpenGeoDB nicht als Komplettpaket heruntergeladen werden, sondern man muss sich „seine Datenbank“ selbst zusammenstellen. Aus diesem Grund können wir auch alle Dateien mit der Endung *.tab von vorneherein ignorieren. Diese enthalten den Datenstamm als .csv-Datei.
Ich gehe jetzt mal davon aus, dass jeder weiß, wie man einen Datenbank-Dump importieren kann. Natürlich nehmen wir als Grundlage MySQL. Außerdem werden wir eine Datenbank für DE erstellen. Datenbanken für CH und AT werden analog erstellt, es lassen sich auch alle Datenbanken kombinieren.
Im ersten Schritt laden wir die Datei opengeodb-begin.sql herunter und importieren diese. Die Datei enthält lediglich die Strukturen der Datenbanken und keine Daten. Nachdem nun die Strukturen angelegt worden sind, müssen nun die Daten folgen. Hierzu muss man gemäß des gewünschten Landes die entsprechende Datei herunterladen:
AT.sql – Österreich
BE.sql – Belgien
CH.sql – Schweiz
DE.sql – Deutschland
LI.sql – Lichtenstein
Jede dieser Dateien enthält die Orte und die Postleitzahlen der einzelnen Länder. Die Dumps enthalten nur die Daten. Es kann entweder ein einzelner Dump importiert, mehrere oder sogar alle. Natürlich sollte man hier ein wenig darauf Achten, das man nur die Daten importiert, die man benötigt.
Zu guter Letzt werden wiederum in einer separaten Datei die Indizes innerhalb der Datenbank angelegt. Hierzu benötigt man die Datei opengeodb-end.sql. Ich empfehle direkt nach Import dieser SQL-Datei alle Tabellen mit einem „OPTIMIZE TABLE“ zu optimieren.
Eigentlich könnte man jetzt vernünftig mit dem System arbeiten, aber auf Wunsch kann man natürlich die bestehende Datenbank noch erweitern. Durch den Import der Datei changes.sql besteht die Möglichkeit, die aktuellsten Patches in die Datenbank einzuspielen. Eine sehr sinnvolle Sache, wie ich finde.
Durch Import der Datei extra.sql kann man den Datenbestand erweitern. Man kann später zum Beispiel Höhenangaben abfragen, aber auch den Kontinent. Richtig lustig wird die Datenbank allerdings erst, wenn man eine der folgenden Dateien importiert:
AThier.sql Hierarchie-Daten für Österreich
BEhier.sql Hierarchie-Daten für Belgien
CHhier.sql Hierarchie-Daten für die Schweiz
DEhier.sql Hierarchie-Daten für Deutschland
LIhier.sql Hierarchie-Daten für Liechtenstein
Auch hier ist wieder darauf zu achten, dass man nur die Daten importiert, die man auch wirklich benötigt. Durch den Import dieser Dumps ordnet man einen Ort in eine Hierarchie ein. Was heißt das? Am Beispiel von Deutschland kann man somit bei einem Ort oder einer Postleitzahl feststellen, ob es sich nur um einen Ortsteil handelt (dies ist bei Postleitzahlen in der Regel immer der Fall). Entsprechend kann man dann mit dem Dump ermitteln, zu welcher Ortschaft der Ortsteil gehört. Die Ortschaft kann wiederum einem Landkreis zugeordnet werden, dieser einem Regierungsbezirk und letztendlich einem Bundesland.
Die Hierarchie kann viele Einsatzmöglichkeiten finden, so zum Beispiel für eine einfache Umkreissuche. Eigentlich ist der Import der Daten recht einfach, wenn man weiß, wofür die einzelnen Dateien gut sind. Arbeitet die Liste einfach in der hier vorliegenden Reihenfolge ab, und entscheidet genau, welche Daten ihr braucht und welche nicht, dann kann eigentlich nichts schief gehen. Einem finalen „OPTIMIZE TABLE“ tut an dieser Stelle übrigens niemandem weh.
Hallo Guido,
wenn du uns noch erklären kannst warum – opengeodb-end – sich nicht ordnungsmessig mportieren lässt… Dabei bricht der Import ab mit Fehler: -MySQL meldet:
– MySQL server has gone away – | SQL-Befehl:
CREATE INDEX text_val_idx ON geodb_textdata –
Gerade zum Schluss sowas zu erleben ist ärgerlich.
Guido, du bist Super.
Wenn Jeder so einfach erklären könnte wie du, wäre die Welt viel netter.
Ich hatte voher so viel im Web gelesen und immer nicht verstanden wofür was ist, was genau braucht man überhaupt von den ganzen Datein, die da stehen, welsche Datei macht was? usw.
Nur jetzt sehe ich wie das Ganze so easy zu verstehen und zu installieren ist, wenn de richtige Man auch mit den richtigen Wörter erklärt, und endlich weiß man wie diese Database gebaut wird. Der rest kann man weiter lernen.
DANKE
Hallo Guido,
ist das ganze auch ohne changes.sql brauchbar ?? selbst nach stundenlangem Fehleraussortieren funktioniert der Import nicht.
Warum beinhaltet die Datei noch Daten von 2007 ? Ist das nicht eher ein Schritt rückwärts ?
Grüße, Lisa
Danke Guido,
habe auf anderen Sites auch Beschreibungen gefunden, die komplizierter klangen als es wirklich ist. Alles im allen, kommt es wirklich drauf an, welche Daten man wirklich braucht und auch brauchen könnte.
Leider gibt es in Berlin viele PLZs die falsch targiert sind in der OG_DB…
Danke für die gute Beschreibung!
Danke für die ausführliche Beschreibung, ich werde es gleich mal ausprobieren
Ich habe ein komplettes Dump von Deutschland inklusive changes.sql mit Stand vom 20.05.2011 online gestellt. Das Zusammenführen der Daten gestaltet sich ja nicht besonders einfach. Vll. hilft es irgendjemandem: http://www.henpeck.de/cms/index.php?id=113
[…] Die OpenGeoDB liefert einen wahren Schatz an Daten mit Geoinformationen. Guido Mühlwitz hat in seinem Blog ein gutes Tutorial veröffentlicht, das die Einrichtung der OpenG… […]
Ich hab mal in die DE.sql rein geschaut und habe dort zwar Ortsangaben aber keine Straßen gefunden.
Habe ich da etwas übersehen?
Wenn nicht, wie kann ich dann zu einer Adresse die genauen Geokoordinaten ermitteln?
MfG
cheapy
versuch es mal mit http://www.mysqldumper.de
da sollte es klappen
Wie bekomme ich denn denn upload dieser großen SQL-Datei hin?
Bekomme ständig Zeitüberschreitungs-Fehler und mein Provider untersützt nur Dateien bis 2 MB.
Wäre toll, wenn ich dazu einen Tip bekäme
MfG
Daniel
Hallo Guido,
ein sehr schöner Artikel!!!
Beim Import der aktuellen changes.sql (Stand 30.10.2009) gibt’s allerdings Fehlermeldungen…
…durch das ‚INSERT INTO‘ bei bestehenden Datensätzen – ‚REPLACE INTO‘ könnte da Abhilfe schaffen…
Doch später hakt’s dann bei vielen Zeilen mit leeren Parametern (suche mal nach 2 aufeinander folgenden Komma-Zeichen).
Ich werde das Tutorial weiter durcharbeiten (natürlich auch das ‚Geocoding‘) und sicher hier auf Deiner WebSite in Zukunft öfter wieder reinschauen…
Anregung:
Eine Anpassung für CakePHP würde sicher viel Anklang finden…!!! Wie ich gesehen habe, bist Du auch in dem Bereich aktiv. :-)
Die Geocoding-Variante aus der BAKERY (über Google-API) finde ich persönlich nicht so toll. Eine Cake-Lösung über den OpenGeoDB-Datenbestand wäre IMHO der bessere Weg.
Beste Grüße
Karsten
Das klingt wirklich interessant!
Ich werde da mal sehen, was ich damit anfangen kann.
Danke für den Artikel!
Ich habe aber eine Anmerkung: diesen Artikeln fehlt eine Print-Funktion und über „Druckvorschau“ im Browser bekommt man leider die Inhalte der in dem Falle nicht relevanten Sidebar mit …
ließe sich da was machen?
Gruss, Connie