Dokumentation

[Stephan Schuster]

Hallo,

ich habe jetzt meinen README-Entwurf überarbeitet und im Wiki
(http://opengeodb.giswiki.org/wiki/OpenGeoDB_Dokumentation) eingestellt.
Ich würde mich freuen, wenn jemand das ganze inhaltlich und formal prüft
und Korrektur liest.

Zwei Anmerkungen hätte ich noch: Sollte unter
http://opengeodb.giswiki.org/wiki/OpenGeoDB_-_Dateninhalt
bei den Angaben zu den unterstützten Daten nicht noch erwähnt werden,
von welchem Typ sie sind (Integer, String, Float, etc.)?

Die Liste mit den vorhandenen Tabellen unter
http://opengeodb.giswiki.org/wiki/Datenbank_der_OpengeoDB#Tabellen-.C3.9Cbersicht
müsste überarbeitet werden, vor allem die Detail-Ansichten

Schönen Gruß
Stephan

--
Stephan Schuster <stephan.s@...>

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

[Martin Trautmann]

Stephan S wrote:

> Hallo,
>
> ich habe jetzt meinen README-Entwurf überarbeitet und im Wiki
> (http://opengeodb.giswiki.org/wiki/OpenGeoDB_Dokumentation) eingestellt.
> Ich würde mich freuen, wenn jemand das ganze inhaltlich und formal prüft
> und Korrektur liest.
>
> Zwei Anmerkungen hätte ich noch: Sollte unter
> http://opengeodb.giswiki.org/wiki/OpenGeoDB_-_Dateninhalt
> bei den Angaben zu den unterstützten Daten nicht noch erwähnt werden,
> von welchem Typ sie sind (Integer, String, Float, etc.)?

Ich würde vorschlagen, hier eine Kategorie SQL oder ähnliches für die
Datenstruktur der opengeodb anzulegen, um die Tabellen, die Typen und
sonstiges zu erläutern.

http://opengeodb.giswiki.org/wiki/Types hatte ich bereits angelegt - da
müssen wir wohl noch etwas strukturieren.

Besten Dank für deine Hilfe,
Martin
--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Peter Wendorff]

Martin Trautmann schrieb:

> Stephan S wrote:
>  
>> Hallo,
>>
>> ich habe jetzt meinen README-Entwurf überarbeitet und im Wiki
>> (http://opengeodb.giswiki.org/wiki/OpenGeoDB_Dokumentation) eingestellt.
>> Ich würde mich freuen, wenn jemand das ganze inhaltlich und formal prüft
>> und Korrektur liest.
>>
>> Zwei Anmerkungen hätte ich noch: Sollte unter
>> http://opengeodb.giswiki.org/wiki/OpenGeoDB_-_Dateninhalt
>> bei den Angaben zu den unterstützten Daten nicht noch erwähnt werden,
>> von welchem Typ sie sind (Integer, String, Float, etc.)?
>>    
>
> Ich würde vorschlagen, hier eine Kategorie SQL oder ähnliches für die
> Datenstruktur der opengeodb anzulegen, um die Tabellen, die Typen und
> sonstiges zu erläutern.
>  

Ich halte das für sinnvoll, direkt in
http://opengeodb.giswiki.org/wiki/OpenGeoDB_-_Dateninhalt auch den
Datentyp anzugeben.
Dieser ist schließlich nicht SQL-spezifisch, sondern gilt auch für die
.tab-Dateien, abgesehen davon, dass in denen keine Typprüfung stattfindet.
Ich habe diese Spalte mal eingefügt (bisher unvollständig), rausnehmen
kann man die immer noch.

Eine Kategorie für die Datenstruktur ist sinnvoll, aber nicht als SQL zu
bezeichnen, da, wie vor allem von Dir (Martin) immer wieder betont, die
Datenstruktur ja eben vom Vehikel (.tab oder eben sql) unabhängig ist.

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

[Peter Wendorff]

Eine Sache ist mir grade unter
http://opengeodb.giswiki.org/wiki/Datenbank_der_OpengeoDB#Tabellen-.C3.9Cbersicht 
aufgefallen.
Es dreht sich um die Tabellen geodb_areas und geodb_polygons:
Wenn ich das logisch durchdenke, enthält geodb_areas einen Datensatz für
jede Fläche, geodb_polygons dagegen für jeden Punkt einen Datensatz, mit
einer Referenz auf eben diesen Datensatz in geodb_areas.

Wenn ich damit recht habe - was ich eben nicht genau weiß, dann würde
ich vorschlagen, hier in der Tabellenübersicht schon darauf hinzuweisen.

Gruß
Peter

P.S.: Ich kann das auch selbst machen, wollte mich aber vergewissern,
dass ich nicht mehr falsch mache, als jetzt drin ist.
--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Stephan Schuster]

Hallo Peter,

> Eine Sache ist mir grade unter
> http://opengeodb.giswiki.org/wiki/Datenbank_der_OpengeoDB#Tabellen-.C3.9Cbersicht 
> aufgefallen.
> Es dreht sich um die Tabellen geodb_areas und geodb_polygons:
> Wenn ich das logisch durchdenke, enthält geodb_areas einen Datensatz für
> jede Fläche, geodb_polygons dagegen für jeden Punkt einen Datensatz, mit
> einer Referenz auf eben diesen Datensatz in geodb_areas.
>
> Wenn ich damit recht habe - was ich eben nicht genau weiß, dann würde
> ich vorschlagen, hier in der Tabellenübersicht schon darauf hinzuweisen.

Die Tabellenübersicht habe ich aus der vorhandene Doku übernommen, ohne
sie weiter zu überarbeiten. Die Übersicht finde ich auch gut, auch das
Prinzip der Detailinformation beim Klick auf die Tabelle. Allerdings ist
das nicht vollständig und nicht aktuell. Der ganze Bereich müsste
überarbeitet werden,  z.B. findet man unter geodb_intdata eine Kopie der
Seite für geodb_hierarchies.

> P.S.: Ich kann das auch selbst machen, wollte mich aber vergewissern,
> dass ich nicht mehr falsch mache, als jetzt drin ist.

Nur zu...

Gruß
Stephan

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

[Peter Wendorff]

Und nochmal hallo.
Ich gehe grade die Dokumentation nochmal genauer durch, und werde hier
einfach mal auflisten, was mir noch auffällt bzw. aufgefallen ist.
Diese erste Email beschäftigt sich mit der Basisdaten-Tabelle unter

http://opengeodb.giswiki.org/wiki/OpenGeoDB_-_Dateninhalt#Basisdaten

Der ags wird nur für Gemeinden bzw. gemeindefreie Gebiete vergeben, in
der opengeodb taucht aber auch in übergeordneten Einträgen ein Eintrag
des AGS auf, nämlich der gemeinsame Teil aller Gemeinden innerhalb
dieses Eintrages.
Dies sollte auch hier in der Basisdaten-Beschreibung auftauchen.

WSG84-Koordinaten (200100000): dies ist in meiner hier lokal
installierten Version der einzige Typ, der in geodb_coordinates
überhaupt existiert. Was ist hier geplant? gibt es Alternativen, die
auch verwandt werden oder in Zukunft werden sollen?


Wo werden lat- (200200000) und lon- (200300000) Werte direkt verwand
(außer als zusammengesetzter Datentyp)?

500700001 (Sortiername eines Verwaltungszusammenschlusses) - soll dieser
Typ verwandt werden? Bisher existiert, soweit ich das sehen konnte, kein
Datensatz dieses Typs.

Sind Postleitzahlen generell Ganzzahlen? Bisher tauchen, wenn ich keinen
Fehler gemacht habe, nur ganze Zahlen auf und das deckt sich mit meinem
Wissen über PLZs in D, A und CH, sicher bin ich mir aber grade nicht.

In welcher Einheit werden Flächen gerechnet? Der Typ 610000000 sagt dazu
ja noch nichts.

unabhängig von der Doku: ist Ebene genau die Information, die sich
früher/alternativ in der hierarchies wiederfinden sollte? Das wäre die
Schlüsselinformation, um ein SQL-Script zur Generierung zusammenzubauen.

Was ist mit dem tab-Feld "invalid"? Wie kommt das da vor, wieso taucht
das in SQL nicht mehr auf etc?

Weitere Emails folgen wahrscheinlich gleich noch, aber sonst wird das zu
lang am Stück, denke ich.

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

[Martin Trautmann]

Peter Wendorff wrote:

> Und nochmal hallo.
> Ich gehe grade die Dokumentation nochmal genauer durch, und werde hier
> einfach mal auflisten, was mir noch auffällt bzw. aufgefallen ist.
> Diese erste Email beschäftigt sich mit der Basisdaten-Tabelle unter
>
> http://opengeodb.giswiki.org/wiki/OpenGeoDB_-_Dateninhalt#Basisdaten
>
> Der ags wird nur für Gemeinden bzw. gemeindefreie Gebiete vergeben, in
> der opengeodb taucht aber auch in übergeordneten Einträgen ein Eintrag
> des AGS auf, nämlich der gemeinsame Teil aller Gemeinden innerhalb
> dieses Eintrages.
> Dies sollte auch hier in der Basisdaten-Beschreibung auftauchen.

? AGS gibt es für das Bundesland bis hinunter zur Gemeinde.

> WSG84-Koordinaten (200100000): dies ist in meiner hier lokal
> installierten Version der einzige Typ, der in geodb_coordinates
> überhaupt existiert. Was ist hier geplant? gibt es Alternativen, die
> auch verwandt werden oder in Zukunft werden sollen?

Nein.

> Wo werden lat- (200200000) und lon- (200300000) Werte direkt verwand
> (außer als zusammengesetzter Datentyp)?

Nur zur Versionierung

> 500700001 (Sortiername eines Verwaltungszusammenschlusses) - soll dieser
> Typ verwandt werden? Bisher existiert, soweit ich das sehen konnte, kein
> Datensatz dieses Typs.

Er ist vorbereitet, derzeit aber ungenutzt.

> Sind Postleitzahlen generell Ganzzahlen? Bisher tauchen, wenn ich keinen
> Fehler gemacht habe, nur ganze Zahlen auf und das deckt sich mit meinem
> Wissen über PLZs in D, A und CH, sicher bin ich mir aber grade nicht.

Denkbar sind auch z.B. wildcards wie 88*** oder 80***/81***

Faktisch haben wir das nicht. PLZ sind aber keine Ganzzahlen, weil eine
führende Null möglich ist.

> In welcher Einheit werden Flächen gerechnet? Der Typ 610000000 sagt dazu
> ja noch nichts.

Gehört eher in die Detail-Doku: km^2

> unabhängig von der Doku: ist Ebene genau die Information, die sich
> früher/alternativ in der hierarchies wiederfinden sollte? Das wäre die
> Schlüsselinformation, um ein SQL-Script zur Generierung zusammenzubauen.

Ja
>
> Was ist mit dem tab-Feld "invalid"? Wie kommt das da vor, wieso taucht
> das in SQL nicht mehr auf etc?

weil damit ungültige Einträge markiert werden. Beim Dump werden die ganz
ausgeblendet. Für wiki und undelete bleiben sie aber im .tab drin.

> Weitere Emails folgen wahrscheinlich gleich noch, aber sonst wird das zu
> lang am Stück, denke ich.

Gerne - mit etc alleine ist die Anfrage recht unspezifisch.
--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Stephan Schuster]

Hallo Peter,

> Sind Postleitzahlen generell Ganzzahlen? Bisher tauchen, wenn ich keinen
> Fehler gemacht habe, nur ganze Zahlen auf und das deckt sich mit meinem
> Wissen über PLZs in D, A und CH, sicher bin ich mir aber grade nicht.

PLZ sollten als String gespeichert werden, außer dass es in Deutschland
führende Nullen gibt, verwendet England beispielsweise Postleitzahlen
mit wilden Mischungen aus Buchstaben, Zahlen und einem Leerzeichen.

Ich habe mir gerade deine Änderungen angesehen und finde die Angabe des
Datentyps sehr gut, allerdings würde ich dort auch nur den Typ angeben,
also integer, string, double etc. Die genaue Erklärung (Zahl mit
führender 0) würde ich dann weiter unten bei den Beschreibungen angeben
und evtl. mit einem Fußnoten-Link kennzeichnen.

Gruß
Stephan
--
Stephan Schuster <stephan.s@...>

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

[Peter Wendorff]

Teil 2 meiner Anmerkungen:
1) http://opengeodb.giswiki.org/wiki/Datenbank_erstellen

Bei Schritt 2 sollte davor gewarnt werden, dass der Import sehr lange
dauern kann und phpmyadmin und andere HTTP-gebundene Importmöglichkeiten
damit Probleme haben können. (oder ist das nicht mehr aktuell - ich hab
das noch so im Kopf, dass es damit mal Probleme gab)

2) http://opengeodb.giswiki.org/wiki/Datenbank_der_OpengeoDB#Allgemein

In der Tabelle wird behauptet, es gäbe nur einen Eintrag vom Typ
Staat/Land. Ich schlage vor, dies für die vollständige opengeodb, dann
nämlich mit allen verfügbaren Staaten, durchzuführen. Das Ergebnis in
meiner lokalen Datenbank verwundert mich allerdings auch - stimmt die
SQL-Query - ich sehe keinen Fehler, aber woher kommt folgendes Ergebnis?
Mein Ergebnis:

type_id           name                             amount
1                     beliebig                                 2
100100000     Erdteil                                 14
100200000     Staat/Land                            5
100300000     Kanton                               332
100400000     Regierungsbezirk             223
100500000     Landkreis                        2841
100600000     Politische Gliederung   15688
100700000     Ortschaft                       20506
100800000     Postleitzahlgebiet           1220
NULL     NULL                                        1151

Genauere Analyse anhand der Erdteile ergibt:
1. sind alle Erdteile in der geodb vorhanden (zumindest in der bei mir
installierten Version)
2. werden bei der angegebenen Abfrage auch weitere Sprachvarianten
mitgezählt, was die Abfrage damit irgendwie noch nicht voll einsatzfähig
macht.

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?

Bei geodb_hierarchies habe ich vermerkt, dass und warum diese Tabelle im
Dump momentan leer ist.

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

[Stephan Schuster]

Hallo Peter

> Teil 2 meiner Anmerkungen:
> 1) http://opengeodb.giswiki.org/wiki/Datenbank_erstellen
>
> Bei Schritt 2 sollte davor gewarnt werden, dass der Import sehr lange
> dauern kann und phpmyadmin und andere HTTP-gebundene Importmöglichkeiten
> damit Probleme haben können. (oder ist das nicht mehr aktuell - ich hab
> das noch so im Kopf, dass es damit mal Probleme gab)

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.

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.

>
> 2) http://opengeodb.giswiki.org/wiki/Datenbank_der_OpengeoDB#Allgemein
>
> In der Tabelle wird behauptet, es gäbe nur einen Eintrag vom Typ
> Staat/Land. Ich schlage vor, dies für die vollständige opengeodb, dann
> nämlich mit allen verfügbaren Staaten, durchzuführen. Das Ergebnis in
> meiner lokalen Datenbank verwundert mich allerdings auch - stimmt die
> SQL-Query - ich sehe keinen Fehler, aber woher kommt folgendes Ergebnis?
> Mein Ergebnis:
>
> type_id           name                             amount
> 1                     beliebig                                 2
> 100100000     Erdteil                                 14
> 100200000     Staat/Land                            5
> 100300000     Kanton                               332
> 100400000     Regierungsbezirk             223
> 100500000     Landkreis                        2841
> 100600000     Politische Gliederung   15688
> 100700000     Ortschaft                       20506
> 100800000     Postleitzahlgebiet           1220
> NULL     NULL                                        1151
>
> Genauere Analyse anhand der Erdteile ergibt:
> 1. sind alle Erdteile in der geodb vorhanden (zumindest in der bei mir
> installierten Version)

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.


> 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 ;-)

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

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)

> 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?
Soll das dann eine Reihe von Abfragen enthalten, oder wird das per
Programmierung gelöst? 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.

Gruß
Stephan

--
Stephan Schuster <stephan.s@...>

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

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

[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

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

[Peter Wendorff]

Teil 3 meiner Anmerkungen:
http://opengeodb.giswiki.org/wiki/OpenGeoDB_-_Umkreissuche

Bei den Allgemeinen Überlegungen wird das "obige Beispiel Berlin"
genannt - was heißt jetzt obig? in
http://opengeodb.giswiki.org/wiki/Beispiele taucht ein Beispiel mit
Berlin auf, das aber auch nicht einmal das letzte auf der entsprechenden
Seite ist. Abgesehen davon ist ein Wiki eben nicht unbedingt zum
linearen Lesen gedacht, was diese Formulierung hier unsinnig macht. Fürs
Wiki würde ich das jedenfalls verlinken.

Beim Erstellen der Datenbasis ist die SQL-Anweisung zur Erzeugung des
Index noch unvollständig, oder?

Die Überlegung, sämtliche Entfernungen zu berechnen, sagt mir
andererseits auch, dass dies eine Tabelle mit bei meiner Datenlage 1 Mio
Datensätzen, vollständig werden das wesentlich mehr sein, weil mehr als
die bei mir vorhandenen 1220 PLZ-Gebiete existieren.
Ob unter diesen Umständen diese Überlegung noch sinnvoll ist, bleibt
fraglich - auch dieser Aspekt sollte jedenfalls dabei erwähnt werden.

Außerdem wäre es praktisch, ein Gesamt-SQL-Script zu basteln, das bei
Angabe einer locid die Orte in einer Entfernung von x km ausspuckt.


Ich muss gleich erstmal zum Jonglage-Training, deshalb irgendwann später
mehr.

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

[Stephan Schuster]

Hallo Peter,

> Bei den Allgemeinen Überlegungen wird das "obige Beispiel Berlin"
> genannt - was heißt jetzt obig? in
> http://opengeodb.giswiki.org/wiki/Beispiele taucht ein Beispiel mit
> Berlin auf, das aber auch nicht einmal das letzte auf der entsprechenden
> Seite ist. Abgesehen davon ist ein Wiki eben nicht unbedingt zum
> linearen Lesen gedacht, was diese Formulierung hier unsinnig macht. Fürs
> Wiki würde ich das jedenfalls verlinken.

ok, ich hab das jetzt einfach allgemeiner formuliert, ich denke so
sollte jedem klar sein, was gemeint ist. Ansonsten fühl dich in solchen Fällen frei
den Text zu korrigieren, dass es deiner Meinung nach präziser ist. Ich
hänge da nicht am Wortlaut, ich denke du weisst in einem solchen Fall
was eigentlich gemeint ist.
 
> Beim Erstellen der Datenbasis ist die SQL-Anweisung zur Erzeugung des
> Index noch unvollständig, oder?

Ja, ich bin noch nicht dazu gekommen zu testen, welcher Index hier am
effizientesten ist...

> Die Überlegung, sämtliche Entfernungen zu berechnen, sagt mir
> andererseits auch, dass dies eine Tabelle mit bei meiner Datenlage 1 Mio
> Datensätzen, vollständig werden das wesentlich mehr sein, weil mehr als
> die bei mir vorhandenen 1220 PLZ-Gebiete existieren.
> Ob unter diesen Umständen diese Überlegung noch sinnvoll ist, bleibt
> fraglich - auch dieser Aspekt sollte jedenfalls dabei erwähnt werden.

Diese Überlegung ist aus meiner Sicht nur dann nicht sinnvoll, wenn es
tatsächlich um Plattenplatz geht. Für eine Datenbank ist es kein Problem,
aus einer Tabelle mit 10 mio. Einträgen die passenden heraus zu suchen
(einen vernünftigen Index vorrausgesetzt), aber die Laufzeit des
Beispielskripts auf einem unbelasteten Testsystem zeigt hier schon die
Grenzen einer Berechnung zur Laufzeit über alle Datensätze auf:
9 rows in set (0.04 sec).

Allerdings finde ich den Ansatz von Martin ebenfalls interessant, die
Auswahl vorher über die maximal / minimal in Frage kommenden lat und lon
einzuschränken. Wie würde denn hierfür die Berechnung aussehen, also wie
komme ich vom Umkreis-Radius auf die entsprechenden lat- / lon-Werte?
Ich bin da nicht so firm ;-)

Gruß
Stephan

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

[Martin Trautmann]

Stephan Schuster wrote:

> Allerdings finde ich den Ansatz von Martin ebenfalls interessant, die
> Auswahl vorher über die maximal / minimal in Frage kommenden lat und lon
> einzuschränken. Wie würde denn hierfür die Berechnung aussehen, also wie
> komme ich vom Umkreis-Radius auf die entsprechenden lat- / lon-Werte?
> Ich bin da nicht so firm ;-)

Du musst einfach die Formel passend umstellen:

Die Abweichung um deinen Sollwert bekommst du mit lon +- d_lon und
lat +- d_lat. earth ist der Erdradius...

d_lon =
abs(acos(
     (cos(distance/earth) - sin(lat)*sin(lat)) /
     (cos(lat)*cos(lat)))
    *45/atan(1))

d_lat =
abs((distance/earth)*45/atan(1))
--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Thomas Bornhaupt]

Hallo,

kleine Anmerkung.

Die Navies bilden die WGS84 Koordinaten auf integer ab und machen die gesamten Berechnungen bei suchen nach Punkten in integer.

Gruß
Th