[opengeodb] Dokumentation

[Martin Trautmann]

Peter Wendorff wrote:
>>> Bei geodb_hierarchies habe ich vermerkt, dass und warum diese Tabelle im
>>> Dump momentan leer ist.
>>>
>> ... und dass ein SQL-Skript geplant ist ;-) Wer plant denn das gerade?
>>
> Es tauchte hier in der Liste in den letzten Tagen und Wochen gehäuft
> gerade diese Diskussion auf, und ich werde mich damit in den nächsten
> Tagen mal beschäftigen - insofern: ich.
>> Soll das dann eine Reihe von Abfragen enthalten, oder wird das per
>> Programmierung gelöst?
> Das Script wird aus den Einträgen vom Typ Ebene (400200000) die
> entsprechenden Einträge der geodb_hierarchies erzeugen. Wenn ich das von
> Martin richtig verstanden habe, sind genau dies die Informationen, die
> dafür gebraucht werden, und ich vermute, dass es sich dabei dann
> insgesamt um eine Handvoll, wenn auch recht langläufige SQL-Befehle
> handeln dürfte, die nach und nach die Tabelle füllen.

Du brauchst Teil von und Ebene.

Du startest auf Ebene 1 und trägst die in 100100000 ein.

Dann nimmst du alle Einträge auf Ebene 2, holst dir über die 
Teil-von-Beziehung die Hierarchie-Beschreibung darüber und ergänzt 
100200000 mit der eigenen locid.

Dann holst du dir Ebene 3, usw.

Es gibt etliche Fälle, wo einzelne Ebenen übersprungen werden. Daher 
bleibt z.B. die Regierungsbezirks-Ebene in den meisten Bundesländern leer.

>> Ich denke fast, dass es sinnvoll ist, diese
>> Tabelle wie bisher von Martin erstellen zu lassen und diese vom
>> Unterverzeichnis dump in das Standard-Verzeichnis zu verschieben. Dabei
>> würde ich sie dann auch umbenennen in (DE|AT|CH)_hierarchies.sql, damit
>> das etwas klarer ist. Und natürlich die Doku entsprechend anpassen.
>>
> Eben genau das ist dann nicht sinnvoll, wenn die Daten aus den
> bestehenden Daten erzeugt werden können.
> Ist das nämlich der Fall, dann kann ein einzelnes hierarchies-Script die
> Hierarchie-Tabelle für beliebige Versionen und Datenmengen erzeugen, was
> Upload-Space, Download-Traffic, Download-Zeiten für die Nutzer, Arbeit
> für Martin und Fehlerpotential sparen dürfte.

Die Arbeit für mich sollte sich in minimalen Grenzen halten - die 
hierarchies können inzwischen nebenher mit ausgespuckt werden. Da es 
aber redundante Daten sind, ist mir der reine SQL-Ansatz am liebsten.

Schönen Gruß
Martin