[opengeodb] Welche Daten sind die aktuellsten?

[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