Inkonsistenzen
Hallo zusammen!
Ich bin neu hier auf der Mailingliste :)
Wie ihr an meiner Signatur sehen könnt, arbeite ich bei markt.de. Leider
haben wir im Moment eine ziemlich veraltete Geo-Datenbank, und sind auf
der Suche nach Möglichkeiten, wie wir sie kontinuierlich aktuell halten
können, auf die OpenGeoDb gestoßen.
Beim Versuch die DE.tab zu parsen und einen Objektbaum aufzubauen, habe
ich ein paar Inkonsistenzen entdeckt und dachte mir, dass ich die am
besten der Community mitteile. Schließlich ist das ein offenes Projekt,
das davon lebt, dass Leute, die es benutzen, ihre Erkenntnisse auch
wieder zurückgeben :)
Also hier sind meine Verbesserungsvorschläge:
- Der Datensatz mit der loc-id 23175 scheint irgendwie kaputt zu sein.
Meiner Meinung nach wäre es wohl am besten, ihn komplett aus der Tabelle
zu löschen. Eine Verbesserung wäre, zumindest "1" im Feld "invalid"
einzutragen.
- Das Feld "invalid" ist ein wenig inkonsistent befüllt. Offensichtlich
scheint "leerer String" und "0" zu bedeuten, dass der Datensatz valide
ist, "1" (und "null" bei Datensatz 23175), dass der Datensatz nicht
valide ist. Stimmt das soweit?
Allerdings gibt es Datensätze die aus der Reihe herausfallen: 153490,
153609 und 556 scheinen nicht valide zu sein, weil sie fast vollständig
leer sind, allerdings steht im invalid-Feld für diese Datensätze "0"
oder "". Sollten diese 3 Datensätze nicht eigentlich invalide sein, also
"1" in dem Feld stehen?
Es sollte auch in der Dokumentation ergänzt werden, dass in diesem Feld
nicht nur 1 und 0 stehen kann. Weil wenn man einen boolean erwartet, ist
man schon ein bisschen verwundert, wenn man plötzlich Felder mit leerem
String sieht.
- Das Feld loc_id sollte eigentlich eindeutig sein, es gibt aber zwei
Städte, die die selbe ID 153671 haben (Maria Veen und Rhedebrügge,
stehen in der DE.tab ganz unten). Das sollte auf jeden Fall schnell
bereinigt werden. Ich weiß nicht, wie andere das machen, aber meine
MySQL-DB hätte schon ganz gerne, dass der primary key auch eindeutig ist ;)
- Im Feld "einwohner" gibt es ein paar Einträge, die enthalten einen
Punkt, offensichtlich als Tausender-Trennzeichen.
Im Feld "flaeche" gibt es auch Zahlen, die einen Punkt enthalten. Hier
scheint es sich aber offensichtlich um ein Dezimalkomma zu handeln.
Das ist meiner Meinung nach gefährlich, weil man das nicht erwartet und
dann Fehler beim parsen macht. Auf die unterschiedliche Formattierung
sollte man auf jeden Fall in der Doku hinweisen. Noch besser wäre, die
Zahl mit deutschem locale zu formattieren, so dass ein Komma statt einem
Punkt beim Feld "flaeche" verwendet wird.
- Feld "level": Ich habe 2 Datensätze entdeckt, die ein komisches Level
haben: Die Orte 18048 und 35793 befinden sich auf dem Level "0" . Das
ist vermutlich falsch, da schon Deutschland auf Level 2 ist.
- Das Feld "of" sollte wohl eigentlich bei jedem Datensatz gefüllt sein
(da ja jedes Objekt einen parent hat) aber es gibt ein paar Datensätze,
da steht nichts in diesem Feld: 285, 278, 275, 190, 189, 187, 144602,
144600, 113129, 113126
- Bei diesen Einträgen in das Feld "typ" scheint derjenige, der das
eingetragen hat, nicht so genau gewusst zu haben, was in das Feld gehört:
- 100900000 (locid 81786 und 84968)
- 7 (locid 151792)
- 8 (locid 151794 und 151796)
So, ich hoffe ich kann damit ein bisschen dazu beitragen, dass die
Datenbank qualitativ besser wird :)
Viele Grüße
Julia Ilnseher
--
Julia Ilnseher | Softwareentwicklerin
markt.de GmbH & Co. KG
Nymphenburger Straße 14
80335 München
Tel: +49 89 878068 123
Fax: +49 89 878068 199
Geschäftsführer: Sang-Woo Pai
Sitz: München
Amtsgericht: München HRA 86724
--
--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)
RSS Feed