[opengeodb] Teilprojekt verwendbare Daten

[Martin Trautmann]

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

Mir ist schnuppe, wie du z.B. ein SQL-Makro definierst oder welches 
andere Hilfsmittel du verwenden willst - dein Problem. Mein Werkzeug ist 
Perl, um für dich SQL daraus abzuleiten.

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

Genau dafür kannst du die hierarchies verwenden.

 > Den allgemeinen Gegenbeweis
> OHNE eine potentiell nicht datensyncrone, weil nicht dazu veröffentlichte
> "geodb_hierarchies" Tabelle.

Es gab hier mal laute Proteste, warum die hierarchies wer wären. Also 
setze ich mich hin, leitete diese redundanten hierachies ab, stellte sie 
bereit - und bekam null Rückmeldung, ob damit das Problem nun gelöst 
wäre. Ebensowenig hat sich keiner der SQL-Experten genäussert, wo denn 
nun das Problem sei, das innerhalb on SQL zu machen. Meckern ist leichter...

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

Richtig, das kann nicht sein. Das wäre auch ziemlicher Schmarrn, Sachen 
zusammenzupacken, die nicht zusammenpassen.

> Wirklich "redundat" sind die Daten nicht wirklich da sie sich nicht via SQL
> wiederherstellen lassen - zumindest in der heutigen Form nicht.


Ach, du glaubst, ich hätte irgendwo noch kleine Geheimdaten, weil ich es 
schaffe, ohne SQL für SQL genau jene Daten abzuleiten, wo sich niemand 
bereit fand, dafür eine Lösung komplett innerhalb von SQL vorzunehmen? 
Den entsprechenden Lösungsweg hatte ich wiederholt geschildert. Wenn SQL 
als angeblich so überlegenes Hilfsmittel nicht in der Lage ist, damit 
die nötigen Operationen vorzunehmen, dann würde ich doch erhebliche 
Zweifel an der Tauglichkeit dieses Werkzeugs haben.

 > Genausowenig
> wenn man Datentypen wild mischt - oder was hat eine loc_id in der
> Text-Tabelle zu suchen?

Du pickst dir gerne raus, wann du die reine Lehre willst und wann du 
pragmatische Vereinfachungen suchst. Dann erkläre mir bitte, was nach 
reiner Lehre wohin gehören muss, dann bin ich vielleicht bereit, das für 
dich auch so zu modellieren. Ich habe aber keine Lust, mir auch noch 
selbst die Stöckchen zu suchen, über die du mich springen lassen willst.



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

Diese Datenstruktur ist nicht plötzlich so festgelegt worden, sondern 
hat sich so entwicklet, weil immer wieder irgend jemand hier und da 
nochwas dazu wollte. Ich warte noch immmer auf deinen grossen Wurf, wie 
es besser zu machen wäre...


> An und dann gibts halt ne Spalte mehr mit Bundesland.

und noch eine fuer den Regierungsbezirk und noch eine fuer den Kreis und 
noch eine fuer die Gemeinde - sprich, du willst irgendwann doch einfach 
nur die hierarchies?

> Wir reden hier nicht
> von redundanzfreien Erfassungsdaten sondern von praktisch verarbeitbaren
> Daten in einer (Web-)Anwendung.

Nein, davon reden wir nicht. Ich rede von opengeodb, von offenen 
Geodaten. Mir geht's primär um die Daten, um die Inhalte. SQL ist nur 
ein Vehikel. Daraus kann sich jeder ableiten, was er braucht.

Wer eine fertige Web-Anwendung will, der möge sich diese irgendwo 
besorgen. Vielleicht könnte opengeodb auch dies bieten - aber nicht von 
mir. Wer das haben will, soll sich eine fertige Web-Anwendung kaufen.

> Und vor allem von Daten die ein nicht
> opengeodb Profi lesen, verstehen und verarbeiten kann.


Ich behaupte mal, fuer den Nicht-Profi gibt es nichts einfacheres und 
verstaendlicheres als die .tab-Dateien. Die kann er nämlich direkt mit 
Excel aufmachen...


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

Dafür gibt's eine mailing list, wo man fragen kann.

Gruss,
Martin