[opengeodb] Dokumentation

[Peter Wendorff]

Hallo Stephan.
> Hier stellt sich die Frage wie weit wir ins Detail gehen wollen. Der
> Import über phpMyAdmin ist sicher die häufigste Variante, aber allein
> davon existieren etliche unterschiedliche Versionen. Die aktuelle
> bietet (dem Vernehmen nach) auch die Möglichkeit die Dumps automatisch
> zu splitten. Oft ist aber auch schon die Maximale Upload-Größe in der
> php.ini auf 2 MB beschränkt, oder die maximale Skriptlaufzeit ist nicht
> änderbar, etc. Die Nutzer die die Daten bei einem Massenhoster
> unterbringen wollen haben aber kaum Einfluß auf die php.ini oder die
> installierte phpMyAdmin-Version. Andere Nutzer wollen vielleicht gar
> keinen Webserver mit PHP laufen haben.
>   
Auf jeden Fall sollte das Problem erwähnt werden, denke ich - ob hier 
oder an anderer Stelle, lässt sich diskutieren.
> Wegen der Vielzahl der Probleme habe ich hier auf einen detailierte
> Beschreibung verzichtet. Eine Beschreibung für den Import per
> Shell-Zugriff mit dem Standard-MySQL-Client würde ich vielleicht noch
> für sinnvoll halten.
>   
Ich würde die ganze Import-Problematik auf einer eigenen Seite 
beschreiben und Lösungstipps geben, und diese hier mit verlinken.
> [..]
> Alle Resultate der angegebenen SQL-Abfragen sind natürlich Ergebnisse
> der lokal bei mir vorhandenen Daten. Dass bei mir kein Erdteil und nur
> ein Staat vorhanden ist, liegt wohl daran, dass ich die extra.sql nicht
> importiert habe, in der diese Zusatzdaten enthalten sind. Ich habe
> aktuell auch nur die DE.sql importiert.
>   
Ich wäre dann dafür, einen aktuellen Dump mit sämtlichen Daten zu 
benutzen, und die entsprechenden Informationen darzustellen, da es sonst 
zu viele Sonderfälle gibt.
>> 2. werden bei der angegebenen Abfrage auch weitere Sprachvarianten 
>> mitgezählt, was die Abfrage damit irgendwie noch nicht voll einsatzfähig 
>> macht.
>>     
> Das alles darf natürlich gerne verbessert werden ;-)
>   
gerne, aber später - es war mir nur aufgefallen, deshalb hab ich es mit 
notiert. Ich bin heute morgen aber nicht direkt dazu gekommen ;)
>> 3) http://opengeodb.giswiki.org/wiki/Datenbank#Tabellen-.C3.9Cbersicht
>>
>> Ich gehe davon aus, dass geodb_polygons die Punkte zu den in geodb_areas 
>> definierten und benannten Polygonen enthält, und habe dies in der Liste 
>> vermerkt.
>>
>> Bei geodb_floatdata steht, diese wäre bisher nicht genutzt. Bei mir 
>> tauchen darin allerdings 18.220 Einträge vom Typ 610000000 (Fläche) auf. 
>> Was ist jetzt korrekt?
>>     
>
> Wie gesagt, diese Tabellen-Beschreibungen habe ich einfach übernommen
> und nicht überarbeitet. Dies sollte dringend noch erfolgen. An dieser
> Stelle wollte ich auch noch bemerken, dass ich die Auflistung der Felder,
> Indizes, Triggers, Definition etc. in der Detailansicht der Tabellen
> wenig sinnvoll finde. Diese Information sollte sich zum einen jeder aus
> seiner eigenen DB holen können, zum anderen wird der Pflegeaufwand der
> Seiten dadurch stark erhöht.
>   
Wieso wird der Pflegeaufwand dadurch erhöht? Gerade Indizes, Trigger 
etc. ändern sich doch eigentlich durch die vorhandene Struktur äußerst 
selten, oder nicht?
> Ansonsten gilt hier: falls dir an dieser Stelle etwas auffällt, kannst
> Du davon ausgehen, dass Deine Info die aktuellere ist (falls Du 0.2.5a
> verwendest)
>   
Ich weiß ehrlich gesagt nicht, welche Version ich verwende. Vorschlag 
dabei übrigens an Martin: In der geodb_changelog sollte bei jeder 
Veröffentlichung ein (neuer) Datensatz eingefügt werden, damit man 
Versionsnummer und Datum der Veröffentlichung nachvollziehen kann. Ob 
dann die Beschreibung der Änderungen dabei steht oder nicht, ist die 
nächste Frage, aber nicht so wichtig.
>> 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.
> 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.

Gruß
Peter