GCgermany.db korrupt

Ist jemanden schon aufgefallen, dass die Datei http://home.debitel.net/user/geocaching/data/GCgermany.db.zip doppelte und falsche Eintraege enthaelt?

Seit laengerer Zeit habe ich die Datei mal wieder herunter geladen. Als ich sie in meine SQL-DB einlesen wollte bekam ich das hier:

Anfrage fehlgeschlagen: Duplicate entry 'GCT89Q' for key 3

Zum Vergrößern anklicken....

OK, Datei oeffnen, suche nach 'GCT89Q', und was finde ich: Die zweite GUID (6c7bbc15-1514-4219-b440-7f535e73fa47) gehoert aber dem Cache "Teufelstisch bei Hinterweidenthal/Pfalz by KaPsTeam" (GCRJBK) und den gibt es in der DCgermany.db gar nicht...

Beim genaueren hinlesen habe ich noch mehr solcher fehlerhaften Dubletten gefunden...

Ist das noch keinem aufgefallen?

mhh ist kein klassischer Dump.. wie bekommt man das ueberhaupt rein? Wie ist die Struktur? Hat Du mal den Link zur Erklaerungsseite der DB.. ichhab heut keine Lust auf Reverseengeneering ;-)

widdi schrieb:

mhh ist kein klassischer Dump..

Zum Vergrößern anklicken....

Dump wovon?

wie bekommt man das ueberhaupt rein?

Zum Vergrößern anklicken....

Wo rein?

Wie ist die Struktur? Hat Du mal den Link zur Erklaerungsseite der DB..

Zum Vergrößern anklicken....

Nein. Die Datei wurde frueher von GC.de per Spider erstellt. Dabei gab's ja immer wieder Probleme, weshalb ich die Verwendung des Files irgendwann mal eingestellt habe. Letztens bin ich wieder ueber den Link gestolpert und hab' mal wieder nachgesen... Aktuelles Datum, aber Ergebnis s. oben.
Auf der neuen GC.de wird von dem File nichts mehr erwaehnt (im Gegensatz zur alten). Ich meine mich allerdings zu erinnern, dass einige der Tools hier (GC-Scanner? Cachwolf?) auf dieser Datei aufbauen...

na Du meintest doch, dass Du das File in eine "SQL-DB" einlesen wolltest

Wenn ich dann zB an mySQL denke, kannst Du ja einen "dump" erstellen, der die Daten als Inserts nimmt und ein "Create Table" enthaelt

Mhh ueber ein Textfile import geht es auch - Trennzeichen ist Leerzeichen. Musst halt dann die Tabellenstruktur selber anlegen (Datentypen)

Auf der von Dir genannten Url ist das alte Design jedoch noch vorhanden

Noch mal zur Klarstellung:
Die Datei wurde frueher von GC.de zur Verfuegung gestellt und von einer Spider auf dem laufenden gehalten.
Ich habe mir hier ein eigenes Tool in PHP gebastelt, mit dem ich mir Overlays erstelle. Die Daten hatte ich mir immer ueber die Datei GCgermany.db besorgt. Die Datenbank selber ist von mir, d.h. ich lese die Datei zeilenweise aus und uebertrage die von mir benoetigten Werte in meine Datenbank.
Auf die Inkonsistenzen bin ich dadurch aufmerksam geworde, weil der Wert fuer den GC-Index (GCXXXX) in meiner DB als "unique" deklariert ist.

Ich habe keine Ahnung, ob und von wem diese Datei noch gepflegt wird (aktualisiert wird sie auf jeden fall). Dachte nur dass vielleicht noch jemand danderes mit der Datei arbeitet und dem etwas dazu einfaellt...

Du erstellst eigene Map-Overlays? spannend


mhh wenn es durch Spider geupdatet wurde, sollte es eigtl nicht vorkommen.

Ich konnte jetzt diese Waypoints rausziehen:

Feld10 Anzahl von Feld10
GCRMDM 2
GCT6R5 2
GCT35W 2
GCT89Q 2
GCT7J3 2
GCRK2N 2
GCT7Q9 2

bei mehreren Tausend Datensaetzen, sehe ich das noch als "normale Fehlerquote" an.

So.. jetzt habe ich mal selbst das Ganze importiert. Ich musste aber allesd auf "Text" zwingen, da sonst Importfehler auftraten.

Soweit so gut

Jetzt ist aber spannend was daraus wurde

Feld1 Feld2 Feld3 Feld4 Feld5 Feld6 Feld7 Feld8 Feld9 GCgermany.Feld10 Feld11 Feld12 Feld13 Feld0
341645 Felsenland Pfalz: 3. Die Pirmasenser Kanzel by KaPsTeam 2006 1 30 4,9185666667e+014 764985 Traditional Cache Small GCT89Q 6a9dc872-1c75-484e-9e66-e7492bed5015 1 2 GCT89Q
341645 Felsenland Pfalz: 3. Die Pirmasenser Kanzel by KaPsTeam 2006 1 30 4,9185666667e+014 764985 Traditional Cache Small GCT89Q 6c7bbc15-1514-4219-b440-7f535e73fa47 1 2 GCT89Q
341104 Stonehead by KAMABI 2006 1 29 5,0198416667e+014 84359 Multi-cache Small GCT7Q9 f557db03-47d4-4938-b59f-5474e9d075ac 38838 38838 GCT7Q9
341104 Stonehead by KAMABI 2006 1 29 5,0198416667e+014 84359 Multi-cache Small GCT7Q9 004df833-b8b6-4684-a516-30137ac4783d 38838 38838 GCT7Q9
340943 Burg Bentheim by Zwillis 2006 1 29 523028 7,1574666667e+014 Traditional Cache Micro GCT7J3 d223f7f3-7d62-4d3f-80b4-1d822f10bba9 1 1 GCT7J3
340943 Burg Bentheim by Zwillis 2006 1 29 523028 7,1574666667e+014 Traditional Cache Micro GCT7J3 461d77cd-0994-427c-928c-cfc6008d55fa 1 1 GCT7J3
340170 Gotteshäuser: Überwasserkirche Münster by jumala 2006 1 28 5,1963983333e+014 7,6225166667e+014 Traditional Cache Micro GCT6R5 e6fb5d6b-88cb-440d-a717-b387262eec60 1 1 GCT6R5
340170 Gotteshäuser: Überwasserkirche Münster by jumala 2006 1 28 5,1963983333e+014 7,6225166667e+014 Traditional Cache Micro GCT6R5 f55caddc-ef21-4496-b361-1dcb86c1f076 1 1 GCT6R5
336720 Gotteshäuser: Alte Synagoge in Essen by 7TCU+Spotter 2006 1 28 514568 7,0156166667e+014 Traditional Cache Micro GCT35W 403a8bd0-8afa-4468-929f-0c679ba552ce 38838 38838 GCT35W
336720 Gotteshäuser: Alte Synagoge in Essen by 7TCU+Spotter 2006 1 28 514568 7,0156166667e+014 Traditional Cache Micro GCT35W ee0d1a1d-ca2e-411b-a731-55ee3ae5c95b 38838 38838 GCT35W
323507 2.Event mit der Möglichkeit zur ASuKK by schlumbum 2006 1 20 5237215 9,7375666667e+014 Event Cache GCRMDM 8e522752-594e-4495-a49b-63f94331cdb6 1 38838 GCRMDM
323507 2.Event mit der Möglichkeit zur ASuKK by schlumbum 2006 1 20 5237215 9,7375666667e+014 Event Cache GCRMDM c9b48886-3ab6-433f-81f3-afd07f0454da 1 38838 GCRMDM
322206 MGCA 3. Licht by violaflöhe 2005 12 8 4,8152366667e+014 115921 Multi-cache Micro GCRK2N 307b18fd-9321-4241-88aa-19e7effdfb91 38838 1 GCRK2N
322206 MGCA 3. Licht by violaflöhe 2005 12 8 4,8152366667e+014 115921 Traditional Cache Micro GCRK2N 8f78b323-1f90-4e32-9c25-89ddf938cd96 38838 1 GCRK2N


Die hier erwaehnte "38838" steht auf der Position der Schwierigkeit. Ich vermute mal, das liegt am Import "1.5" usw.. dass Excel (nahm ich als Zwischenformat) das als Datum interpretiert hatte.. nicht dran stoeren

Die Datensaetze unterscheiden sich dann nur an der GUID

Feld11
6a9dc872-1c75-484e-9e66-e7492bed5015
6c7bbc15-1514-4219-b440-7f535e73fa47

f557db03-47d4-4938-b59f-5474e9d075ac
004df833-b8b6-4684-a516-30137ac4783d

d223f7f3-7d62-4d3f-80b4-1d822f10bba9
461d77cd-0994-427c-928c-cfc6008d55fa

e6fb5d6b-88cb-440d-a717-b387262eec60
f55caddc-ef21-4496-b361-1dcb86c1f076

403a8bd0-8afa-4468-929f-0c679ba552ce
ee0d1a1d-ca2e-411b-a731-55ee3ae5c95b

8e522752-594e-4495-a49b-63f94331cdb6
c9b48886-3ab6-433f-81f3-afd07f0454da

307b18fd-9321-4241-88aa-19e7effdfb91
8f78b323-1f90-4e32-9c25-89ddf938cd96


Diese sind im File jedenfalls eindeutig.

Ich vermute, dass der Spider auch nach der GUID vorgeht und durch irgendein Problem nicht weiterschaltete und daher dann bei den o.g,. Caches nochmal die Daten des vorhergefunden Cache eingetragen hat. Wohl ein Bug in der Fehlerbehandlung des Spiders, der stupide weitermacht, wenn er auf einen bestimmten Fehler trifft[/code]

Danke fuer die Analyse. Hab' nach der 3. Dublette aufgegeben weiter zu suchen. Wenn das nicht so viele sind, dann mache ich mir vielleicht die Arbeit eine Korrekturfunktion dafuer zu schreiben...

Danke schon mal.

PHerison schrieb:

Ich habe keine Ahnung, ob und von wem diese Datei noch gepflegt wird (aktualisiert wird sie auf jeden fall). Dachte nur dass vielleicht noch jemand danderes mit der Datei arbeitet und dem etwas dazu einfaellt...

Zum Vergrößern anklicken....

Vom neuen GC.de-Team darf eine solche Datei *nicht* mehr angeboten werden. Die von Groundspeak gestellten Bedingungen lassen das nicht zu.
Die unter dem hier genannten Link erhältliche db-Datei wird soweit ich weiß noch von Vinnies Spider aus den Zeiten der alten GC.de gefüllt, aber nicht mehr wirklich gepflegt. Es gab vor kurzem einen Thread im Geocache-Scanner-Unterforum zu dem Thema, wo er sich auch zu Wort gemeldet hatte.