[opengeodb] Inkonsistenzen der Download-Daten

[Martin Trautmann]

Andreas Müller wrote:

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

Das ist richtig: in DE ist vieles hinzugekommen.
Ausserdem haben sich z.B. in AT viele der Nummern nochmal komplett geändert.

Dein "passen nun aber ganz und gar nicht" hilft nicht viel weiter,um 
Probleme einzugrenzen. Mit deiner Aussage hier weiss ich, worauf du dich 
beziehst - und womit man dem abhelfen könnte, schlichtweg mit einem 
neuen Dump der hier.sql


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

Es gab ja auf SF keine neuere release, mit oder ohne Einbindung 
ungeprüfter hierarchies.

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

Bis hierhin: ja, so kann das schon jetzt passieren. Was das Script noch 
nicht kann, ist die passende Benennung der Datei: die nächste bei 
gleicher Datenstruktur wäre nach
dump/opengeodb-02612_2008-01-21.sql.gz also
dump/opengeodb-02613_2008-03-25.sql.gz
... und Löschung von dump/opengeodb-026.sql.gz, die auf Version 02612 
verweist
... und Neuanlage des Links dump/opengeodb-026.sql.gz auf Version 02613

Der bestehende Link von dump/opengeodb.sql.gz nach 
dump/opengeodb-026.sql.gz kann bleiben.

Entsprechende Vorschläge für ein shell-script nehme ich gerne auf.


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

Das übersteigt meine aktuellen Kenntnisse. Ablage nur unter CVS würde 
zwar vermutlich einfacher gehen, halte ich aber für wenig hilfreich. 
Beispielsweise kann ich im Büro bisher kein CVS (oder war's SVN?) 
installieren, weil das wiederum bestimmte Bibliotheken brauchte, auf die 
ich keinen Zugriff hatte. Sprich: Die Releases gehören in den normalen 
Download-Bereich. Kannst du dafür ein passendes Script anbieten?

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

Uff - das wäre mehr als mühsam. Geht das auch anders, analog zum INSERT 
INTO?

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

A) weil in den .tab derzeit schlichtweg nicht die Info vorliegt, in 
welcher Sprache das steht. Ich kann die Info nicht herbeizaubern, 
sondern muss sie erst noch einpflegen

B) weil ich mit dem patch eine Holzhammermethode anwenden kann: Ich 
werde einfach alles löschen, wo ich den Verdacht habe, dass es 
herausgehört. Ich weiss schon jetzt, dass ich damit Löschbefehle für 
etwas geben muss, das in Einzelfällen überhaupt nicht vorliegt

C) weil die Wiki-Versionierung der Extra-Daten mit drei Optionen kommen 
wird: ändern, hinzufügen oder löschen. Beim Ändern und Löschen werden 
aber nicht etwa die SQL-Dateien gleich entsprechend neu erstellt und um 
die zu löschenden Zeilen bereinigt. Statt dessen wird am Ende der Datei 
der entsprechende Löschbefehl hinzugefügt - der so auch unmittelbar 
wieder rückgängig gemacht werden kann.

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

Wenn du mir eine Tabelle gibst mit locid und 500100001-Wert, dann kann 
ich das kurzfristig hinzufügen. Ansonsten musst du dich noch etwas 
gedulden, bis du das selbst eingeben kannst.


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

Rotta - Also 
http://fa-technik.adfc.de/code/opengeodb.pl?locid=23356;c=DE, Teil von 
http://fa-technik.adfc.de/code/opengeodb.pl?locid=35793;c=DE

Zum Zeitpunkt der hier-Berechnung war die Gebietsreform in 
Sachsen-Anhalt wohl noch nicht eingepflegt.

> 23717
 > 23735
 > 23827
 > 23973
 > 24178

Schköna, Schleesen, Schnellin, Schützberg, Selbitz
dito

> 80596
> 80598
> 80599
> 80601
> 80602
> 80603
> 80604
> 80605
> 80606
> 80607
> 80608

Da haben wohl Leute mit Neueingaben herumgespielt und die entsprechenden 
Angaben noch nicht gemacht bzw. die Daten sind so neu, dass sie im 
hier-dump noch fehlen.

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

... also erst mal haufenweise Ergebnisse mit 8 als Teil von 8, was ja 
völlig richtig ist. Auf Ortsteilebene wird es beliebig schwierig, die 
richtige Ebene herauszufinden. Diese Ebenen sind nicht mehr amtlich - 
und auch nicht mehr sinnvoll in geodb_hierarchies einzubinden. Mit "Teil 
von" bekommt man die notwendige Flexibilität.

> 80621;5;5

Da ist die Ebene falsch markiert - das ist kein Kreis (mehr), sondern 
(nur noch) eine Gemeinde.

Die entsprechende Änderung habe ich soeben erledigt:
http://fa-technik.adfc.de/code/opengeodb.pl?locid=80621;c=DE

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

Ja, das war vielleicht besser so.

Nach deiner Aussage hatte ich eher Fälle erwartet, wo der untergeordnete 
Teil als übergeordnet markiert gewesen wäre:

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

> Die Frage die sich hieraus ergibt ist wie man das eingentlich in der
> "geodb_hierarchies" Tabelle abbilden soll - denn so geht das dort nicht.

Mach' einen Vorschlag...


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

"BRANDIS" wäre ja durchaus richtig - nur möchtest du vermutlich das 
ganze in "Schönschrift" "Brandis". Nun, diese Information ist redundant 
und lässt sich wie erklärt aus BRANDS und Brandis bei Wurzen korrekt 
ableiten.

> Ganz abgesehen davon das der Name
> "Brandis bei Wurzen" eine Erfindung ist.

Nicht meine. Google kennt 14500 Treffer dazu.

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

ich hatte sie dir gerade zuvor geschrieben. Jemand muss sie in SQL 
giessen und je nach Erkenntnissen verbessern.


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

Ich habe in der Praxis festgestellt, dass Ortsteile gerade in 
Kombination mit Gross-/Klein-/Ober-/Unter-/Alt-/Neu- variantenreich mal 
mit oder ohne Leerzeichen oder Bindestrich. Ich tendiere derzeit auch zu 
deiner Lösung - das komplette Zusammenfassen verunstaltet viele 
Schreibweisen zur Unkenntlichkeit. Was bei "St. Ingbert"? "ST. INGBERT" 
oder "ST INGBERT"?

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

Kann man - wenn man damit etwas verbessern würde.

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

Es geht einfacher ohne Fallunterscheidung, wenn die Ebene quasi die 
Hierarchieebene wiedergeben kann: Ebene 1 -> 10010000, Ebene 7 -> 
10070000, Ebene 8 -> 10080000 usw.

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

Dann habe ich eine ganz pragmatische Lösung für dich: Vergiss, dass PLZ 
12345 und 12347 in X-Dorf die PLZ 12345 und 12347 ist, sondern betrachte 
die 12345 einfach als m:n-Verknüpfung von Ort X-Dorf zu PLZ-Gebiet 
12345. Dass der hierzu verwendete Schlüssel zufälligerweise genauso 
heisst wie die PLZ selbst, das braucht dich ja nicht zu stören.


Oder verkenne ich irgendwie dein Problem?

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

Du gehst von einem offiziellen Namen aus, wie er für deinen speziellen 
Anwendungszweck hilfreich ist: Dir reicht PLZ und Ortsname, gerade weil 
über die PLZ jeglicher Zusatz entfallen darf und soll: Seit Umstellung 
auf fünfstellige PLZ schreibt man eben nicht mehr "Frankfurt a.M.", 
"Frankfurt / Main" oder "Frankfurt am Main", sondern nur noch Frankfurt.

Bei einer Textsuche hingegen, bei Statistiken in Tabellenform usw. ist 
wenig hilfreich, wenn du "Frankfurt, Oder" und "Frankfurt am Main" als 
Frankfurt nicht von einander unterscheiden kannst.

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

Es gibt keine Komma in ASCII, vermute ich. Wie du die Kurzform aus der 
Kombination von ASCII und Langform ermitteln kannst, hatte ich dir schon 
beschrieben.

Schönen Gruß
Martin