Ort anhand der PLZ füllen - ?OpenGeoDB?

[baumina]

Ich habe ein Adressverwaltungsprogramm (DB ist mySQL), welches ich nun insofern erweitern soll, dass bei Eingabe der PLZ der Ort automatisch gefüllt werden soll.

Meine Recherchen bezüglich der Datenverfügbarkeit PLZ/Ort haben mich zu OpenGeoDB geführt. Doch irgendwie blicke ich da noch nicht so richtig durch.

- Macht es nun Sinn für mich, eine neue Datenbank für die OpenGeoDB auf meinem mySQL-Server anzulegen und einen Dump einzulesen? (Viele Daten von denen ich die meisten im Moment gar nicht brauche. Aber dann wäre ein Update der Daten einfacher?)
- Oder ziehe ich mir nur die Textdatei plz.tab (oder nur PLZ und Ort) in eine neue Tabelle meiner vorhandenen DB? (dann könnte ich die Daten nicht vernünftig updaten?)
- Oder gäbe es da auch eine Delphi-Komponente, die mir den Ort ausm Internet holt?

Sicherlich hat der ein oder andere von euch sich mit dem Thema schon mal auseinandergesetzt und kann mir dazu wertvolle Tipps geben.

Danke im Voraus

[nahpets]

Hallo,

hab' mir die Datei PLZ.tab gerade mal angeschaut.

Würde hier eine eigene Tabelle in meiner DB anlegen und die Textdatei importieren.
Beim Update ein Truncate auf die eigene Datenbanktabelle und anschließend eine neue PLZ.tab einlesen. (Bei fremden Daten immer alles Eigene wegwerfen und vollständig neu einlesen. - Eine "eigene" Pflege der Tabelle PLZ.tab muss dann aber zwingend unterbleiben.)

Wenn die Tabelle dauerhaft unter http://fa-technik.adfc.de/code/opengeodb/PLZ.tab (oder wo sonst auch immer) zu erreichen sein sollte, ließe sich das Update per tIDHTTP... automatisieren.

Im Programm könnte man die "eigene" Datenbanktabelle für PLZ.tab als Nachschlagtabelle hinter das Postleitzahlenfeld legen.
Mit einer TDBLookupComboBox wäre das recht einfach zu lösen, man hat dann nach der Eingabe einer PLZ automatisch den Ort dazu.

Die PLZ.tab scheint aber keine Postfachpostleitzahlen zu enthalten, hier würde ein Nachschlagen daher nicht funktionieren. Wäre das bei Deinem Programm erforderlich?

[baumina]

Danke dir nahpets. Ja, deine vorgeschlagene Vorgehensweise war auch mein erster Gedanke. Aber ich weiß eben nicht, ob diese Datei immer dort zum download liegt und immer genau so heißt und immer dieselbe Struktur hat. Ist das UTF-8? Sieht in meinem Windows so komisch aus.

Zitat:

Zitat von nahpets (Beitrag 1227967)

Die PLZ.tab scheint aber keine Postfachpostleitzahlen zu enthalten, hier würde ein Nachschlagen daher nicht funktionieren. Wäre das bei Deinem Programm erforderlich?

Ah, das ist mir noch gar nicht aufgefallen, denke darauf kann ich aber auch verzichten.

[nahpets]

Hallo,

das scheint kein UTF8 zu sein, sondern eine reine Textdatei, mein Editor kommt jedenfalls mit den Umlauten klar, also ein Windowszeichensatz.

Naja, ob die Datei immer da liegt und immer die gleiche Struktur haben wird und immer in der Struktur unverändert bleiben wird? Nix genaues weiß man nicht.

Eine eigene Datenbanktabelle hätte dann aber den Vorteil, Du könntest aus Daten einer anderen Quelle durch eine neue Importroutine Deine bisherige Tabelle befüllen und müsstest dann im Programm und im Datenbankschema nichts ändern. Außerdem müsstest Du dann nur die tatsächlich von die benötigten Daten einlesen, kannst also alle Spalten der PLZ.tab verwerfen, die Du nicht benötigst.

Beim Einlesen eines Dumps bekommst Du automatisch neue oder veränderte Strukturen und musst dann Programm und/oder Datenbankroutinen ändern und ggfls. alles ausliefern.

Eine veränderte Textdatei führt zu weniger Aufwand, da nur Einlesescripte bzw. Konvertierroutinen geändert werden müssen.

Hier ist eine weitere Quelle für die Tabelle http://www.manfrin-it.com/postleitzahlen/plz.html

Falls Du in einer anderen Quelle noch Postfachpostleitzahlen mit Orten finden solltest, könntest Du die Daten auch in einer Tabelle zusammenfügen, was bei einem Dump nicht möglich ist.

Bei mehreren Quellen in einer Datenbanktabelle könntest Du noch ein Feld "Quelle" in Deine Tabelle einfügen und dieses zusammen mit den Daten befüllen, dann kannst Du bei einem Update ein Delete from Tabelle where Quelle = 'Lieferant' machen und anschließend neu einlesen.

Vermutlich bist Du mit dem Einlesen von Textdateien auf Dauer flexibler, als mit dem Einlesen von Datenbankdumps und kannst mit weniger Aufwand auf "externe" Änderungen reagieren.

Bei einem Dump bist Du darauf angewiesen, dass er für "Deine" Datenbank zur Verfügung steht. Wenn Du nun (warum auch immer) von MySQL auf PostGres, Oracle, FireBird... wechselst, bekommst Du garantiert erstmal ein Problem, mit Einleseroutinen für Textdateien musst Du "nur" die Datenbankverbindung ändern und schon ist diese Aufgabe erledigt (ok, könnte ein bisserl mehr werden, aber sicherlich weniger, als nötigenfalls zwei Datenbanken zu unterstützen, eine für Deine Daten und eine für die Postleitzahldaten.)

[BUG]

Zitat:

Zitat von baumina (Beitrag 1227973)

Ist das UTF-8?

Zumindest Firefox sagt UTF-8. Sieht aus wie CSV mit Tabs als Trenner; ich denke nicht, dass die an der Struktur allzu-viel ändern.

Zitat:

Zitat von nahpets (Beitrag 1227983)

das scheint kein UTF8 zu sein, sondern eine reine Textdatei

Öhm ... UTF-8 ist eine Zeichencodierung, die in "reinen" Textdateien benutzt wird; normaler geht es kaum :gruebel:

Die flexibelste Lösung wäre es, wenn du die Daten in einem bestimmten Format auf deinem eigenen Server bereitstellst und damit die Herkunft der Daten einfach ändern kannst ohne den Klienten anzufassen.
Zudem könntest du Daten aus verschiedenen Quellen zusammenführen und die Server der Quellen würden entlastet.

[p80286]

Falls Du die GroßkundenPLZ benötigst, schau mal hier rein

Gruß
K-H

[nahpets]

Hallo ,
@BUG

Zitat:

Zitat von BUG (Beitrag 1227984)

Zitat:

Zitat von nahpets (Beitrag 1227983)

das scheint kein UTF8 zu sein, sondern eine reine Textdatei

Öhm ... UTF-8 ist eine Zeichencodierung die in "reinen" Textdateien benutzt wird, normaler geht es kaum :gruebel:

Jaja, hast recht, habe mich (mal wieder) unpräzise ausgedrückt.
Ja, hast recht, ist UTF8, wußte garnicht, dass per Copy&Paste von Firefox nach Uralteditor konvertiert wird, ohne dass man das mitkriegt.

Reine Textdatei ist für mich sowas wie Zeichensatz für MS-Dos(e) oder Ansi ;-)

@baumina

Zitat:

Zitat von p80286

Falls Du die GroßkundenPLZ benötigst, schau mal hier rein

Mit den hier genannten Quelle kannst Du Dir eine (fast) vollständige Nachschlagtabelle bauen, aus der PLZ.tab die Spalten 2 und 5, aus der plz_gross.txt die Spalten 1 und 2.
Die Grosskundentabelle der UNI-Mainz ist vom 01.12.1993, also nicht zwingend aktuell.

Hiermit bist Du mit einer eigenen Datenbanktabelle und eigenen Einleseroutinen flexibler als mit Datenbankdumps für die PLZ.tab...

Wir bedienen uns bei Oracle immer des SQL-Loaders. Die Quelldaten werden per FTP von verschiedenen Quellen gezogen und alles per Script verarbeitet.

Bei Änderung der Quelladresse muss nur die FTP-Verbindung geändert werden, bei Änderungen an der Datenstruktur werde die SQL-Loaderscripte geändert. In der Regel sind die Änderungen in wenigen Minuten erledigt und wir müssen nur die Daten übernehmen, die wir benötigen und nicht in episch gelieferter Breite.

[blondervolker]

Hallo,

solltest noch suchen...
http://www.datendieter.de/item/Postl...te_Deutschland:-D

[p80286]

Zitat:

Zitat von nahpets (Beitrag 1227990)

Die Grosskundentabelle der UNI-Mainz ist vom 01.12.1993, also nicht zwingend aktuell.

Da die Beziehung zwischen PLZ und Ort gesucht wird, sollte es ausreichend sein. Soweit ich weiß gibt es für Großkunden und Postfächer feste Bereiche. Falls also die PLZ für die Wohnort Bestimmung genutzt werden soll, könnten sie ausreichen oder aber eine Warnung "keine echte PLZ" generieren. Je nach dem was man braucht. ggf. wäre es in der Vergleichstabelle sinnvoll einen Typen für die PLZ zu speichern 1=StraßenPLZ 2=Postfachplz 3=GroßkundenPLZ.

Gruß
K-H

[Der.Kaktus]

Zitat:

Zitat von blondervolker (Beitrag 1227992)

Hallo,

solltest noch suchen...
http://www.datendieter.de/item/Postl...te_Deutschland:-D

bisl sehr alt ;-)..ich hab sowas mal gemacht vor paar Jahren ..wir hatten in der Firma als Quelle immer die Aktuelle CD http://www.deutschepost.de/dpag?xmlF...nk1015592_1041

Da gibts CSV Datei..einfach in eine Datenbank zu uebernehmen und vorallem AKTUELL :-D

[nahpets]

@p80286

Zitat:

Zitat von p80286 (Beitrag 1227995)

Da die Beziehung zwischen PLZ und Ort gesucht wird, sollte es ausreichend sein. Soweit ich weiß gibt es für Großkunden und Postfächer feste Bereiche. Falls also die PLZ für die Wohnort Bestimmung genutzt werden soll, könnten sie ausreichen oder aber eine Warnung "keine echte PLZ" generieren. Je nach dem was man braucht. ggf. wäre es in der Vergleichstabelle sinnvoll einen Typen für die PLZ zu speichern 1=StraßenPLZ 2=Postfachplz 3=GroßkundenPLZ.

Prinzipiell hast Du da Recht, eigentlich müsste es reichen, nach Postleitzahlbereichen zu suchen.

Die Postleitzahlen für Leipzig (Straße-, Postfach- und Großkundenpostleitzahl) dürften z. B. von bis 04000 bis 04399 reichen.

Wenn's was kosten darf, dann ist die Post mit ihren Daten sicherlich immer die erste und beste Quelle.

[zeras]

Zitat:

Zitat von nahpets (Beitrag 1227967)

Wenn die Tabelle dauerhaft unter http://fa-technik.adfc.de/code/opengeodb/PLZ.tab (oder wo sonst auch immer) zu erreichen sein sollte, ließe sich das Update per tIDHTTP... automatisieren.

Dort stehen aber nicht alle Orte drin. Meinen Ort kann ich unter meiner PLZ nicht finden. Es wird ein größerer Ort ca. 15 km entfernt gezeigt.
Aber besser als gar nichts.

[Furtbichler]

Denkt daran, das es zu einer PLZ mehrere Orte geben kann.

Da sich PLZ nicht so oft ändern, wäre es sinnvoll, die Daten in der DB vorzuhalten. Ich halte nicht viel von diesem Stückelzeugs, wo man sich die Daten zusammensuchen muss. Ein Fehler, und sei es eine defekte Datei, und das ganze System spinnt, bzw. eben nicht und bombt irgendwann aus. Dann doch lieber alles in einer DB, wo die Integrität zudem gewährleistet ist.

[baumina]

Zitat:

Zitat von zeras (Beitrag 1228007)

Dort stehen aber nicht alle Orte drin. Meinen Ort kann ich unter meiner PLZ nicht finden. Es wird ein größerer Ort ca. 15 km entfernt gezeigt.
Aber besser als gar nichts.

Also wenn man unter bearbeiten der Datenbestände sucht, ist dein Ort bestimmt dabei. Irgendwie scheint die PLZ.tab der OpenGeoDB alleine nicht ausreichend zu sein.

Zitat:

Zitat von nahpets (Beitrag 1228001)

Wenn's was kosten darf, dann ist die Post mit ihren Daten sicherlich immer die erste und beste Quelle.

Ich befürchte kosten darfs nix :(

[zeras]

Zitat:

Zitat von baumina (Beitrag 1228046)

Zitat:

Zitat von zeras (Beitrag 1228007)

Dort stehen aber nicht alle Orte drin. Meinen Ort kann ich unter meiner PLZ nicht finden. Es wird ein größerer Ort ca. 15 km entfernt gezeigt.
Aber besser als gar nichts.

Also wenn man unter bearbeiten der Datenbestände sucht, ist dein Ort bestimmt dabei. Irgendwie scheint die PLZ.tab der OpenGeoDB alleine nicht ausreichend zu sein.

Ja, unter dem Ort kann ich dann meine PLZ finden.

[nahpets]

Zitat:

Zitat von baumina (Beitrag 1228046)

Also wenn man unter bearbeiten der Datenbestände sucht, ist dein Ort bestimmt dabei. Irgendwie scheint die PLZ.tab der OpenGeoDB alleine nicht ausreichend zu sein.

Wenn man diesem Link folgt, sieht man unten, unter den Eingabemöglichkeiten, einen Link Dateien. Dem kann man folgen und bekommt eine Liste der verfügbaren Dateien, dies sind einige Datendateien und etliche SQL-Scripte. Unter Anderem findet man dort die DE.tab. Diese enthält auch den "vermissten" Ort. Sie hat aktuell den Stand vom 8.9.2013. Allerdings scheint sie unter Postleitzahlenkriterien nicht vollständig zu sein. Mein Wohnort hat mehrere Postleitzahlen, in dieser Datei ist aber nur eine dieser Postleitzahlen zu finden.
Meine Vermutung ist momentan: Die Datei DE.Tab enthält alle Orte mit ihrer "Hauptpostleitzahl", während die PLZ.tab alle weiteren Postleitzahlen zu den Orten enthält. Es wird also für eine Nachschlagtabelle eine Kombination aus diesen beiden Dateien benötigt.

Schaut man sich alle Dateien unter o. g. Link an, so findet man (vermutlich) die vollständigen Scripte, um sich eine MySQL-Datenbank aufzubauen (einschließlich der Create-Table...-Statements) und kann sich damit seine eigene OpenGeoDB erstellen.

[baumina]

Danke an Euch alle, die sich mit mir den Kopf zerbrochen haben und für die, die eine ähnliche Lösung suchen.

Meine Lösung sieht nun folgendermaßen aus:

Ich habe beschlossen die gesamte OpenGeoDB via Dump als eigene DB in mein mySQL zu nehmen. Mein select, um den Ort via PLZ zu suchen sieht folgendermaßen aus:

SQL-Code:

SELECT Ort.text_val
  FROM opengeodb.geodb_textdata PLZ
  JOIN opengeodb.geodb_locations LPLZ
    ON (PLZ.loc_id = LPLZ.loc_id)
  JOIN opengeodb.geodb_hierarchies HPLZ
    ON (PLZ.loc_id = HPLZ.loc_id)
  JOIN opengeodb.geodb_textdata Ort
    ON (PLZ.loc_id = Ort.loc_id)
  JOIN opengeodb.geodb_textdata Land
    ON (HPLZ.id_lvl2 = Land.loc_id)
 WHERE PLZ.text_val = '<gesuchte PLZ>'
   AND Land.text_val = '<gesuchte Länderkennung>' // D(Deutschland), A(Österreich), CH(Schweiz), B(Belgien), FL(Lichtenstein)
   AND Ort.text_locale = 'de' // deutscher Name des Ortes
   AND PLZ.text_type = 500300000 // 500300000=PLZ
   AND LPLZ.loc_type = 100600000 // 100600000=Politische Gliederung (weil ich die ganzen Teilorte nicht haben mag) ansonsten 
                                 // 100800000=Postleitzahlgebiet mit allen Teilorten
   AND Ort.text_type = 500100000 // 500100000=Ortsname
   AND Land.text_type = 500500000 // 500500000=Länderkennung 
 ORDER BY Ort.text_val;

[mquadrat]

OpenGeoDB ist immer so ein Thema. Theoretisch steht alles drin, aber teilweise auch einfach doppelt und manchmal in der falschen Hierarchieebene. Mein Favorit ist der Eintrag "überhprüft das eigentlich irgendwer".