Inkonsistenzen der Download-Daten

[Andreas Müller-3]

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


--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Martin Trautmann]

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
--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Andreas Müller-3]

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


--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Stephan Schuster]

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

Ich denke du wirst nicht darum herumkommen einen unscharfen Vergleich in
deine Anwendung einzubauen. Für die meisten Einwohner Bad Bernecks ist
der Ort mit "Bad Berneck" ausreichend eindeutig identifiziert, da es
kein anderes Bad Berneck gibt. Etliche fügen vielleicht noch "i.F."
hinzu (steht auf dem Autobahnschild). Amtlicher Name ist jedoch "Bad
Berneck i.Fichtelgebirge". Dein exakter Vergleich wird also in etlichen
Fällen nicht treffen, auch wenn in der DB der amtliche Name steht.

Und wenn Dich "Brandis bei Wurzen" stört, sollte doch eigentlich eine
Änderung über http://fa-technik.adfc.de/code/opengeodb.pl für dich problemlos
möglich sein, oder?

Gruß
Stephan

--
Stephan Schuster <stephan.s@...>

--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Andreas Müller-3]

Hallo Stephan,

ich wiederhole mich gern nochmal:

-> Die Daten sollen ja nicht weg sondern die fehlenden dazu - was ist daran
so schwer zu verstehen?

-> Manchmal will man nicht von einem Ort zur Daten finden sondern z.B. von
einer PLZ, einer Vorwahl oder was weiss ich. Dann sollte ein Ortsname
abfragbar sein der amtlich ist und nicht von Dichtern stammt.

-> Das ganze sind BEISPIEL !!!! Es ist ja wohl nicht Sinn der Sache das man
alle Daten manuell nochmal überarbeiten muss obwohl die passenden Daten
vorhanden wären wenn man sie mit exportieren würde.

"Bad Berneck" heisst offizielle nur "Bad Berneck" - kannst gern nachfragen.
Alle Anhängsel sind inoffizielle Andichtungen. Das gleiche gilt auch für
viele andere Orte.

Warum darf um himmelswillen bei der Anfrage nach der PLZ "04821" nicht
"Brandis" abfragbar sein und warum muss das einzige verwertbare Ergebnis der
Abfrage "Brandis bei Wurzen" sein? Warum muss das so sein und warum darf das
nicht auch anders sein? Warum muss eine Adressvervollständigung dann
"Brandis bei Wurzen" als Ort in die Adresse schreiben wenn doch der Ort so
garnicht heiss? Warum kann man nicht akzetieren das man hier noch etwas
Nachholebedarf hat und das Problem angehen? Warum muss man immer und ständig
nur mauern statt aus dem Projekt das herauszuholen was drinsteckt?

Gruß,
Andreas


--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[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
--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Martin Trautmann]

Stephan S wrote:

> Und wenn Dich "Brandis bei Wurzen" stört, sollte doch eigentlich eine
> Änderung über http://fa-technik.adfc.de/code/opengeodb.pl für dich problemlos
> möglich sein, oder?

Nun, eine solche Änderung würde ein anderer Benutzer wie ich vermutlich
durch einen Klick auf "undo" wieder rückgängig machen, weil die Änderung
einen Verlust an Information bedeutete.

Schönen Gruß
Martin
--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Martin Trautmann]

Andreas Müller wrote:


> "Bad Berneck" heisst offizielle nur "Bad Berneck" - kannst gern nachfragen.

Und Eisleben heisst Lutherstadt Eisleben. Prerow heisst Ostseebad
Prerow. Hamburg heisst Freie und Hansestadt Hamburg usw.

> Alle Anhängsel sind inoffizielle Andichtungen. Das gleiche gilt auch für
> viele andere Orte.

Im Gegenteil sind viele höchst offiziell und heiss umkämpft, bis man
endlich seinen Titel "Bad" oder "Universitätsstadt" bekommt...

> Warum darf um himmelswillen bei der Anfrage nach der PLZ "04821" nicht
> "Brandis" abfragbar sein und warum muss das einzige verwertbare Ergebnis der
> Abfrage "Brandis bei Wurzen" sein?

Weil du einfach behauptest, es würde nur "Brandis bei Wurzen" geliefert.
Bastel dir Brandis doch selbst rein.

Wenn das für dich so schwierig ist, schicke ich dir gerne eine Liste mit
locid und Langform. Für opengeodb erachte ich dies als redundante Daten.


> Warum muss das so sein und warum darf das
> nicht auch anders sein? Warum muss eine Adressvervollständigung dann
> "Brandis bei Wurzen" als Ort in die Adresse schreiben wenn doch der Ort so
> garnicht heiss? Warum kann man nicht akzetieren das man hier noch etwas
> Nachholebedarf hat und das Problem angehen? Warum muss man immer und ständig
> nur mauern statt aus dem Projekt das herauszuholen was drinsteckt?

Warum muss man jeden möglichen und denkbaren Anwendungsfall vorbereiten,
wenn man derartig redundante Daten mit ein paar Befehlen und
schlimmstenfalls einigen manuellen Eingriffen selbst ableiten kann? Und
was hilft dir "Brandis", wenn du eigentlich "Waldsteinberg" brauchst -
den anderen Ort in der Gemeinde Brandis mit PLZ 04821

Was heisst hier mauern, wenn wir hier einfach diskutieren, was sinnvoll
ist und was nicht? Ja, wenn du nicht diskutieren magst, dann ist das mauern.

Schönen Gruß
Martin
--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Stephan Schuster]

Hallo Andreas,

tut mir leid, ich glaube du hast Ton und Absicht meiner Mail völlig
falsch verstanden ;-)

ich hatte nicht die Absicht zu mauern oder zu blockieren, im Gegenteil
ist mir viel daran gelegen, dass wir uns weiterbewegen und im Zuge
dessen finde ich es gut und hilfreich, dass Du dir die Mühe gemacht hast
die Daten zu prüfen. Dass die OpenGeoDB nicht perfekt ist und
"Nachholbedarf" hat ist hier auch absolut unstrittig, aber wenn jede
Anmerkung hier sofort ohne Diskussion umgesetzt werden würde, würde sich
allein die Datenbank-Struktur schon wöchentlich ändern.

Ich wollte eigentlich nur darauf hinweisen, dass eine unscharfe Suche
möglicherweise deine Anwendung verbessert und habe versucht dies am
Beispiel Bad Berneck zu belegen. Unabhängig davon was mit "Brandis"
passiert ;-)

> "Bad Berneck" heisst offizielle nur "Bad Berneck" - kannst gern nachfragen.
> Alle Anhängsel sind inoffizielle Andichtungen. Das gleiche gilt auch für
> viele andere Orte.

Ich bin bisher davon ausgegangen, im statistischen Bundesamt
Deutschlands würden die offiziellen amtlichen Gemeindenamen benutzt?
http://www.destatis.de/gv/suche_gv2000.htm sagt für Bad Berneck:

PLZ Gemeindenamen      95460 Bad Berneck i.Fichtelgebirge, Stadt
Gemeindetyp            Stadt
Anschrift der Gemeinde Stadt Bad Berneck i.Fichtelgebirge

In der Wikipedia ist als amtlicher Name ebenfalls Bad Berneck i.Fichtelgebirge
geführt. Woher stammt denn deine Erkenntnis, dass dies falsch ist?

Gruß
Stephan

--
Stephan Schuster <stephan.s@...>

--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)