[opengeodb] Inkonsistenzen der Download-Daten

Die Mar 25 12:06:28 CET 2008

Andreas Müller wrote:
> 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.

Der zweite Blick hilft:

opengeodb.de: SF Projektseiten->OpenGeoDB

http://sourceforge.net/projects/opengeodb/ : Latest News:
	# Invitation for corrections    2007-11-07

http://sourceforge.net/forum/forum.php?forum_id=752450

Oder auf opengeodb.de über Wiki & News:

http://opengeodb.giswiki.org/wiki/OpenGeoDB

Aktuelles: 18-06-2007 opengeodb-wiki

> 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.

Auf SF muss man erheblichen Mehraufwand für neue releases treiben - und 
derzeit ist die gesamte Datenstruktur wieder etwas im Umbruch. Die 
SF-releases müssen nicht ganz so oft erfolgen, wenn man an anderer 
Quelle dumps aktueller, wenn nicht gar taggenau bekommen kann.

> 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.

ganz und gar nicht heisst?
Dhier.sql stammt vom 18. Dezember. Erst in den letzten  Tagen bekam ich 
den ersten konkreten Hinweis, was an diesen Daten falsch wäre.

Soll ich permanent neue Dumps erzeugen, wenn keiner sich die Daten ansieht?

> 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".

Der Fehler ist schon länger bekannt und wurde hier wiederholt diskutiert 
- eine tatsächliche, aktuelle Schwäche in BE, NL, CH, wo die korrekte 
Sprachinfo vereinfached und falsch auf de gesetzt wurde.

http://fa-technik.adfc.de/code/opengeodb.pl?locid=633;c=BE zeigt, dass 
die korrekte Sprach-Info aber in den Extra-Daten existiert.

Pragmatischer Vorschlag, an dem ich aktuell arbeite: reicht dir ein
DELETE FROM geodb_textdata 
VALUES(633,500100000,'Belgique','de',1,1,null,null,'3000-01-01',300500000);/* 
BE */

Wie lautet die korrekte Syntax für den DELETE-Befehl?
Dadurch werden die fehlerhaft konvertierten Basis-Daten gelöscht und 
durch die richtigen ersetzt:
Basis-Daten:
INSERT INTO geodb_textdata 
VALUES(633,500100000,'Belgique','de',1,1,null,null,'3000-01-01',300500000);/* 
BE - falsch*/
Extra-Daten:
INSERT INTO geodb_textdata 
VALUES(633,500100000,'Belgien','de',1,0,null,null,'3000-01-01',300500000);/* 
BE */
INSERT INTO geodb_textdata 
VALUES(633,500100000,'Belgique','fr',1,1,null,null,'3000-01-01',300500000);/* 
BE */
INSERT INTO geodb_textdata 
VALUES(633,500100000,'Belgium','en',0,0,null,null,'3000-01-01',300500000);/* 
BE */
INSERT INTO geodb_textdata 
VALUES(633,500100000,'België','nl',1,0,null,null,'3000-01-01',300500000);/* 
BE */
Extra-Daten-Korrektur:
DELETE FROM geodb_textdata 
VALUES(633,500100000,'Belgique','de',1,1,null,null,'3000-01-01',300500000);/* 
BE */

> 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?

War der je drin oder müssen wir den erst noch hinzufügen?

> 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

solche Abfragen helfen mir nichts, da ich keine SQL-Datenbank verwende. 
Bitte gib gleich das Resultat an, mindestens auszugsweise.

> 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.

Was hast du unternommen, um die Fehler zu korrigieren? Genau dafür steht 
ja eine Korrekturoberfläche zur Verfügung.

Es ist übrigens relativ normal, dass auf Ortsteil-Ebene der 
untergeordnete Teil die gleiche Ebene aufweist.

> 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.

Suche halt nicht in 500100000 sondern in 500100002

Beachte z.B. http://fa-technik.adfc.de/code/opengeodb.pl?locid=142002;c=DE
  "Brandis, Schweinitzer Fließ"
als Teil der Gemeinde "Schönewalde bei Herzberg, Elster", nicht aber in 
der Gemeinde "Schönewalde, Niederlausitz"

Sprich: es liegt wohl eher an deiner Abfrage als an den verfuegbaren Daten.

> 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.

Sieh dazu in die Archive - das wurde in diesem Jahr schon diskutiert. 
Ja, 500100002 sind meist redundante Daten.

Sobald mir jemand die entsprechenden SQL-Befehle mitteilt, die ich mit 
copy/paste in http://fa-technik.adfc.de/code/opengeodb/opengeodb-end.sql 
hinzufügen muss, um fehlende 500100002 passend zu berechnen, sobald 
fliegen redundante 500100002 raus.

Aktuelle Konvertierung:

  tr/a-zäöüáàâãåéèêëíìïïóòôõçñ/A-ZÄÖÜAAAAAEEEEIIIIOOOOCN/;
  tr/ÀÁÂÃÅÈÉÊËÌÍÎÏÒÓÔÕÇÑ/AAAAEEEEIIIIOOOOCN/;
  Ä -> AE
  Ö -> OE
  Ü -> UE
  ß -> SS
  SSS -> SS

Punkt und Bindestrich sind derzeit noch ebenso drin wie Leerzeichen. 
Hier wurde ueberlegt, diese wegzulassen. Die Frage ist, in was man "Alt 
Görlitz", "Alt-Görlitz" und "Altgörlitz" umwandeln moechte.

> 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.

Das kannst du für falsch halten und dennoch ist es so.

> 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.

Das sehe ich auch so. PLZ-Gebiete folgen einer völlig eigenen Logik. Ich 
experimentiere gerade damit, dass PLZ-Gebiete statt der 10080000 die 
10000000 bekommen und die 10090000 zur 10080000 wird (bzw. bleiben darf, 
weil sie irrtümlich ohnehin schon da liegt)

 > 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.

Nein, das ist keine Lösung. Was hilft dir, wenn du statt jeder PLZ in 
einem Ort statt dessen dir entsprechende 1:n-Beziehungen zu den 
PLZ-Gebieten aufbauen willst. Das hast du schon über die n PLZ-Einträge 
selbst. Ebenso hilft es wenig, alle m Orte mit gleicher PLZ über eine 
Relation zum PLZ-Gebiet zu verknüpfen - dort sind die Ortskoordinaten ja 
schon weit genauer als die Koordinate des PLZ-Gebiets. Ausserdem hat 
fast jeder größere Ort auch noch Ortsteile mit je einer oder mehrer PLZ.

Es ist offensichtlich, dass die PLZ-Problematik nicht mit der opengeodb 
vollständig in den Griff zu bekommen ist. Das geht nicht einmal dann, 
wenn wir mit der Genauigkeit auf Straßenebene angekommen sind - denn 
dafür benötigen wir die Genauigkeit jeder einzelnen Postadresse, jedes 
einzelnen Hauses. Dies aber sind Daten, die in Umfang und Genauigkeit 
der Post gehören und wo die Post der einzig richtige Ansprechpartner und 
Lieferant ist.

> 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.

Ja, es ist besser, solche Details in einzelnen E-Mails und damit 
getrennten Threads zu diskutieren, wo man schon alleine über den Titel 
erkennt, um was es geht.

> 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.

Persönlich habe ich nicht die geringste Lust, die Ortsnamen zu 
korrigieren - denn sie sind richtig und so wertvoller als 
verwechslungsträchtige Kurzformen.

Es stehen durchaus verschiedene Methoden zur Verfügung, wie du dir die 
Kurzformen ableiten kannst - z.B. indem du ab dem ersten 
kleingeschriebenen Wort den Rest wegwirfst, ebenso alles nach einem 
Komma, Schrägstrich oder Klammer. Wie du schon entdeckt hast, steht in 
500100002 genau das zur Verfügung, was du brauchst. Den Zusatzaufwand 
der Konvertierung kannst du entweder im Moment der Abfrage machen oder 
dir vorab eine Rückkonvertierung ausdenken, die über den ASCII-Teil dir 
den relevanten Teil der Kurzform zurückgibt.
Ebenso kannst du natürlich eine Wildcard-Suche verwenden, die dir alles 
liefert, was mit Brandis beginnt.

Beispiel:
http://fa-technik.adfc.de/code/opengeodb.pl?locid=20509;c=DE
Ort:  	Lutherstadt Eisleben
ASCII:  	EISLEBEN

Schönen Gruß
Martin