Teilprojekt verwendbare Daten

[Andreas Müller-3]

Hallo zusammen,

nachdem ich mir gerade die aktuelle Datenstruktur genau angesehen habe kann
ich jeden der mit den Daten massive Probleme hat sehr gut verstehen.
Ich würde daher vorschlagen ein Teilprojekt zu starten das parallel zum
erscheinen der Original-DB passende Daten zur Verfügung stellt um die
Verwendung der Daten zu vereinfachen.

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

Ich weiss nicht wer das noch blicken soll. Die Dokumentationen stimmen nicht
mehr, 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 ...

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.

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,
>
> nachdem ich mir gerade die aktuelle Datenstruktur genau angesehen habe kann
> ich jeden der mit den Daten massive Probleme hat sehr gut verstehen.
> Ich würde daher vorschlagen ein Teilprojekt zu starten das parallel zum
> erscheinen der Original-DB passende Daten zur Verfügung stellt um die
> Verwendung der Daten zu vereinfachen.

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.

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

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

> Ich weiss nicht wer das noch blicken soll.

Ich auch nicht - ich verwende daraus nur jene Daten, die mich interessieren.

> Die Dokumentationen stimmen nicht
> mehr,

weil niemand sie korrigiert. Es ist einfacher, darüber zu klagen, als
sie zu verbessern.

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

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

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,

> 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



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

[Andreas Müller-3]

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




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

[Martin Trautmann]

Andreas Müller wrote:

>> Genau dafür kannst du die hierarchies verwenden.
>
> Die es aber nicht mehr konsistent zu den Daten gibt!

Warum nicht? In dem Moment, wo ich einen neuen Dump anstosse, kann ich
dazu die Hierarchies passend erzeugen.

Warum aber sollte ich das tun, wenn ich keine Rückmeldung bekomme, ob
sie was taugen oder nicht.

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

Die haben bisher funktioniert, wo wir nur bis zur Gemeinde-Ebene
heruntergingen - und selbst da hatten wir nicht sauber getrennt zwischen
Ort und Gemeinde. Wenn wir heute Daten ergänzen wollen, so kommen wir
hinunter auf Ortsteil-Ebenen, wo die starren Hierarchien zunehmend
nutzlos werden, wo aber deren Verwaltung einen enormen organisatorischen
Pflegeaufwand bedeuten.


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

Die hierarchies werden zu einem bestimmten Zeitpunkt erzeugt und passen
dann zu den Daten von diesem Zeitpunkt. Wenn du völlig unterschiedliche
Releases zusammenwirfst, so wird das noch immer zu grossen Teilen passen
- an den aktualisierten Ecken aber klemmen.


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

Ich denke, ich habe den Gegenbeweis angetreten, dass ich mit eigentlich
ungeeigneteren Werkzeugen und wenig Aufwand diese Daten offensichtlich
herstellen kann. Im Gegenteil wäre aber ein immenser Pflegeaufwand damit
verbunden, die hierarchies mit zu korrigieren und zu versionieren. Den
tue zumindest ich mir nicht an. Du kannst ja mal exemplarisch selbst
versuchen, die Kreisreform in Sachsen-Anhalt über die hierachies
nachzuziehen - das sollte für dich ja eine einfache Fingerübung sein...


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

Dann erkläre es mir doch einfach. Wie viele konstante Ebenen brauchst
du, um von Deutschland nach Berlin-Kreuzberg zu kommen? Und wie viele
brauchst du bis München-Schwabing? Und wie viele bis zur Uferpromenade
von Lausanne?


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

Auch das halte ich zumindest aus meiner Sicht für falsch. Es kann sein,
dass du auch auf diesem Weg zum Ziel kommen kannst. Warum aber kannst du
dir nicht die passenden Hilfsstrukturen hinzufügen, die dir das Leben
leichter machen?


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

Mach's doch einfach mal. Wir haben jahrelang um den grossen Wurf
herumgeredet, wie man die Bearbeitung der Daten am besten online zur
Korrektur anbieten könnte. Aber keiner hat's gemacht. Sobald du etwas
bessers anbieten kannst, ist es sicherlich sinnvoll, auf dein Angebot zu
wechseln.


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

Genau deswegen sage ich ja: wenn du jemanden helfen willst, dann wäre
eine Möglichkeit, dass du eben jene Dokumentation anfertigst, die ihm
helfen 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...
>
> Dafür gilt das gleiche wie oben? Gibts ja offiziell nicht parallel
> versioniert zum download. Woher soll man wissen was man da nun hat.

Sie sind tagaktuell, jederzeit verfügbar und sie werden begleitet von
einem Protokoll der Änderungen, die jederzeit von jedermann korrigert
werden können. Eine weitere Versionierung der Daten wäre ebenfalls
einfach nur redundant. Sollte ich für jeden Benutzereintrag eine neue
Version anlegen?

Das würde ohnehin voraussetzen, dass Benutzer die Daten korrigieren
würden...

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

gut dem bleibt nichts hinzuzufügen wenn du dir nicht einmal die Arbeit
machst zu lesen was ich geschieben habe.

Gruß,
Andreas

--
+--------------------------------------------------+
| Nur zwei Dinge sind unendlich:                   |
| Das Weltall und die menschliche Dummheit.        |
| Beim Weltall bin ich mir aber nicht ganz sicher. |
|                                                  |
| ~Albert Einstein~                                |
+--------------------------------------------------+


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

[Andreas Hubel-2]

Mach einfach was du vorhast und versuche möglichst viele Leute zu  
finden, die dir helfen falls, du welche brauchst.

MfG Andi

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

[Stephan Schuster]

Hallo Andreas,

> gut dem bleibt nichts hinzuzufügen wenn du dir nicht einmal die Arbeit
> machst zu lesen was ich geschieben habe.

man sollte das was man von anderen fordert auch selbst leisten. Du hast
Dich hier in ziemlich rüdem Ton darüber beschwert, die Daten wären nicht
zu durchblicken und "unbrauchbar" und hast Dir nicht die Mühe gemacht,
auf Martins Argumente zu antworten.

Dir stehen hier vor allem dank Martins Engagement eine Menge
Informationen zur Verfügung die woanders jede Menge Geld kosten, und
ohne ihn wären die Daten auf dem Stand von ca. 2005. Und Du beschwerst
Dich, dass Dir das Format nicht taugt. Dann nimm einfach die (frei
verfügbaren) Daten und bau Dir Deine Lösung zusammen und erwarte nicht,
dass andere das für Dich machen!

Und wenn Du was Gutes tun willst, stell Deine Lösung auch anderen zur
Verfügung.

Gruß
Stephan

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

[Lucas Mengel]

Hi Andreas!
Solche Vorschläge haben wir hier schon öfters mal gelesen.
Tatsache ist, dass der Datenbestand nicht einfach in einer
einzigen Tabelle veröffentlicht werden kann. Es wäre ja auch
blödsinnig, würde man in jedem Datensatz den Stadtname,
Gemeinde etc. neu aufführen.
Es muss schon ein sehr gutes Relationenmodel geben, aber das
ist bei näherem hinsehen tatsächlich nicht einfacht.

Andreas Müller schrieb:

> Hallo zusammen,
>
> nachdem ich mir gerade die aktuelle Datenstruktur genau angesehen habe kann
> ich jeden der mit den Daten massive Probleme hat sehr gut verstehen.
> Ich würde daher vorschlagen ein Teilprojekt zu starten das parallel zum
> erscheinen der Original-DB passende Daten zur Verfügung stellt um die
> Verwendung der Daten zu vereinfachen.
>
> 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. 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.
>
> Ich weiss nicht wer das noch blicken soll. Die Dokumentationen stimmen nicht
> mehr, 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 ...
>
> 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.
>
> Gruß,
> Andreas
>
>

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

[Lucas Mengel]

Hi Martin!
Ich glaube hier verbirgt sich mehr Potenzial als wir vermuten.
Aber sicherlich werden sich einige Kreativköpfe denken:
Warum die Arbeit machen, wenn sich das Datenbankmodell
aufgrund dieser Protestwelle sowieso bald ändert?

Ich meine, seien wir mal ehrlich: Im Grunde suchen wir doch
alle nur nach einer besseren Lösung, oder nicht?

Gruß,
Lucas

Martin Trautmann schrieb:

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

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

[Martin Trautmann]

Lucas Mengel wrote:
> Hi Martin!
> Ich glaube hier verbirgt sich mehr Potenzial als wir vermuten.
> Aber sicherlich werden sich einige Kreativköpfe denken:
> Warum die Arbeit machen, wenn sich das Datenbankmodell
> aufgrund dieser Protestwelle sowieso bald ändert?

Hallo Lucas,

Wenn jemand einen guten Vorschlag hat, wie ein besseres Modell aussehen
kann, so ist das nach meiner Einschätzung recht leicht umsetzbar. Ich
erwarte aber keine massiven Änderungen - und mir scheint, die Grundtypen
mit ihren Schlüsselnummern werden die gleiche bleiben.

Das Datenbankmodell ist für mich nur ein Vehikel. Mir geht's um die
Inhalte, die ich selbst in zwei gänzlich anderen Datenstrukturen nutze
(eben .tab und ansonsten .fp7). Wenn ich eine schlüssige Erklärungen
bekomme, was falsch ist und besser sein soll, so halte ich das für
durchaus diskussionswürdig und erstrebenswert. Dafür brauche ich aber
weit konkretere Angaben als nur einfache Ablehnung. Erzähl einem Blinden
von der Sonne und mir von SQL...

> Ich meine, seien wir mal ehrlich: Im Grunde suchen wir doch
> alle nur nach einer besseren Lösung, oder nicht?

Aber sicher doch - bis dahin halte ich die bisherige aber für durchaus
tauglich und anwendbar. Ich finde aber vor allem, dass die grundlegende
Dokumentation fehlt, was ueberhaupt drin ist und was das bedeutet.
Vermutlich läuft es auch hier darauf hinaus, sowas selbst machen zu
muessen...

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

[Peter Wendorff]

Hallo Andreas, Hallo Liste.
Andreas Müller schrieb:
>> 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.
Hier ist das meiner Meinung nach eigentliche Missverständnis.
Die  OpenGeoDB ist eben KEINE Web- oder sonstige -Anwendung, sondern
eine Sammlung von Daten.
Ein Anwender der OpenGeoDB muss sich eben mit der Struktur der Daten
beschäftigen, da führt kein Weg daran vorbei.
Da diese Anwender dann aber eben auch im Normalfall Programmierer sind,
kann man ihnen an einigen Stellen dies meiner Meinung nach auch zumuten.
Technisches Unverständnis wird in der Mailingliste oft behoben oder
vermindert, wer dazu zu blöd ist, soll sich fragen, ob er als
Programmierer taugt - oder ob er/sie/es eben doch lieber bei irgendeinem
Anbieter eine fertige Lösung kauft - die ja übrigens zudem auf der
opengeodb basieren darf, da die Lizenz entsprechend frei ist, wenn ich
mich grade nicht irre.
> 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.
Klar - Geld hilft immer bei mangelnder Bildung und mangelndem Einsatz -
man kann damit etwas dagegen tun oder die Auswirkung eliminieren, indem
man einkaufen geht - irgendeinen Grund muss die Shopping-Manie der 12
bis 17-jährigen (keine harte Grenze, nagelt mich darauf nicht fest!)
Mädchen in Deutschland ja haben.

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

Das sollten parallele Projekte wie zum Beispiel die GeoClass erledigen,
das hat nur am Rande mit der OpenGeoDB und definitiv nichts mehr mit
Martin zu tun (es sei denn, es tritt der unwahrscheinliche Fall ein,
dass der sich da einklinken will).
An dieser Stelle kann man dann auch überlegen, welche Formate dazu
sinnvoll sind, dann gehört zu der entsprechenden Schnittstelle (ob
Klasse, "einfaches" Export-Script oder was auch immer) auch eine
entsprechende Schnittstelle für die Daten, so dass man eben entweder die
releases von Martin direkt verwenden kann sie sich über Import-Scripte
importieren lassen.

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