[opengeodb] Teilprojekt verwendbare Daten

[Andreas Müller]

Hallo Martin,

> Ich würde viel eher empfehlen, passende Scripts zur Verfügung zu 
> stellen, wie man aus einem allgemeinen und universellen Bestand die 
> Dinge rausfiltern kann, die man selbst braucht. Es ist IMHO 
> unmöglich, 
> die Daten in jeder erdenklichen und nötigen Form anzubieten. Einer 
> braucht nur die Gemeinden, einer nur die Vorwahlen, viele nur die 
> PLZ-Gebiete usw.

Script? Auf welcher Basis denn? PHP? Hat jeder PHP? Win32 Binaries? Hat
jeder Windows?

Es ist nicht notwendig die Daten in ALLEN nötigen Formaten aufzubereiten. Es
gibt Standard-Anwendungebiete die man definieren und versorgen muss. Wem das
nicht reich kann immer noch die Originaldaten nehmen. Aber ich würde
behaupten das man 80% erschlagen kann.

> > So ist es z.B. im Moment nicht mehr möglich mit nur einer 
> SQL Abfrage
> > zuverlässig eine Liste aller deutschen Ort mit PLZ und 
> Koordinaten zu
> > bekommen.
> 
> Erstens ist das falsch, zweitens ist das IMHO nciht nötig.

So wo ist das denn falsch? Ich muss mich durch eine Hierachie quälen bei der
nicht festgelegt ist das jedes Element die gleichen Ebenen durchläuft. Daher
ist es nicht möglich mit einer SQL Abfrage eine Liste
"Land,Ort,Ortsteil,PLZ,Koordinaten" abzufragen. Den allgemeinen Gegenbeweis
OHNE eine potentiell nicht datensyncrone, weil nicht dazu veröffentlichte
"geodb_hierarchies" Tabelle.

> > Erst ein algorithmisches durchhangeln durch in der Text-Tabelle
> > (!!!TEXT!!!) verküpften Hierachiebenen führt hier zum Erfolg. Die
> > angebotenenen "Dhier.sql" Dateien oder was auch immer 
> erscheinen nicht mit
> > der Hauptdatenbank und stellen somit keine korrekte alternative dar.
> 
> Dhier ist aber genau das, was du verlangst: redundante 
> Ergänzungsdaten, 
> weil entweder SQL oder die SQL-Fähigkeiten zu beschränkt 
> sind, um diese 
> Daten selbst abzuleiten.

Na das ist ja toll nur kann man im Moment keine Daten herunterladen die
definiv zusammenpassen. Sonst müssten die Daten zusammen mit den
Originaldaten veröffentlicht werden. Es kann nicht sein das ich auf SF.net
mit die Originaldaten besorge und dann irgendwo im Netz eine hoffenlich
passende andere Landesspezifische Verknüpfungsdatei herunterlade.

Wirklich "redundat" sind die Daten nicht wirklich da sie sich nicht via SQL
wiederherstellen lassen - zumindest in der heutigen Form nicht. Genausowenig
wenn man Datentypen wild mischt - oder was hat eine loc_id in der
Text-Tabelle zu suchen?

> 
> > Die Dokumentationen stimmen nicht
> > mehr,
> 
> weil niemand sie korrigiert. Es ist einfacher, darüber zu klagen, als 
> sie zu verbessern.

Verbessern wird sowas nur jemand der sich für die Datenstrukur Entwicklung
verantwortlich sieht. Derjenige der die Datenstruktur ändert hat auch die
Doku anzupassend.


> > wichtige Daten werden einfach mal weggelassen und in der 
> Text-Tabelle
> > verhackstückt - lustig wenn ich dann überall casten muss um 
> einen Join bauen
> > zu können usw. Wenn die "Teil von" etc. Logik wenigstens 
> eine Bit-Map wäre
> > das man von einem Ort auch direkt auf das Land schließen könnte ...
> 
> Dir wäre das Land wichtig - anderen vielleicht nur das Bundesland.

An und dann gibts halt ne Spalte mehr mit Bundesland. Wir reden hier nicht
von redundanzfreien Erfassungsdaten sondern von praktisch verarbeitbaren
Daten in einer (Web-)Anwendung. Und vor allem von Daten die ein nicht
opengeodb Profi lesen, verstehen und verarbeiten kann. Wir reden von wenigen
MB Daten, von SQL Servern mit der Möglichkeit von Indizes etc.

> > Vielleicht schließen sich ja ein paar betroffene zusammen 
> und finden hier
> > gemeinsam eine Lösung - so jedenfalls sind die Daten 
> unbrauchbar da kaum zu
> > beherrschen.
> 
> Meine Motivation ist hier beschränkt, meine Zeit noch viel mehr. 
> Beispielsweise hat sich seit Monaten niemand gefunden, mal eine 
> brauchbare README-Datei zu schreiben. Ich würde mich viel 
> lieber auf die 
> Teile konzentrieren, die mir niemand abnehmen kann.

Nun falls die README das Datenmodell beschreibe soll dann siehe oben. Ich
befürchte das die Hürde durch das Konstrukt durchzublicken so groß ist das
sich da niemand rantraut.

Nochmal: Ich finde die Struktur für eine Erfassungsdatenbank ja nichtmal
dumm. Abgesehen von ein paar kleinen Inkonsequenzen verstehe ich den Aufbau
nur zu gut. Nur verstehe ich alle die damit nicht klarkommen um mit den
Daten zu arbeiten - und das kann man hier auf der Liste eindrucksvoll
verfolgen.

Gruß,
Andreas