[opengeodb] Teilprojekt verwendbare Daten

[Andreas Müller]

Hallo Martin,

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

wenn du Tools für jeden Vorschlängst ist es nur verständlich das diese Frage
kommt oder?

> Genau dafür kannst du die hierarchies verwenden.

Die es aber nicht mehr konsistent zu den Daten gibt! 

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

Nun es ist immer die Frage wie man ein Problem löst. So ist es aber keine
Lösung da du feste Feldzuordnungen für die Hierarchieebenen wegoptimiert
hast.
Wäre jede Spalte der alten Tabelle via Type abfragbar wäre das anders - dann
hätte man aber wieder redundante Daten. 

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

Du willst mir jetzt aber nicht erklären das die "geodb_hierarchies" nicht zu
den anderen Tabellen gehört? Jede neue loc_id hat hier einer Änderung zur
Folge - daher gehören die Daten dazu und wenn es als separater aber gleich
versionierer Dump ist. Aber der heutig unversionierte download ist murks.
Versioniere es einfach mit und veröffentliche es parallel und schon ist
diesbezüglich alles in Butter.

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

Nö das denke ich nicht - so ein quatsch. Nur halte ich es für falsch ein
Datenstruktur durch eine andere Datenstruktur abzulösen wenn erste nich mit
einfachen Mitteln wiederhergestellt werden kann. Jetzt muss man mit großem
Aufwand diese Daten wiederstellen.

Vielleicht ist dir ja das Problem noch nich klar: Seit der Änderung ist
nicht mehr klar wieviel KONSTANTE Ebenen ich absteigen muss um z.B. Land
oder Bundesland abzufragen. Das ist nun variabel und nicht mehr mit
vertretbaren Aufwand (ohne massive UNIONS und Abfrage aller Möglichkeiten)
machbar. Früher konnte ich geziehlt auf eine Spalte zugreifen und hatte
meine ID's.

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

Ich picke mir hier garnix raus sondern stelle nur fest das ich heute für
JOINS eine loc_id (int) mit einer text_val (varchar) Spalte verwenden muss
was nicht alle Datenbanksysteme so einfach mitmachen. Muss ich dann auf
Cast-Funktionen zurückgreifen bleibt er Optimizer meist auf der Strecke. Ich
sage ja blos das gibts eine Tabelle "geodb_intdata". Wenn wir schon
datentypspezifische Tabellen haben dann sollen Integer Werte auch zu
Integerwerten.

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

Ich hoffe du hast den Schluss der letzten Mail gelesen oder mein Posting vom
04.03.2008. Dann sollte dir das klar sein.

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

Du solltest mal das lesen was ich geschriebe habe. Der Einwand mit den
Bundesland kam von dir und es war nur ein Beispiel von mir was ich versuchte
abzufragen.

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

Mit "wir reden hier" bezog ich mich auf das Thema dieses Treads und nicht
über den opengeodb als solche. Nochmal: Die Strukur der opengeodb ist für
mich abgesehen von den Datentypschwächen und der verloren gegangenen
direkten Hierarchieadressierung so perfekt für das was man mit opengeodb
erreich will.

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

Es hat ja keiner von dir verlangt die Daten anders bereitzustellen. Du wirs
aber zugeben müssen das die Hauptprobleme hier dadurch entstehen das es
extreme Verständnisprobleme und technische Unfähigkeiten der Anwender der
Daten gibt. Nur das führt eben nicht dazu das diese sich zu helfen lernen -
nein die werfen das Handtuch und kaufen sich eben irgendwo anders Daten die
so aufbereitet sind wie sie sie in etwa brauchen. In deren Augen ist
opengeodb dann "scheisse" und ein "saustall" weil es für sie nahezu
unmöglich ist mit den Daten direkt sinnvoll zu arbeiten. Nur wenn das so
weitergeht ist bald niemand mehr da der die Daten verwendet - und für wen
macht man sich dann die Arbeit. Nur wenn die Daten auch (parallel!) in von
den einfachen Anwendern leicht verwendbarer Form zur Verfügung gestellt
werden (und ich sage NICHT das du das machen sollst - du sollst mal schön
dich um die Daten kümmern wie heute) werden die Daten auch von einer
bereiten Masse akzeptiert und verwendet!

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

Dafür gilt das gleiche wie oben? Gibts ja offiziell nicht parallel
versioniert zum download. Woher soll man wissen was man da nun hat. 

Der Release-Inhalt und das Release-Management gilt es meiner Meinung nach
genauso geradlinig zu bringen wie die Lernkurve für Standard-Anwendnungen
abzuflachen. Für ersteres sehe ich dich in der Verantwortung - für letzteres
definiv Leute hier auf der Liste die gemeinsam Standards definieren und
diese aus den Daten füllen und bereitstellen.

Gruß,
Andreas