• Willkommen im Geoclub - dem größten deutschsprachigen Geocaching-Forum. Registriere dich kostenlos, um alle Inhalte zu sehen und neue Beiträge zu erstellen.

[DEV] cache.xml bzw. CacheHolderDetail erweitern

MiK

Geoguru
Hallo,

um wirklich GC-kompatible GPX im speziellen auch MyFinds zu generieren benötigen wir ein paar zusätzliche Daten pro Cache. Wie müssten diese eingebaut werden um abwärtskompatibel zu bleiben? Welche Informationen sollten nur in die cache.xml und welche sollten auch in die index.xml? Welche Probleme können jeweils entstehen?

Meiner Meinung nach, sollten Erweiterungen nur in der cache.xml problemlos sein. Dann würden die Daten aber nicht in der Listendarstellung und zum Filtern zur Verfügung stehen. Sehe ich das richtig?

Hier meine (vorläufige) Liste mit ein paar Bemerkungen dazu:
- cache-Id: Diese ist auf jeden Fall nötig um kompatible GPX zu erzeugen. Sie muss aber nicht in den Index. Für OC bekommen wir sie wohl mitgeliefert. Für GC müssen wir sie entweder spidern oder einfach aus dem Wegpunkt berechnen.

- owner-Id: Ich weiß noch nicht, wie wir einfach an die kommen. Aber sie ist auch erstmal nicht nötig. Vielleicht sollten wir sie aber trotzdem vorsehen

- country und state: Das sind auf jeden Fall interessante Felder, die z.B. auch für ein Filtern vor dem Kartendownload nützlich sein können. Deswegen müssten sie wohl mit in die index.xml. Was meint ihr?

- log-Id: die ID des eigenen Logs (falls vorhanden). Einige Statistikprogramme funktionieren nur zuverlässig, wenn im FyFind-GPX dort die richtigen IDs stehen. Da wir diese aber nur zum Export benötigen, genügt ein Eintrag in der cache.xml. Dort sollten wir auch irgendwo hinterlegen, welches das eigene Log ist oder dessen Text nochmal duplizieren.

- finder-Id: Das ist wohl meist die eigene Id. Diese würde ich dann eher in den Preferences eingeben lassen.

Wisst ihr noch weitere Daten, die wir aufnehmen sollten? Was spricht gegen meine obigen Überlegungen? Ich denke, es ist wichtig, dass wir eine solche Datenumstrukturierung gut durchdenken, damit wir danach keine größeren Kompatiblitätsprobleme mit alten Dateien bekommen und auch möglichst alles anliegende auf einmal erledigen, so dass wir nicht bald noch einmal ran müssen.
 

greiol

Geoguru
mal ein paar ideen dazu:
  • die einzige notwendigkeit nach ländern in der übersicht zu filtern wäre "sicherzustellen" dass alle caches im bereich eines webmapservices für ein bundesland liegen
  • im gegenzug würden voll ausgeschriebene state/country informationen in der index.xml diese ziemlich aufblähen
  • eine lösung wäre eine state/country liste damit im index nur eine kennziffer auftaucht
  • die liste bedeutet bei zentraler erstellung pflegeaufwand
  • die liste könnte dezentral gefüllt werden. taucht ein state/country zum ersten mal bei einem cacher auf wird er in die indexliste geschrieben und bekommt eine autoincrementnummer. allerdings funktioniert eine index,xml dann immer nur mit genau der persönlichen state/country liste vernünftig
  • in den cache.xml und der index.xml sollte eine versionsinfo mit abgespeichert werden, damit alte cachewolf versionen erkennen, dass sie mit der datei nichts anfangen können
  • so wie ich mir gerade für die 0.9 nach 1.0 konvertierung ein tool baue, könnte man eines für die konvertierung 0.9 nach 1.0 zur verfügung stellen.
  • da es nur einmal laufen müsste, könnte man sich die konvertierung im cw sparen und ihn entsprechend schlanker halten
 
OP
MiK

MiK

Geoguru
greiol schrieb:
mal ein paar ideen dazu:
[*] die einzige notwendigkeit nach ländern in der übersicht zu filtern wäre "sicherzustellen" dass alle caches im bereich eines webmapservices für ein bundesland liegen
Wobei es dann beim Kacheln eines Bereichs trotzdem noch zu weißen Kacheln kommen kann. Vielleicht sollten wir uns an der Stelle etwas intelligentes überlegen und es aus der index.xml raus halten. In der Tabelle nimmt es wohl sowieso meist nur Platz weg.
greiol schrieb:
[*] im gegenzug würden voll ausgeschriebene state/country informationen in der index.xml diese ziemlich aufblähen
[*] eine lösung wäre eine state/country liste damit im index nur eine kennziffer auftaucht
[*] die liste bedeutet bei zentraler erstellung pflegeaufwand
Eine solche Liste halte ich für zu aufwendig und fehleranfällig. Ich glaube auch nicht, dass es viel bringt. Der Aufwand zum Einlesen korreliert eher mit der Anzahl der Elemente als mit der Textlänge. Und das bisschen Speicherplatz macht den Kohl wirklich nicht fett.

greiol schrieb:
[*] in den cache.xml und der index.xml sollte eine versionsinfo mit abgespeichert werden, damit alte cachewolf versionen erkennen, dass sie mit der datei nichts anfangen können
[*] so wie ich mir gerade für die 0.9 nach 1.0 konvertierung ein tool baue, könnte man eines für die konvertierung 0.9 nach 1.0 zur verfügung stellen.
[*] da es nur einmal laufen müsste, könnte man sich die konvertierung im cw sparen und ihn entsprechend schlanker halten
Eine Versionsnummer kann auf jeden Fall nicht schaden. Wenn wir uns aber auf Änderungen in der cache.xml beschränken sollte es keine Abwärtskompatiblitätsprobleme geben. Die neuen Felder werden mit einem Default vorbelegt und wenn sie nicht da sind, dann sind sie halt nicht da. Eine Konvertierung ist dabei nicht notwendig. Nur wenn man die neuen Informationen nutzen möchte, muss man die Caches eben aktualisieren. So war es z.B. auch bei der Einführung der Attribute.
 

salzkammergut

Geomaster
Mik schrieb:
um wirklich GC-kompatible GPX im speziellen auch MyFinds zu generieren benötigen wir ein paar zusätzliche Daten pro Cache.
Da habe ich schon die erste Frage: Was soll CW sein? Eine abgespeckte Version von GSAK? Oder eine schlanke (?!) Software die primär "paperless Caching" ermöglicht und daher sich auf dafür wesentliche Funktionen konzentriert? Warum brauchen wir die "myFinds"? Kann man das nicht auch mit Geolog oder anderer Software machen?

Ich bin noch nicht überzeugt, dass diese zusätzlichen Felder (cache-id, owner-id, log-id, finder-id) wirklich notwendig sind, sie blähen den Code auf, kosten am PDA wertvollen Speicherplatz (vor allem wenn sie in der index.xml stehen), kosten Zeit beim Einlesen usw. Wenn sie andererseits in der cache.xml stehen, sehe ich Probleme mit der Geschwindigkeit, weil dann immer die alle cache.xml Dateien gelesen und geparst werden müssen um ein Feld zu lesen. Dann müßte man schon mal überlegen auf eine Datenbank umzusteigen.

Mik schrieb:
Vielleicht sollten wir uns an der Stelle etwas intelligentes überlegen und es aus der index.xml raus halten. In der Tabelle nimmt es wohl sowieso meist nur Platz weg.
Sehe ich genau so. Country/state könnten bei den Mapservices hilfreich sein - da wäre zu prüfen ob das nicht auch ohne eine Erweiterung der index.xml geht.

greiol schrieb:
in den cache.xml und der index.xml sollte eine versionsinfo mit abgespeichert werden, damit alte cachewolf versionen erkennen, dass sie mit der datei nichts anfangen können
Das steht auch bei mir schon lange auf der Liste, damit man auch mal eine Änderung machen kann, die nicht abwärtskompatibel ist, aber z.B. einen deutlichen Zeitgewinn verspricht.

Weiters würde ich am Anfang der index.xml auch die Anzahl der Wegpunkte ablegen, damit in der cacheDB gleich die richtige Anzahl von Einträgen erzeugt werden kann und nicht während des Einlesens der Vector mehrfach umkopiert werden muß. Wenn ich mich richtig erinnere weist EWE einem Vector zunächst 8 Plätze, dann 16, dann 32 usw. zu.

Mik schrieb:
Der Aufwand zum Einlesen korreliert eher mit der Anzahl der Elemente als mit der Textlänge.
Ja, jedes Objekt das erzeugt wird (also auch zusätzliche Strings, die im CacheHolder gespeichert werden) kostet Zeit.

Ich würde überlegen die index.xml in einem internen (serialized) Format zu speichern, das sollte eigentlich schneller gehen, müßte aber mal getestet werden. Für die index.xml kommen dann je ein Exporter und ein Importer dazu. Wenn also diese Umstellung gemacht wird (weil sie vor allem am PDA Geschwindigkeit bringt), dann muß man halt für jedes Profil einmalig die index.xml importieren - das ist durchaus machbar.

Grüße
skg
 
OP
MiK

MiK

Geoguru
salzkammergut schrieb:
Mik schrieb:
um wirklich GC-kompatible GPX im speziellen auch MyFinds zu generieren benötigen wir ein paar zusätzliche Daten pro Cache.
Da habe ich schon die erste Frage: Was soll CW sein? Eine abgespeckte Version von GSAK? Oder eine schlanke (?!) Software die primär "paperless Caching" ermöglicht und daher sich auf dafür wesentliche Funktionen konzentriert? Warum brauchen wir die "myFinds"? Kann man das nicht auch mit Geolog oder anderer Software machen?
Es geht dabei nicht nur um MyFinds, sondern z.B. auch um den Export für Garmins. Gerade die neueren Modelle sind da recht pingelig. Und ich finde diese Lösung auf jeden Fall besser als selbst noch Statistiken zu generieren, wie es auch schon gewünscht wurde. Deswegen würde ich hier lieber kleinere Erweiterungen machen um sagen zu können: Wir exportieren in ein verbreitetes Format. Damit könnt ihr dann weiterarbeiten.

salzkammergut schrieb:
Ich bin noch nicht überzeugt, dass diese zusätzlichen Felder (cache-id, owner-id, log-id, finder-id) wirklich notwendig sind, sie blähen den Code auf, kosten am PDA wertvollen Speicherplatz (vor allem wenn sie in der index.xml stehen), kosten Zeit beim Einlesen usw.
Die cache-id hat sich schon erledigt. Für OC haben wir die sowieso schon drin und für GC können wir sie aus dem Wegpunkt berechnen. Die owner-id können wir auch erstmal vergessen. Die finder-id würde ich nur für eigene Finds angeben und kann damit über eine Pref gelöst werden. Bleibt als Id also nur noch die Id des eigenen Fund-Logs.

salzkammergut schrieb:
Wenn sie andererseits in der cache.xml stehen, sehe ich Probleme mit der Geschwindigkeit, weil dann immer die alle cache.xml Dateien gelesen und geparst werden müssen um ein Feld zu lesen. Dann müßte man schon mal überlegen auf eine Datenbank umzusteigen.
Für den Export muss die cache.xml sowieso eingelesen werden. Nach meinem bisherigen Plan kämen dort country, state, eigene LogId und der eigene Logtext dazu. Das letzte braucht wohl am meisten Platz, wenn man es auch noch mal in den normalen Logs hat. Vielleicht kann man das auch mit einem Link lösen. Alternativ könnte man auch das Note-Feld dafür benutzen. Eigentlich ist das sowieso überflüssig, da man genausogut den Solver dafür nutzen kann.

salzkammergut schrieb:
Mik schrieb:
Vielleicht sollten wir uns an der Stelle etwas intelligentes überlegen und es aus der index.xml raus halten. In der Tabelle nimmt es wohl sowieso meist nur Platz weg.
Sehe ich genau so. Country/state könnten bei den Mapservices hilfreich sein - da wäre zu prüfen ob das nicht auch ohne eine Erweiterung der index.xml geht.
Ich würde im ersten Schritt für meine Erweiterungen (country, state, Log-Id und -Text) nur die cache.xml nutzen. Falls es später sinnvoll erscheint, kann man das noch in den index ziehen. Aus Performancegründen würde ich aber vorerst darauf verzichten.
 

Haehnchen

Geocacher
Hallo,
für das Templet "field notes"
http://www.geoclub.de/viewtopic.php?f=40&t=31542
braucht man eine neue Variable "log-typ" in der je nach Cachetyp (Tradi, Webcam, Event) die Logtypen einzutragen sind
zB. Found it, not found, write note, Webcam Photo taken, Attended....
Man braucht auch für jeden Log Datum und Zeit.
Vielleicht kann man unter "Details" den Kalender vom Status so erweitern,
das man dort die möglichen Logtypen als Icon mit einbindet (je nach Cachetype GC, OC).
Thomas
 
OP
MiK

MiK

Geoguru
Dies wird wohl alleine über das Status-Feld gelöst werden. Dazu brauchen wir wahrscheinlich keine Änderung der Datenstruktur.
 
Oben