[opengeodb] Inkonsistenzen der Download-Daten

Die Mar 25 11:19:09 CET 2008

Hallo zusammen,

da das Wetter über Ostern so nett war hatte ich etwas Zeit mir die Daten mal
genauer anzusehen. Hier sind die Ergebnisse:

1. Download aktueller Daten
---------------------------
Auf <www.opengeodb.de> wird auf SourceForge für den Download der Daten
verlinkt. Dort findet man die Version 0.2.5a vom 04.10.2007. Diese ist zum
einen nicht aktuell noch werden die Dumps für "geodb_hierarchies"
bereitgehalten. Einen Verweis auf die inoffizielle offizielle Downloadseite
<http://fa-technik.adfc.de/code/opengeodb/> konnte ich nirgends auf den
ersten Blick entdecken. Meiner Meinung nach wäre es doch besser die Daten
aktuell und komplett auf SourceForge bereitzustellen wenn dieses schon als
offizieller Download-Link angegeben ist.

2. Inkonsistenz Daten und *hier.sql
-----------------------------------
Nach dem download der aktuellen Daten (opengeodb-02612_2008-01-21.sql.gz)
testete ich ob die Aussage stimmt das parallel zu den aktuellen Daten auch
passende *hier.sql Dateien bereitgestellt werden. Das Dateidatum ist da ja
nicht unbedingt ausschlaggebend *hier.sql Dateien können ja noch von älteren
Versionen passen wenn keine loc_id's dazukommen oder wegfallen und sich nur
Inhalte ändern. Nun die aktuell Verfügbaren *hier.sql Dateien
(17.-18.12.2007 passen nun aber ganz und gar nicht zu den aktuellen Daten.
Ich hatte es befürchtet ...

3. Bezeichnung für Belgien offensichtlich falsch
------------------------------------------------
Eine Abfrage für Belgien "select * from geodb_textdata where loc_id=633"
fördert einen offensichtlichen Fehler zu Tage:
"Belgique" ist sicherlich nicht der default_name in der text_locale="de".

4. Fehlende Daten
-----------------
Um das Problem zu umschiffen wollte ich nur noch die ISO 3166 Codes der
Länder haben. Bei der Abfrage nach Ländern musste ich feststellen das der
Typ 500100001 (ISO 3166 Alpha-2) nicht in den Daten enthalten ist. Ist das
Absicht?

5. Aufbau einer eigegen "geodb_hierarchies"
-------------------------------------------
In Ermangelung einer verfügbaren "geodb_hierarchies" Tabelle musste ich mir
diese also selbst bauen. Dabei bin ich auf folgende Probleme gestoßen:

5.1. Fehlender Hierarchie Referenzen
------------------------------------
Normal sollte es keine loc_id ohne level (400200000) geben und falls eine
übergeordnete loc_id angegeben ist sollte diese auch existieren. Tut es
nicht immer wie folgende Query auf den aktuellen Daten (siehe oben) zeigt:

select a.loc_id
from geodb_textdata a
left join geodb_textdata b on b.loc_id=a.text_val and b.text_type=400200000
where a.text_type=400100000 and a.text_val<>'-1'
and b.loc_id is null

5.2. Falsche Level
------------------
Normal sollte in einer Hierarchie auch jeder Parent einen (in dem Fall)
niedrigeren Level-Wert haben. Nachdem ich in meiner selbst erzeugten
"geodb_hierarchies" Tabelle ein paar ungereimtheiten gefunden habe hab ich
das mal genauer untersucht und bin z.B. auf das hier gestoßen:

select a.loc_id,b.text_val lvl,c.text_val parent_lvl
from geodb_textdata a
inner join geodb_textdata b on b.loc_id=a.loc_id and b.text_type=400200000
inner join geodb_textdata c on c.loc_id=a.text_val and c.text_type=400200000
where a.text_type=400100000
and b.text_val<=c.text_val

Diese Abfrage liefert loc_id's deren Parent loc_id den gleichen oder einen
größeren Level hat also die loc_id selbst.

6. Ortsnamen
------------
Eigentlich hatte ich ein ganz einfaches Ziel: Eine Liste von Orten und deren
Postleitzahlen und Vorwahlen um diese Daten in einem Warenwirtschaftssystem
zur Adresseingabeverbesserung heranzuziehen. Sollte ja nachdem man obige
Probleme gelöst hat machbar sein.

Nun wohne ich in der kleinen Stadt Brandis - was liegt da näher sich selbst
einmal zu suchen:

select * from geodb_textdata where text_type=500100000 and
text_val='Brandis' 

Komisch nur das das Ergbnis leer war. Also mal global nur nach dem text_val
gesucht und nach etwas hin und her hatte ich es raus: "Brandis bei Wurzen"
steht in der Datenbank. Nun gut ein Blick auf meinen Perso und eine
Rückfrage heute bei der Stadt ergab: Der hochoffizielle Name meiner Stadt
ist "Brandis" - und nix mit "bei Wurzen". Nachdem ich das gleiche mit meiner
Geburtsstadt "Plauen" und in ähnlicher weise bei meinem im Moment oft
Besuchten Kundenort "St. Ingbert" (ich habe mich heute früh herzlich gelacht
als ich den Thread gelesen habe) versucht habe und jedesmal auf die Nase
gefallen bin habe ich es erstmal aufgegeben.

Um es auf den Punkt zu bringen: Nach Aussage der Stadtverwaltung Brandis
hiess Brandis schon immer Brandis ohne jeden Schnörkel. Diese Zusätze haben
sich irgendwann einmal Kartographen einfallen lassen um in
Ortsverzeichnissen die Stadt Brandis vom dem Ortsteil Brandis von
Schönewalde unterscheiden zu können - entbehrt aber jeder Amtlichkeit.
Ähnliches habe ich bei kurzen Telefonaten mit Plauen und St. Ingbert
erfahren.

Hier sollte dringend etwas getan werden denn so sind die Daten für viele
Anwendungsfälle unbrauchbar. Vermutlich sollte man hier die Namen
austauschen. Die Prosa-Namen (nenne ich sie mal) müssen ja nicht
verschwinden - aber an ihre heutige Stelle (500100000) sollte warscheinlich
die Datenbasis für text_type=500100002 - denn das scheint so gut wie immer
zu stimmen. Nur gibt es diesen Inhalt nicht in originaler schreibweise in
den Daten.

7. Suchname
-----------
Für mich ist es fragwürdig ob ein text_type=500100002 überhaupt in die Daten
gehört. An sich ist das ja redundant da jeder sich seine Suchvereinfachung
selbst bauen kann. So verwende ich z.B. in meine Datenbanken bisher die
Kleinschreibungsvariante ohne Sonderzeichen (wie Punkt, Komma, Bindestrich)
aber mit exakt einem Leerzeichen zwischen Worten. Damit fallen bei mir
mehrere Worte in der Suche nicht zwingend zusammen.

8. Postleitzahlgebiete vs. mehrer PLZ an der Ortschaft
------------------------------------------------------
Ich halte es für falsch einem Ort mehrer Postleitzahlen (also reelle PLZ,
keine PF-PLZ) zuzuordnen statt ihn mehrere Postleitzahlgebiete zu verpassen.
Es gibt durchaus PLZ genaue Koordninaten und dann sollte man diese auch
erfassen können. Problematisch wird das ganze aber erst recht noch wenn man
PLZ Shapes verwalten will. D.h. meiner Meinung nach sollten die PLZ Gebiete
NICHT Bestandteil der normalen Hierarchie sein. Vielmehr muss man in einer
n:m Zuordnung die PLZ Träger mit den PLZ Gebieten verknüpfen können - anders
ist die Komplexität nicht lösbar und behindert auch die Einbindung weiterer
Daten.

Epilog
------
Ich bin bei meinen Analysen noch ganz weit oben an der Oberfläche geblieben.
Ein paar Details habe ich noch mehr entdeckt aber das würde hier erstmal den
Rahmen sprengen. Wenn die o.g. Probleme behoben sind und vor allem die
Ortsnamen stimmen kann ich weitere Analysen fahren und die Daten auch mal
gegen andere Datenbestände gegenfahren um Vollständigkeiten und
Genauigkeiten zu prüfen. Das ganze werde ich gern tun und auch bald eine
Möglichkeit anbieten die Daten via Online Service aufbereitet abzufragen.

Gruß,
Andreas