[opengeodb] Inkonsistenzen der Download-Daten

Die Mar 25 13:23:21 CET 2008

Hallo Martin,

nun dann versuche ich mal zu antworen:

> > 1. Download aktueller Daten
> Der zweite Blick hilft:
...

Der Hilft mir vielleicht aber keinem neuen. Entdecke ich heute opengeodb
dann habe ich ein Problem die richtigen Daten zu finden. Und das einchecken
eines Archives in SF ist nun nicht so aufwendig. Oder entfernt einfach die
offiziellen Downloadverweise und setzt sie auf die aktuelle Lokation - nur
das alte zu verlinken und das neue irgendwo zu verstecken ist nicht so
schön.

> > 2. Inkonsistenz Daten und *hier.sql
> > -----------------------------------
> 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?

Nun von der Dezemberversion zur Januar Version scheint sich einiges auch an
den loc_id's getan zu haben. So sind etliche tausend loc_id's dazugekommen
und deren Referenzen fehlen eindeutig in den alten *hier.sql Dateien. Und
nein du sollst nicht permanent neue Dumps erzeugen sondern nur dann wenn bei
einem neuen Datenrelease neue loc_id's hinzugekommen sind, loc_id's gelöscht
wurden oder sich Änderungen in deren Hierarchie ergeben haben.

Um 1. und 2. zusammenzufassen: Ich wäre hier ganz faul. Ich würde mir ein
Script bauen welches aus meinen internen Daten den Export für SQL erzeugt
und zwar immer komplett also mit *hier.sql Dateien. Diese würde ich per
Script zu einem ZIP Archiv packen, per Script in den SF CVS Server
einchecken und per Script auf den Downloadbereich hochladen. Das baut man
genau ein einziges mal - vor allem der letzte Teil des packens und
hochladens ist immer gleich.

> > 3. Bezeichnung für Belgien offensichtlich falsch
> > ------------------------------------------------
> 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.
>..

Der korrekte Syntax für das Löschen wäre:

DELETE FROM textdata WHERE loc_id=633 AND text_type=500100000 AND
text_val='Belgique', ....

Aber blöde Frage: Warum muss man das patchen und kann es nicht direkt
beheben? Wenn das Problem schon länger bekannt ist wo ist dann das Problem
die locale Zuordnung zu den native language names zu korrigieren?

> > 4. Fehlende Daten
> > -----------------
> War der je drin oder müssen wir den erst noch hinzufügen?

Also laut Doku sind sie Daten drin. Ansonsten würde ja auch der Typ
500100001 keinen Sinn machen. Das sind nicht viele Datensätze - die sollten
sich ja wohl einfügen lassen.

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

Nun dann hier mal die Ergebnisse:

23356
23717
23735
23827
23973
24178
80596
80598
80599
80601
80602
80603
80604
80605
80606
80607
80608

> > 5.2. Falsche Level
> > ------------------
> 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.

Auch hier erstmal die Ergebnisse:

26723;8;8
26724;8;8
26725;8;8
26726;8;8
26727;8;8
26728;8;8
26729;8;8
26730;8;8
26731;8;8
26732;8;8
14423;8;8
15134;8;8
17177;8;8
17900;8;8
23754;8;8
26041;8;8
15949;8;8
27059;8;8
27058;8;8
27210;8;8
27177;8;8
27111;8;8
27109;8;8
35736;8;8
35738;8;8
35737;8;8
35739;8;8
22122;8;8
24784;8;8
27453;8;8
27471;8;8
27478;8;8
27499;8;8
27535;8;8
27545;8;8
27519;8;8
27530;8;8
27466;8;8
27498;8;8
26821;8;8
26832;8;8
27374;8;8
27370;8;8
27371;8;8
27379;8;8
27373;8;8
27372;8;8
27382;8;8
26649;8;8
16935;8;8
18609;8;8
20256;8;8
21016;8;8
21434;8;8
22735;8;8
35797;8;8
35801;8;8
35810;8;8
35802;8;8
21112;8;8
35818;8;8
35843;8;8
35844;8;8
35848;8;8
35845;8;8
35846;8;8
35847;8;8
35849;8;8
35850;8;8
35763;8;8
35765;8;8
35757;8;8
35756;8;8
111325;8;8
111326;8;8
112668;8;8
112669;8;8
112670;8;8
82151;8;8
82153;8;8
82152;8;8
82154;8;8
82156;8;8
82155;8;8
141874;8;8
141875;8;8
142007;8;8
142161;8;8
142192;8;8
142193;8;8
142196;8;8
142206;8;8
142207;8;8
142484;8;8
142624;8;8
142625;8;8
142626;8;8
142623;8;8
142627;8;8
80621;5;5

Unternommen habe ich garnichts da ich ja fachlich nicht in der Lage bin den
Umstand zu klären. Mir ist es nur bei der Prüfung der Datenbank aufgefallen.
Die Frage die sich hieraus ergibt ist wie man das eingentlich in der
"geodb_hierarchies" Tabelle abbilden soll - denn so geht das dort nicht.

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

Nein du siehste das etwas falsch. Ich habe dazu geschrieben wozu ich die
Daten brauche - als Eingabehilfe für Adresseingaben. Ich will nicht nur nach
einem Ort suche und dessen PLZ finden sondern ich will auch wenn jemand eine
PLZ eingibt den richtigen Ort auswählbar haben. Dazu ist es notwendig das
man auch die richtige Ortsbezeichnung in der Datenbank hat. Als Ergebnis für
ein PLZ Lookup nach "04821" ist "Brandis bei Wurzen" für eine
Adresseingabeunterstützung unbrauchbar. Ganz abgesehen davon das der Name
"Brandis bei Wurzen" eine Erfindung ist.

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

Nun das weglassen des Typ 500100002 nützt ja im Moment nicht viel da dessen
Grundlage nicht veröffentlicht wird. Siehe auch 6.
Sobald die Grundlage veröffentlicht wird könnte der Typ entfallen denn hier
brauch jeder vielleicht eine andere "Normalisierung". Siehe dazu mein
Beispiel das komplett anders arbeitet als der Ansatz hier.

Per SQL könnte man mehrere Statements verwenden:

UPDATE geodb_textdata SET text_val=replace(text_val,'Ä','AE');
...

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

Nach meinem System das sich schon etliche Jahre bewährt hat würde da
folgendes rauskommen:

"Alt Görlitz" -> "alt goerlitz"
"Alt-Görlitz" -> "alt goerlitz"
"Altgörlitz"  -> "altgoerlitz" 

Nun normalisiere ich in 2 Schritten:
1.: nur Trennzeichen in Leerzeichen wandeln, Umlaute normalisieren, doppelte
Leerzeichen entfernen
-> suchen
falls kein Treffer:
2.: via iteration nach und nach leerzeichen entfernen und alternative
schreibweisen checken (z.B. St. -> Sankt)

In Wahrheit baue ich mir heute eine Suchliste bei der Normalisierung auf die
Eintrag für Eintrag abgearbeitet wird. Immer davon ausgegehen der der
Benutzer schon treffende Eingaben gemacht hat.

> > 8. Postleitzahlgebiete vs. mehrer PLZ an der Ortschaft
> > ------------------------------------------------------
> Das kannst du für falsch halten und dennoch ist es so.

D.h. ja aber nicht das man es nicht ändern kann bzw. sollte.

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

Nun warum dann nicht die 10080000 so lassen aber eben nicht in die
Hierarchie-Struktur aufnehmen und statt dessen eine n:m PLZ Hierarchie
aufbauen.

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

Nun das kommt immer auf den Anwendungsfall an. Habe ich z.B. nur eine PLZ
und keinen Ort interessiert mich durchaus eine "Mittelpunktskoordinate"
eines PLZ Gebietes. Du musst das getrennt betrachten und nicht nur auf
bestimmte Anwendungsgebiete. Ein Ort hat Koordinaten, kein PLZ Gebiet hat
Koordinaten, eine Strasse hat Koordinaten (gleich Logik könnte man nämlich
auch auf Strassen anwenden - wozu dann Koordinaten beim Ort wenn doch die
Strasse Koordinaten hat). Es würde niemanden stören und jeden kann nach
seinem Anwendungsfall die Daten herauskitzeln. Erfasse ich sie garnicht erst
sind sie gleich mal garnicht da.

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

Nun das würde ich mal so nicht sagen. Es gibt durchaus auch andere
Datenbestände die Strassendaten und auch Hausnummerndaten haben die
vielleicht nicht so genau wie bei der Post sind aber durchaus brauchbar.

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

Nun richtig ist eben die Frage. Wenn hier Ort drin stehen die
garniemalsnimmer so heissen wie sie hier in der DB stehen dann schränkt das
die Nutzbarkeit der Daten ein. Ich sage ja auch nicht das die Daten raus
sollen nur gehören diese Prosanamen in einen anderen Typ und der offizielle
Name in den Typ 500100000.

Da die Basisdaten der Suchbegriffsgenerierung nicht veröffentlicht werden
ist es technisch unmöglich die korrekte Schreibweise zu rekonstruieren.
Warum? Nun das Beispiel hast du oben selbst gegeben: Mit oder ohne
Bindestrich, Leerzeichen, Punkt oder Komma ... war weg ist ist weg und man
kann das nicht wiederherzaubern.

Gruß,
Andreas