Der eine oder anderen von uns hat sich ja schon mal die Cache DB zerschossen und meist ist das kein so großer Beinbruch, denn man kann eine neue PQ erstellen und einspielen. Mit einer kleinen Ausnahme. Die Cachenotes. Sie existieren nur innerhalb des CW und können derzeit weder extrahiert noch zurück gespielt werden. Ich fände eine Backup und Restore Funktion für die Notes nicht schlecht.
-
Willkommen im Geoclub - dem größten deutschsprachigen Geocaching-Forum. Registriere dich kostenlos, um alle Inhalte zu sehen und neue Beiträge zu erstellen.
Export Notes , Import Notes
- Ersteller greiol
- Erstellt am
Für's Backup habe ich mir mal mit perl etwas gebastelt. Vielleicht hilft's ja jemandem.
Code:
#! /usr/bin/perl -w
eval 'exec /usr/bin/perl -S $0 ${1+"$@"}'
if 0; #$running_under_some_shell
use strict;
use File::Find ();
use XML::Simple;
use vars qw/*name *dir *prune/;
*name = *File::Find::name;
*dir = *File::Find::dir;
*prune = *File::Find::prune;
sub wanted;
File::Find::find({wanted => \&wanted}, '.');
exit;
sub wanted {
if ( /^.*\.xml\z/si && ! /^index\.xml\z/si ) {
my $ref = XMLin("./$_");
if (ref $ref->{NOTES} ne "HASH") {
open OUT, ">$_.note";
print OUT $ref->{NOTES},"\n";
close OUT;
}
}
}
pfeffer
Geowizard
wenn ich das irgendwo richtig gelesen habe, will Kalli die Notes als Feld im Exporter mit aufnehmen, sodass man die in einem mit template quasi beliebigem Format ausgeben kann.
Was mir noch wichtiger / am liebsten wäre:
Alle Änderungen (zusätzliche Wegpunkte, Notizen...) werden grundsätzlich irgendwo anders gespeichert, so dass man einfach neu heruntergeladene Caches in das Verzeichnis auf dem PDA kopieren kann, ohne dass am PDA gemachte Änderungen verlioren gehen.
Gruß,
Pfeffer.
Was mir noch wichtiger / am liebsten wäre:
Alle Änderungen (zusätzliche Wegpunkte, Notizen...) werden grundsätzlich irgendwo anders gespeichert, so dass man einfach neu heruntergeladene Caches in das Verzeichnis auf dem PDA kopieren kann, ohne dass am PDA gemachte Änderungen verlioren gehen.
Gruß,
Pfeffer.
Bilbowolf
Geowizard
Jetzt fällt mir auch ein, warum wir dies noch nicht implementiert haben. Die Idee ist ein Feuture zu integrieren, womit man die index.xml herstellen kann, wenn diese zerschossen wurde, einfach indem man die einzelnen cache.xml ausliest. Damit wäre das "Notes" - Problem ebenfalls berücksichtigt.
salzkammergut
Geomaster
An das mit der zerschossenen index.xml habe ich am Wochenende auch gedacht, als ich mir beim Testen der Dezimalkoordinaten dieses Datei zerschossen habe. 
@Bilbowolf: Ich glaube nicht, daß das doppelte Speichern von Daten ein Ladezeitproblem ergibt: Die index.xml wird ja dadurch nicht verändert, sondern nur die cache.xml Dateien, die aber beim Laden nicht gelesen werden.
Wenn wir ans Ende der cache.xml die in der index.xml gespeicherten Daten anhängen, wäre der Restore der index.xml kein Problem (würde ich aber in eine eigene Utility ausgliedern um CW nicht unnötig aufzublähen). Beim Lesen der cache.xml ist das kein zeitlicher Nachteil, weil diese Daten ja nicht gelesen werden müssen. Nur das Schreiben dauert minimal länger.
@Pfeffer: Das mit den zusätzlichen Dateien ist so eine Sache. Das Problem für mich ist die index.xml. Wenn ich am PC neu spidere, dann kopiere ich die Dateien mit neuem Datum auf den PDA. Was mache ich mit der index.xml am PDA? Eigentlich müßte ich die zuerst mit dem PC synchronisieren, ehe ich am PC neue Caches lade und sie dann wieder zum PDA kopieren. Nur vergesse ich das meist, bzw. habe den Cradle für den PDA nicht mit etc. Hier habe ich noch keine einfache Lösung.
Ich würde auch gerne zwei Zusatzfelder haben: Notes und Logs. Der Nutzen wäre wie folgt:
Notes sind irgendwelche Notizen, die eine Beziehung zum Cache haben (z.B. Hints zum Bonuscache einer Cache-Serie, der Zeitstempel, Infos die ich nicht verlieren will). Aber alles Daten, die nicht für die Öffentlichkeit bestimmt sind.
Logs sind die Texte, die man an GC oder OC senden will. D.h. Ich tippe meine Logs nicht mehr auf der GC Webseite sondern im CW (Das kann sowohl am PDA als auch am PC erfolgen). Dann gibt es einen Button, der alle noch nicht gesendeten Logs zu GC oder OC sendet (wobei da noch zu klären wäre wie man mit Travelbugs umgeht). Das würde sich vor allem bei mehreren Caches zeitlich auszahlen.
Sowohl Notes als auch Logs könnten in einer eigenen Datei gespeichert werden, da sie nur bei Bedarf im DetailPanel gelesen werden. Ich würde diese Datei im gleichen Verzeichnis wie die cache.xml Dateien halten, aber durch ein Dateinamenpräfix kennzeichnen, z.B. NOTE_GCXXYYZZ.xml. So bleibt sie von allfälligen Änderungen der index.xml bzw. cache.xml verschont. Die index.xml braucht dann vielleicht ein neues feld aka "unsent_log", welches beim Erstellen eines Logs gesetzt, und beim Senden zurückgesetzt wird. Filtern danach müßte auch möglich sein.
@Bilbowolf: Ich glaube nicht, daß das doppelte Speichern von Daten ein Ladezeitproblem ergibt: Die index.xml wird ja dadurch nicht verändert, sondern nur die cache.xml Dateien, die aber beim Laden nicht gelesen werden.
Wenn wir ans Ende der cache.xml die in der index.xml gespeicherten Daten anhängen, wäre der Restore der index.xml kein Problem (würde ich aber in eine eigene Utility ausgliedern um CW nicht unnötig aufzublähen). Beim Lesen der cache.xml ist das kein zeitlicher Nachteil, weil diese Daten ja nicht gelesen werden müssen. Nur das Schreiben dauert minimal länger.
@Pfeffer: Das mit den zusätzlichen Dateien ist so eine Sache. Das Problem für mich ist die index.xml. Wenn ich am PC neu spidere, dann kopiere ich die Dateien mit neuem Datum auf den PDA. Was mache ich mit der index.xml am PDA? Eigentlich müßte ich die zuerst mit dem PC synchronisieren, ehe ich am PC neue Caches lade und sie dann wieder zum PDA kopieren. Nur vergesse ich das meist, bzw. habe den Cradle für den PDA nicht mit etc. Hier habe ich noch keine einfache Lösung.
Ich würde auch gerne zwei Zusatzfelder haben: Notes und Logs. Der Nutzen wäre wie folgt:
Notes sind irgendwelche Notizen, die eine Beziehung zum Cache haben (z.B. Hints zum Bonuscache einer Cache-Serie, der Zeitstempel, Infos die ich nicht verlieren will). Aber alles Daten, die nicht für die Öffentlichkeit bestimmt sind.
Logs sind die Texte, die man an GC oder OC senden will. D.h. Ich tippe meine Logs nicht mehr auf der GC Webseite sondern im CW (Das kann sowohl am PDA als auch am PC erfolgen). Dann gibt es einen Button, der alle noch nicht gesendeten Logs zu GC oder OC sendet (wobei da noch zu klären wäre wie man mit Travelbugs umgeht). Das würde sich vor allem bei mehreren Caches zeitlich auszahlen.
Sowohl Notes als auch Logs könnten in einer eigenen Datei gespeichert werden, da sie nur bei Bedarf im DetailPanel gelesen werden. Ich würde diese Datei im gleichen Verzeichnis wie die cache.xml Dateien halten, aber durch ein Dateinamenpräfix kennzeichnen, z.B. NOTE_GCXXYYZZ.xml. So bleibt sie von allfälligen Änderungen der index.xml bzw. cache.xml verschont. Die index.xml braucht dann vielleicht ein neues feld aka "unsent_log", welches beim Erstellen eines Logs gesetzt, und beim Senden zurückgesetzt wird. Filtern danach müßte auch möglich sein.
pfeffer
Geowizard
Ich bin sehr dafür, Notes und Logs in einer eigenen Datei zu speichern. Das ist mir schon das wichtigste. Dann sind die wichtigsten selbst erzeugten Daten recht sicher.
Was dann noch fehlt: dass selbst erzeugte Wegpunkte erhalten bleiben. Dazu bietet sich auch das Verfahren von Salzkammergut an. Alledings mit folgender Zusatzfunktion:
Beim Laden des Profils checkt CachewOlf, ob eine cache.xml jünger ist als die index.xml (das geht schnell, weil dazu nicht jede Datei geöffnet werden muss, sondern das Datum aus dem Directorylisting hervorgeht). Falls ja: die index.xml wird automatisch neuerstellt und alle caches sind erhalten. Dann kann man einfach alle Dateien, bis auf die index.xml von einem auf den anderen Rechner schieben und alle Daten bleiben erhalten.
Gruß,
Pfeffer.
Was dann noch fehlt: dass selbst erzeugte Wegpunkte erhalten bleiben. Dazu bietet sich auch das Verfahren von Salzkammergut an. Alledings mit folgender Zusatzfunktion:
Beim Laden des Profils checkt CachewOlf, ob eine cache.xml jünger ist als die index.xml (das geht schnell, weil dazu nicht jede Datei geöffnet werden muss, sondern das Datum aus dem Directorylisting hervorgeht). Falls ja: die index.xml wird automatisch neuerstellt und alle caches sind erhalten. Dann kann man einfach alle Dateien, bis auf die index.xml von einem auf den anderen Rechner schieben und alle Daten bleiben erhalten.
Gruß,
Pfeffer.
salzkammergut
Geomaster
Nachtrag: Ich würde Notes und Logs in der gleichen Datei speichern, da sonst durch die Clustergröße relativ viel Platz am PDA verloren geht. Der Name der Datei ist dann halt INFO_GCXXYYZZ.xml o.Ä.
Was meint Ihr prinzipiell zur Idee zwischen Notes (=privat) und Logs (=öffentlich) zu differenzieren?
@Pfeffer: Die Idee finde ich gut, kann aber noch nicht Absschätzen wie sich das zeitlich auswirkt. Kann man bei allen PDAs ein nach Datum sortiertes Verzeichnis erstellen lassen wo man nur eine Datei überprüfen muß? Denn sonst muß man jede cache.xml einzeln anschauen, was bei 1400 caches die manche in ihrem Verzeichnis haben auch einige Zeit dauern dürfte. Eher dann schon unter Verwalten einen Menüeintrag "index.xml regenerieren".
Was meint Ihr prinzipiell zur Idee zwischen Notes (=privat) und Logs (=öffentlich) zu differenzieren?
@Pfeffer: Die Idee finde ich gut, kann aber noch nicht Absschätzen wie sich das zeitlich auswirkt. Kann man bei allen PDAs ein nach Datum sortiertes Verzeichnis erstellen lassen wo man nur eine Datei überprüfen muß? Denn sonst muß man jede cache.xml einzeln anschauen, was bei 1400 caches die manche in ihrem Verzeichnis haben auch einige Zeit dauern dürfte. Eher dann schon unter Verwalten einen Menüeintrag "index.xml regenerieren".
pfeffer
Geowizard
ewe hat ne Funktion (Files.list), die Dateien in einem Verzeichnis nach Datum sortiert in einem Array auszugeben (ob die natürlich auf allen Geräten funktioniert... aber mir fällt erstmal kein Grund ein, warum das auf manchen Geräten nicht gehen sollte.) Ich verwende die Ausgabe der Dateien in einem Verz in ein Array beim Einlesen der .wfl-Dateien.
Mir fällt grad ein: noch schöner und zeitlich vermutlich kaum aufwändiger: gucken, ob in dem Verzeichnis cach.xml drin sind, die im index.html nicht drin sind. Wenn man beides nach WPName sortiert, kann man sehr schnell feststellen, ob eine fehlt - äää noch einfacher: die Anzahl wäre ein guter Indikator. Dieses Verfahren hätte den Vorteil, dass man einfach alle Dateien inkl. index.xml (d.h. das ganze Verzeichnis) vom PC auf den PPC kopieren kann und dennoch auf dem PocketPC keine Daten verloren gehen.
Ja, beides in 1 Datei ist besser, Du hast recht. Würde aber eher "NotesLog_OC1234" nennen als "Info...".
Gruß,
Pfeffer.
Mir fällt grad ein: noch schöner und zeitlich vermutlich kaum aufwändiger: gucken, ob in dem Verzeichnis cach.xml drin sind, die im index.html nicht drin sind. Wenn man beides nach WPName sortiert, kann man sehr schnell feststellen, ob eine fehlt - äää noch einfacher: die Anzahl wäre ein guter Indikator. Dieses Verfahren hätte den Vorteil, dass man einfach alle Dateien inkl. index.xml (d.h. das ganze Verzeichnis) vom PC auf den PPC kopieren kann und dennoch auf dem PocketPC keine Daten verloren gehen.
Ja, beides in 1 Datei ist besser, Du hast recht. Würde aber eher "NotesLog_OC1234" nennen als "Info...".
Gruß,
Pfeffer.
salzkammergut
Geomaster
An die Anzahl habe ich auch gedacht. Die weiß man aber erst nach Lesen der index.xml wenn wir sie nicht am Anfang hinzufügen.
Kalli
Geowizard
Also ich würde das Regenerieren der index.xml nur als Notnagel sehen, wofür man eine extra Aktion auslösen muss. Dann würde ich so vorgehen:
- Datenbank im Speicher löschen
- Alle cache.xml einlesen
- index.xml neu schreiben
Man müsste natürlich einmal hergehen, und die kompletten cache.xml-Dateien neu generieren, wenn man das Feature eingebaut hat, damit die Infos auch in allen Cache.xml-Dateien drin ist.
Ich trage mich schon die ganze Zeit mit dem Gedanken rum, ob es nicht Sinn macht, eine Klasse zu schaffen, die für die ganzen Datenbank-Geschichten zuständig ist. Wir gehen zwar schon mittlerweile in die Richtung, haben aber verschiedene Klassen für die Index.xml und die Cache.xml. Dann könnte man sauberer mit add, insert, delete arbeiten, einen Index für die Datenbank halten (Hash-array), suchen etc. So haben wir viele Stellen im Code, wo insbesondere Suchfunktionen gemacht werden und auch ein Index neu erstellt wird. Diese Klasse könnte dann auch solche "Supportfunktionen" übernehmen.
- Datenbank im Speicher löschen
- Alle cache.xml einlesen
- index.xml neu schreiben
Man müsste natürlich einmal hergehen, und die kompletten cache.xml-Dateien neu generieren, wenn man das Feature eingebaut hat, damit die Infos auch in allen Cache.xml-Dateien drin ist.
Ich trage mich schon die ganze Zeit mit dem Gedanken rum, ob es nicht Sinn macht, eine Klasse zu schaffen, die für die ganzen Datenbank-Geschichten zuständig ist. Wir gehen zwar schon mittlerweile in die Richtung, haben aber verschiedene Klassen für die Index.xml und die Cache.xml. Dann könnte man sauberer mit add, insert, delete arbeiten, einen Index für die Datenbank halten (Hash-array), suchen etc. So haben wir viele Stellen im Code, wo insbesondere Suchfunktionen gemacht werden und auch ein Index neu erstellt wird. Diese Klasse könnte dann auch solche "Supportfunktionen" übernehmen.