Welche Daten sind die aktuellsten?

[Felix Schwarz-5]

Hallo,

ich möchte den Datenbestand der OpenGeoDB für eine Applikation evaluieren. Nach Durchsicht des
Mailing-Listen-Archivs und etwas gegoogelt habe, scheint der "ADFC-Dump" derzeit die aktuellsten
Daten zu beinhalten und auch am besten gepflegt zu werden.

Leider gibt es unter http://fa-technik.adfc.de/code/opengeodb/ viele verschiedene Dateien, deren
Sinn sich mir nicht direkt erschließt. Ich hätte gerne einen SQL-Dump, den ich automatisiert
importieren kann. Unter http://fa-technik.adfc.de/code/opengeodb/dump/ gibt es MySQL-Dumps,
allerdings ist mir nicht klar, worin sich die dumps unterscheiden - bzw. genauer: /worin/ sie
sich unterscheiden, sehe ich im diff, nur /welchen/ Zweck erfüllen die Unterschiede?

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

[Felix Schwarz-5]

Noch ein paar ergänzende Fragen zum Datenbestand:

Nachdem ich opengeodb-0251_2007-10-02.sql aus dem ADFC-Bestand importiert
habe, gibt es mehrere Datensätze, die für mich keinen Sinn ergeben, z.B.
loc_id 23519.

mysql> select loc_id, lon, lat, valid_since, valid_until from geodb_coordinates where loc_id = 23519;
+--------+------------------+------------------+-------------+-------------+
| loc_id | lon              | lat              | valid_since | valid_until |
+--------+------------------+------------------+-------------+-------------+
|  23519 | 11.2440571428571 | 51.5083285714286 | NULL        | 3000-01-01  |
|  23519 |          51.4667 |             11.3 | NULL        | 2005-09-30  |
|  23519 | 51.5083285714286 | 11.2440571428571 | 2005-12-01  | 3000-01-01  |
|  23519 | 51.5089692307692 | 11.2346230769231 | 2005-10-01  | 2005-11-30  |
+--------+------------------+------------------+-------------+-------------+

Laut GeoDatenZentrum ist der erste Eintrag in etwa richtig. Warum ist der 3. dann
nicht abgelaufen bzw. wie kann man algorithmisch entscheiden, dass der erste richtig
ist?

Ähnliches scheint bei allen IDs zu gelten, die die Abfrage
  select * from geodb_coordinates where date_type_since is not null;
zurückliefert.

Nur in opengeodb-02510_2007-10-02.sql ist der Eintrag offenbar richtig, da dort
auch nur ein Datensatz für die o.g. loc_id besteht. Leider lässt sich diese Datei
nicht in MySQL importieren:
$ mysql --user=root opengeo < opengeodb-02510_2007-10-02.sql
ERROR 1136 (21S01) at line 232: Column count doesn't match value count at row 1

Gibt es da Abhilfe bzw. mit welchem Datenbestand habt ihr gute Erfahrungen gemacht?

Vielen Dank,
Felix Schwarz

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

[Martin Trautmann]

Felix Schwarz wrote:
> Hallo,
>
> ich möchte den Datenbestand der OpenGeoDB für eine Applikation evaluieren. Nach Durchsicht des
> Mailing-Listen-Archivs und etwas gegoogelt habe, scheint der "ADFC-Dump" derzeit die aktuellsten
> Daten zu beinhalten und auch am besten gepflegt zu werden.

Hallo Felix,

die sourceforge-release entsprach diesen Daten.

> Leider gibt es unter http://fa-technik.adfc.de/code/opengeodb/ viele verschiedene Dateien, deren
> Sinn sich mir nicht direkt erschließt. Ich hätte gerne einen SQL-Dump, den ich automatisiert
> importieren kann. Unter http://fa-technik.adfc.de/code/opengeodb/dump/ gibt es MySQL-Dumps,
> allerdings ist mir nicht klar, worin sich die dumps unterscheiden - bzw. genauer: /worin/ sie
> sich unterscheiden, sehe ich im diff, nur /welchen/ Zweck erfüllen die Unterschiede?

Es waren verschiedene Versionen, die jeweils durch Fehlerrückmeldungen
kurzfristig hintereinander entstanden. 025 verlinkt auf die letzte 0253,
die auch der auf sourceforge entspricht.

Vor kurzem erstellte ich für dich eine neue 026, Erklärung dazu separat.

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

[Martin Trautmann]

Felix Schwarz wrote:

> Noch ein paar ergänzende Fragen zum Datenbestand:
>
> Nachdem ich opengeodb-0251_2007-10-02.sql aus dem ADFC-Bestand importiert
> habe, gibt es mehrere Datensätze, die für mich keinen Sinn ergeben, z.B.
> loc_id 23519.
>
> mysql> select loc_id, lon, lat, valid_since, valid_until from geodb_coordinates where loc_id = 23519;
> +--------+------------------+------------------+-------------+-------------+
> | loc_id | lon              | lat              | valid_since | valid_until |
> +--------+------------------+------------------+-------------+-------------+
> |  23519 | 11.2440571428571 | 51.5083285714286 | NULL        | 3000-01-01  |
> |  23519 |          51.4667 |             11.3 | NULL        | 2005-09-30  |
> |  23519 | 51.5083285714286 | 11.2440571428571 | 2005-12-01  | 3000-01-01  |
> |  23519 | 51.5089692307692 | 11.2346230769231 | 2005-10-01  | 2005-11-30  |
> +--------+------------------+------------------+-------------+-------------+
>
> Laut GeoDatenZentrum ist der erste Eintrag in etwa richtig. Warum ist der 3. dann
> nicht abgelaufen bzw. wie kann man algorithmisch entscheiden, dass der erste richtig
> ist?

Der erste ist der aktuellste und richtige - er stammt aus D.tab und
wurde in SQL umgewandelt. Dabei wurden valid_since mit NULL und valid
until mit 3000-01-01 aufgefüllt.

Die nächsten drei Zeilen stammen aus der extra.sql, wo Daten mit Datum
hinterlegt sind. Dort hatte ich eigentlich die Reihenfolge schon auf das
gängigere lat/lon umgestellt - nur in der Umwandlung von tab nach sql es
bei der alten lon/lat belassen.

Die neue Datenstruktur kommt in Zukunft also mit lat,lon, daher auch die
neue 026-dump-Version.

So viel also zur Vertauschung von lon und lat in deiner Tabelle.

Die zweite Zeile stellt die ersten Koordinatenangaben dar: bis 2005-09-30
die vierte Zeile hat die Folgedaten: 2005-10-01 bis 2005-11-30
die dritte Zeile hat die seither gültigen Daten ab 2005-12-01.

Weil diese Daten ein Beginn-Datum haben, tauchen sie doppelt auf: einmal
ohne aus den D.tab-Rohdaten, einmal aus dem extra.sql

Wolltest du das bereinigen, so solltest du dir entsprechend die Daten
zusammenbasteln, z.B. indem du alle Daten ohne Begin-Datum wegwirfst,
wenn es dafür noch weitere Daten mit gültigen begin-until gibt. Das geht
zumindest, wenn die Inhalte identisch sind. Andernfalls kannst du
zusätzlich die changes.sql heranziehen, um festzustellen, wann sie
geändert wurden.


> Gibt es da Abhilfe bzw. mit welchem Datenbestand habt ihr gute Erfahrungen gemacht?

Wenn ich Rückmeldungen bekomme, dann kan ich dem teilweise Abhilfe
verschaffen.

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

[Felix Schwarz-5]

Martin Trautmann schrieb:
> Die neue Datenstruktur kommt in Zukunft also mit lat,lon, daher auch die
> neue 026-dump-Version.

Vielen Dank für die schnelle Hilfe.

--
Felix Schwarz
Software-Entwicklung und Beratung
Schwerpunkt: Sichere Datenbank-Anwendungen, Open-Source-Software-Entwicklung

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