⬅ Zurück zur Übersicht

OpenGeoDB Hürden

david am Sonntag, 25.03.2018 - 14:54:05
⬅ Zurück zur Übersicht

Vorüberlegungen

Für ein aktuelles Projekt habe ich eine Liste mit allen Postleitzahlen in Deutschland inkl. zugehöriger Städtenamen gebraucht. Es gilt zwar „Je mehr Daten desto besser“ 😉 aber das waren zumindest die notwendigen Mindestanforderungen. Am Ende sollte ein Autocomplete – Input rauskommen bei dem wir PLZ und zugehörigen Ort angezeigt bekommen. Erste Aufgabe ist also das Besorgen der Daten, und Mr. Google hat mich auf das ziemlich vielversprechende Projekt OpenGeoDB gebracht.
Hier werden wirklich alle erdenklichen Daten zu einem Ort geliefert, die man sich wünschen könnte:

Es war also recht schnell klar, dass ich hier die Daten bekomme welche ich brauche.
Los ging es also mit dem Download der Daten als SQL – Dump.
Interessanterweise gibt es hier 3 Dateien:

Das Grundgerüst

Wir fangen entsprechend als erstes mit der opengeodb-begin.sql an um das Grundgerüst zu erstellen. Hier treffen wir auf die Hürde aka den Fehler Nummer 1.

[FEHLER in Abfrage 3] You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ‚TYPE=InnoDB CHARACTER SET utf8‘ at line 10

TYPE=InnoDB kennt die Datenbank also nicht. Schade. Liegt aber daran, dass der Dump mit einer Version vor MySQL 4 erstellt wurde. Seit MySQL 4 hört die Datenbank nicht mehr auf TYPE, sondern auf ENGINE.

Lösung also: Dump im Editor seiner Wahl öffnen und „TYPE=InnoDB“ ersetzen durch „ENGINE=InnoDB“.
Dump erneut importieren und sich am erfolgreichen Import erfeuen.

Der Datensatz

Weiter geht’s mit dem Datensatz. Dazu einfach die Datei DE.sql (gilt natürlich nur für Deutschland. Österreicher nehmen die AT.sql, Schweizer die CH.sql etc.) importieren und warten… warten… bis die etwa 600.000 Datensätze importiert wurden … und dann die Fehlermeldung erhalten, dass 0 kein Datum ist (.. tatsächlich?)

Incorrect date value: ‚0‘ for column ‚valid_since‘ at row 1

Das warten war umsonst. Yeah.
Tabelle also wieder leeren und überlegen, was schief gelaufen ist.
Grundsätzlich bin ich davon ausgegangen, dass die Daten von OpenGeoDB an sich korrekt sind und es an meiner MySQL Konfiguration liegt, welche einfach keine 0 zulässt. Vielleicht sollte meine Datenbank da nicht ganz so streng sein und ausnahmsweise trotzdem die 0 zulassen generell eine 0 als Datum zulassen*. Das MySQL Manual brachte mich auf die Variable strict_mode, welche mit einem kurzen

1
SHOW VARIABLES LIKE 'sql_mode'

ausgelesen werden konnte und mir ein

ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION

zurückgegeben hat. Hier musste also das „NO_ZERO_IN_DATE,NO_ZERO_DATE“ weg, und da das ganze persistent geschehen sollte wurde eben die my.cnf konfiguriert, welche bei mir unter /usr/local/etc/my.cnf zu finden war. Dort musste ein

1
sql_mode = ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION

angehängt (= Ausgabe von SHOW VARIABLES ohne die Werte NO_ZERO_IN_DATE und NO_ZERO_DATE) und der Server mit einem freundlichen

1
brew services restart mysql

neugestaret werden. Danach nochmal mit „SHOW VARIABLES LIKE ’sql_mode'“ den Zustand prüfen und schauen, ob alles geklappt hat.
Es wird Zeit für einen neuen Versuch – DE.SQL importieren und warten. Diesmal sollte alles klappen 🙂

Finishing

Schritt 3 ist das Importieren der opengeodb-end.sql, welche das „Finishing“ durchführt – Titel einfügen und Indizes erstellen. Hier lief alles fehlerfrei ab *puh*
Jetzt sind die Daten importiert und können verarbeitet werden.

* Wer die Änderungen nur temporär will, kann das mit einem

1
set global sql_mode='ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION'

bewirken.

TL;DR

  1. Datensätze von http://opengeodb.giswiki.org/wiki/OpenGeoDB_Downloads herunterladen: opengeodb-begin.sql, opengeodb-end.sql, DE.sql
  2. opengeodb-begin.sql im Editor öffnen und TYPE=InnoDB mit ENGINE=InnoDB ersetzen
  3. opengeodb-begin.sql importieren
  4. sql_mode=’ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION‘ ausführen
  5. DE.sql importieren
  6. opengeodb-end.sql importieen
Kommentar schreiben

Kommentare