Arbeitsweise mit CW

Mich würde interessieren wie ihr CW verwendet:

Wenn ich an einem neuen Ort geocachen will, so suche ich zunächst am PC die Koordinaten des Zentrums (mit Maporama o.ä.), lege dann ein Profil an und spidere die Caches in ein neues Verzeichnis. Dann kopiere ich dieses Verzeichnis auf meinen PDA. Jetzt muß ich auch am PDA noch dasselbe Profil erstellen und die Koordinaten des Zentrums noch einmal eintippen, ehe ich cachen kann.

Ich habe damit zwei Probleme:

1.) Die Anzahl von 4 Profilen ist mir zu wenig und ich muss immer wieder mühsam ein Profil temporär durch ein anderes ersetzen
2.) Ich will die Koordinaten des Zentrums nicht noch einmal eintippen

Jetzt überlege ich folgende Lösung:

Die Anzahl der Profile ist unbegrenzt. Jedem Profil entspricht ein Verzeichnis unterhalb des Arbeitsverzeichnisses (das ist eine kleine Einschränkung). Diese Verzeichnisse bestehen wie bisher aus der Index-Datei und den einzelnen Cache-Dateien samt Bildern, Karten etc.

Beim Start liest CW entweder automatisch das letzte verwendete Profil ein (durch einen Schalter bei den Präferenzen ein/aus-schaltbar) oder bietet eine Liste aller Verzeichnisse unterhalb des Arbeitsverzeichnisses an (die ja jeweils ein Profil beinhalten) aus denen dann eines ausgewählt wird. Die Koordinaten des Mittelpunktes würde ich dann in der Indexdatei innerhalb des Profils speichern. Ausserdem gibt es natürlich eine Option innerhalb CW entweder ein neues Profil anzulegen oder auf ein vorhandenes umzuschalten.

Der Vorteil dieser Lösung wäre:
- Anzahl der Profile unbegrenzt
- einfaches Kopieren eines Verzeichnisses auf den PDA reicht und los geht's!
Der Nachteil:
- Die Profile müssen unterhalb des Stammverzeichnisses liegen

Bitte lasst mich wissen ob das Eure Zustimmung findet. Ich würde das dann in den nächsten Wochen so implementieren.

ich bin dafür, gute Lösung!

das einzige, was man überlegen könnte wäre: ob man in den Präferenzen ein "Daten-Verzeichnis" einstellen lässt. Dadrunter würden dann die Verzeichnisse für die verschiedenen Orte angelegt werden (Damit man CW im Hauptspeicher ablegen kann und die Daten auf eine Memorykarte). Unter dieses Verzeichnis würde ich dann auch ein Verzeichnis "maps" anlegen...

Gruß,
Pfeffer.

Die Idee gefällt mir auch, wobei ich pfeffer zustimme, das Datenverzeichnis sollte man wählen können. Meiner Meinung nach sollten auch alle Informationen zu einem Profil in der Index-Datei landen. Was dort wahrscheinlich nicht landen kann, ist der absolute Pfadname der Daten, der relative zum eingestellten Daten-Wurzel-Verzeichnis sollte aber gehen.
Vieleicht könnte man es so machen wie z.B. viele Programme mit den zuletzt geöffneten Dateien umgehen, man merkt sich z.B. die letzten vier Profile und bietet die zum Öffnen an. Man kann natürlich auch andere Profile Öffnen bzw. neu anlegen. Die Anzahl bleibt somit unbegrenzt.

Vielleicht sollte man Datenbank- und Profilverwaltung unabhängig von einander betrachten. Ich denke der Wunsch mehrere Profile benutzen zu können, stammt nicht so sehr aus der Wunsch heraus mehrere Datenbanken zu haben, sondern eher nur einen bestimmten Teil der vorhandene Caches betrachten zu können.
So ist dies bei mir der Fall und vermutlich auch bei Albsucher, wie man Thread "Profile ergänzen mit Umkreis" entnehmen kann.
=> Statt mehrere Datenbanken würde eine Datenbank mit mehrere Filter ausreichen.

Ich bin öfters mal Bremen, Hamburg und in Bremervörde (zwischen HB und HH). Zudem habe ich noch einige Caches von einige Reisen (Urlaub usw.) auf der Beobachtungsliste und zudem plane ich schon einige Cachesuchen für die Zukunft.
=> Ich könnte somit schon mehr wie 5 Profile gebrauchen.

Bei meiner Cacheverwaltung kommt es vor, dass einige Caches sowohl im Einzugsgebiet von HB (bzw. HH) und mein Heimatort liegen. Da ich Doppelverwaltung nicht mag, macht es Sinn diese Daten in eine Datenbank abzulegen.
=> Profile wären dann nichts weiter als Filterdefinitionen. Diese Filterdefinitionen brauchen meiner Meinung nach nicht so Komplex zu sein, wie die jetzige CW-Filter. Ein Koordinaten/Radius-Filter würde (erst einmal) ausreichen. (Ein Radius von 0 könnte weiterhin, die ganze Datenbank sein.)
=> Nebeneffekt: Eine Radiuseingabe bei den OC.de/GC.com-Funktionen könnten wegfallen, wenn der Profilradius gesetzt ist.

Für ein Profil bräuchte ich kein eigene Daten, sondern eher eine Beschreibung, welche Daten tatsächlich in dem Speicher zu laden bzw. zu verwalten sind.

Ich weis nicht wie CW im Augenblick die Daten lädt, ich kann mir jedoch folgendes vorstellen:
1) Einstellungen werden geladen mit
1a) bevorzugtem Datenbank-Verzeichnis
1b) bevorzugtem Profil

2) Im eingestellten Datenverzeichnis Lädt man
2a) Die Index-Datei
2b) Die Profil-Filter-Definition

3) Es werden tatsächlich nur die Caches aus 2a) geladen, die den Filterbedingungen 2b) erfüllen.

Die ganze CW-Funktionen, die es jetzt gibt (sortieren, Zentrum setzen usw.) würden dann weiterhin auf die in 3) geladene Caches angewand werden.


Weiter Ideen für die Zukunft wäre z.B.
*) Je Datenbank- und Profilkombination eine eigene index-Datei, um das einlesen zu beschleunigen.
*) Ein Profilvorschlag, nachdem man 'Zentrum setzen' gewählt hat, indem nachgeschaut wird welches Profilzentrum dem neuen Zentrum am nächsten ist.
*) Ein Profilgenerator => Vom jetzigen Standort und Filtereinstellungen wird automatisch ein Profil generiert.
usw.


Man kann durchaus eine Datenbankverwaltung implementiert lassen, so wie es jetzt der Fall ist bzw. vorgeschlagen wurde. Die Profilverwaltung würde ich trotzdem unabhängig davon betrachten.

Gruss,
Daniel

Kurze Anmerkung:
Die "Datenbank" besteht nur aus Dateien, aus der index.xml (Nomen est Omen) und den Cachebeschreibungen bzw. Bildern. Beim Hochfahren wird die index.xml in den Speicher geladen, Beschreibungen und Bilder werden bei Bedarf nachgeladen. Wenn man die Daten speichert, wird die index.xml komplett neu geschrieben, es gibt also kein selektives Schreiben.
Wenn man eine richtige Datenbank hätte, könnte man da einiges anders machen, dann wäre aber die Plattformunabhängigkeit nicht mehr gegeben.

Bei der Diskussion muss man auch berücksichtigen, dass es (wie bei jeder Datenbank) Imports und Updates gibt. Wenn man eine GPX-Datei lädt (oder spidert oder mit OC synchronisiert) wird immer erst mal nachgeschaut, ob es den Cache schon gibt, wenn nicht, wird ein neuer Eintrag erzeugt. Man könnte nach dem vorgeschlagenen Verfahren doppelte Einträge erzeugen, wenn man eine GPX-Datei lädt, die nicht zum Filter passt. Bei unterschiedlichen Datenbanken kann man dies leichter wieder rückgängig machen, da die Profile im Allgemeinen (HB und HH mal ausgenommen) keine Überdeckung haben.

Nach einer längeren Dienstreise hatte ich dieses Wochenende endlich wieder einmal Zeit an CW weiterzuarbeiten und die Profilverwaltung voranzutreiben. Derzeit sieht es so aus, daß das Basisverzeichnis frei wählbar sein wird und alle darunterliegenden Verzeichnisse als Profil angeboten werden (Ausnahme: Verzeichnis "maps" für Pfeffer's Karten). Zusätzlich werden auch die vorhandenen 4 Profile der pref.xml (so sie definiert sind) zur Auswahl angeboten. Das letzte verwendete Profil wird automatisch vorselektiert und kann so mit einem Mausklick geladen werden. Wenn die Option zum automatischen Laden des letzten Profils in den Präferenzen aktiviert wird, wird es ohne Auswahldialog sofort geladen. Die Zentrumskoordinaten werden beim Speichern in der jeweiligen index.xml abgelegt, nicht mehr in pref.xml. (Um Verwirrungen zu vermeiden: Noch habe ich den Code noch nicht hochgeladen).

So wird das Umstellen auf die neue Struktur recht einfach sein:
- Ein Profil aus pref.xml öffnen und wieder speichern (dadurch werden die Zentrumskoordinaten in der index.xml abgelegt). Anschliessend über das Betriebssystem das relevante Verzeichnis unterhalb das Arbeitsverzeichnis kopieren. Jetzt das Profil in der pref.xml löschen. Fertig.

Im Zuge der Änderungen an Preferences.java ist mir erst aufgefallen wie verbreitet diese Klasse genutzt wird. Fast überall wird eine lokale Variable deklariert um auf die Preferences zugreifen zu können. Die Variablen haben auch oft unterschiedliche Namen.

Daher meine Frage and die Programmierkollegen: Sollten wir in Preferences.java nicht alle Elemente als "static" deklarieren? Die Funktionen zum Lesen und Schreiben von pref.xml müssen dann natürlich auch static sein. Der Zugriff auf das Datenverzeichnis könnte dann z.B. von überall über Preferences.mydatadir erfolgen ohne die Notwendigkeit irgendwelcher Deklarationen. Eventuell wäre noch eine Kapselung durch get/set Methoden bzw. ein Singleton pattern andenkbar.

Diese Änderung wäre zwar relativ weitreichend und betrifft viele Dateien, würde aber den Zugriff auf die Preferences meiner Meinung nach stark vereinfachen. In Eclipse läßt sich das auch relativ rasch realisieren. Globale Daten sind zwar in Java etwas verpönt, aber in diesem Fall würden sie doch was bringen.

Als zusätzliche Variante wäre zu Überlegen die Preferences.java in GlobalPreferences und LocalPreferences zu splitten. In den GlobalPreferences würde ich alle cacheunabhängigen Einstellungen halten (Basisverzeichnis, GPS, Spaltenbreiten etc.). In den LocalPreferences wären dann die aus der index.xml gelesenen Einstellungen (derzeit nur Zentrumskoordinaten, Radius und letztes Updatedatum).

Reini schrieb:

Ausserdem gibt es natürlich eine Option innerhalb CW entweder ein neues Profil anzulegen oder auf ein vorhandenes umzuschalten.

Zum Vergrößern anklicken....

Wie soll denn das Löschen eines Profiles gestaltet werden. Auch über CW oder 'zu Fuß' durch löschen des Verzeichnisses?

dewildt schrieb:

=> Statt mehrere Datenbanken würde eine Datenbank mit mehrere Filter ausreichen.

Zum Vergrößern anklicken....

dann müsste aber unglaublich an der performance gedreht werden. cw wird mit wachsendem datenbestand immer langsamer

=> Ich könnte somit schon mehr wie 5 Profile gebrauchen.

Zum Vergrößern anklicken....

mir reicht zwar die derzeit möglich zahl von profilen, aber eine frei konfigurierbare anzahl würde mich auch nicht wirklich stören

macht es Sinn diese Daten in eine Datenbank abzulegen.

Zum Vergrößern anklicken....

das problem könnte sein eine ebenso schlanke wie plattformunabhängige datenbankengine zu finden. ich habe eh schon das problem, daß bei caches mit mehr als zwei bildern das dritte wegen speichermangels nicht mehr angezeigt wird (aber wenigstens kommt jetzt eine meldung und kein absturz - das ist schon mal besser).

da ich den pda auch noch für andere dinge als cachen benutze ist es mir wichtig, daß was auch immer kommt mit einem möglichst kleinen footprint daher kommt. wenn ich anfangen muss termine löschen damit cw läuft wirds knapp.

ich überlege im moment eher ob es mittelfristig nicht sinnvoll sein könnte zwischen einer fetten desktopvariante und einer schlanken mobilen variante des cw zu unterscheiden. aus meinem lokalen datanbestand schiebe ich mir den kram dann passend vorselektiert auf den pda. aber das ist jetzt auch noch sehr im unreinen.

aber das geht dann mächstig in richtung einer anderen anwendung.

@Reini:
zu preferences als static: ich kenne mich da nicht so ganz genau aus, aber Deine Erläuterungen erscheinen mir plausibel. Auch dass nur eine Instanz von Preferences erzeugt werden können soll (Singleton) erscheint mir sinnvoll.
Vielleicht wäre es in diesem Zusammenhang sinnvoll, in jede Klasse, die die Preferences verwendet eine Methode einzuführen preferenceschanged(), die daraus resultierende neu Initialisierungen in der jeweiligen Klasse vornimmt.
Ob eine Unterscheidung in GlobalPreferences (ich würde sie nur Preferences nennen) und LocalPreferences (ich würde eher "CurrentProfile" vorschlagen) sinnvoll ist, übersehe ich ebenfalls nicht. Für die meisten einzelnen Klassen ist es sicher nicht notwendig. Aber für die Routinen, die die Einstellungen verwalten, könnte das sinnvoll sein. Mir würde dabei folgendes einleuchten:
die Preferences enthalten einen Vector der Profiles und einen Zeiger auf das akutelle Profile. Dann kann dadrauf zugegriffen werden mit Preferences.currProf.LastUpdateDate

Gruß,
Pfeffer.

@greiol
Meine Vorstellung sieht vor, nur die gefilterte Daten im Speicher zu laden (und zu behalten). Dies würde im Realfall nur ein Bruchteil aller vorhandene Daten sein. Die Performance müsste dann durchaus im gut sein, da der aktive (gefilterte) Datenbestand in etwa gleich bleibt. Nur das einlesen (der index.xml) würde dauern, da dann gefiltert werden muss. (Obwohl es dafür sicherlich auch schnelle heuristiken geben würde.)

Da Frage wäre wie lange es dauert
* die index.xml einzulesen
* die Caches aus der index.xml zu filtern. (Am einfachsten wäre eine Radiussuche.)
* die Daten dieser aktive Caches zu laden.

Wenn tatsächlich das verwalten (laden/speichern/filtern) der index.xml eine Menge Zeit kostet, dann klappt mein Vorschlag selbstverständlich nicht.
OK, wenn mann irgendwo in Deutschland alle Caches im Umkreis von 1000km anschauen will, dann gibt es auch performance Problemen.
Vielleicht kann man dann evt. eine obergrenze definieren. z.B. Die 50 erst gefilterte Caches oder die 50 nächst gelegene. (Ach nein, nächst gelegen würde wieder bedeuten, dass sortiert werden muss.)

Wg. Datenbank:
Wikipedia meint dazu

... einen logisch zusammengehörigen Datenbestand

Zum Vergrößern anklicken....

Demnach bilden die CW-Cache-Daten (Cachebeschreibung, Logs, Bilder, Karten, Index usw.) für mich schon einen Datenbank.
Und falls mann einen DB-Engine für Java sucht, wäre SQLite vielleicht ein Hinweis: http://www.ch-werner.de/javasqlite/

Wg. dem PDA:
- Wieviel RAM hat denn dein PDA? Mit mein Loox N560 habe ich das Problem nicht.
- Ich packe alles auf einer SD-Karte.

Gruss,
Daniel

Kleine Anmerkung zum Thema

RAM: bei mir hat sich neulich der CW verweigert das zweite Bild (für die Lösung notwendig) zu laden. Über nen Explorer hab ichs aber parallel hinbekommen?!

Performance:
Ich hab so ca. 250 Datensätze drin und muss sagen der Start geht schon ganz schön zäh. Jeglicher Performancegewinn wäre natürlich klasse!

dewildt schrieb:

- Wieviel RAM hat denn dein PDA?

Zum Vergrößern anklicken....

64 MB wie die meisten geräte

Mit mein Loox N560 habe ich das Problem nicht.

Zum Vergrößern anklicken....

das ist schön für dich

- Ich packe alles auf einer SD-Karte.

Zum Vergrößern anklicken....

mit dem cw geht das auch. aber es gibt andere tools bei denen das bedauerlicherweise nicht geht

Albsucher schrieb:

RAM: bei mir hat sich neulich der CW verweigert das zweite Bild (für die Lösung notwendig) zu laden. Über nen Explorer hab ichs aber parallel hinbekommen?!

Zum Vergrößern anklicken....

ja, das hatte ich auch schon. Es könnte daran liegen, dass die Ewe-VM offenbar nicht dynamisch RAM belegen und freigeben kann. In der nächsten BleedingEdge belegt CacheWolf gleich 12 MB, das sollte für die meisten Fälle ausreichen.

Gruß,
Pfeffer.

ah. und ich wollte schon überlegen, ob ich den dargelegten buildmechanismus dazu misbrauche all die teile aus cw rauszuwerfen, die ich eh nicht benutze um ihn schlanker zu machen

Zum Thema Performancesteigerung habe ich auch noch drei Sachen auf meiner persönlichen TODO-Liste:

- Die Index.xml ohne den SAX Parser zu lesen. Ich weiß nicht wie die Entscheidung für XML als Speicherformat gewählt wurde, eine mit TABs als Trennzeichen gespeicherte CSV Datei wäre natürlich viel schneller zu verarbeiten. Habe vor es zunächst mit der XML Datei zu versuchen. Wenn das wirklich nicht schnell genug wird, dann probiere ich mal etwas mit CSV.

- Die Sortierung zu beschleunigen. Hier wird bei jeder Vergleichsoperation zunächst geprüft was denn nun verglichen wird. Das kann alles einmalig vor Beginn der Suche erfolgen und müßte einen deutlichen Geschwindigkeitsgewinn ergeben.

- Das Scrollen zu beschleunigen. Hier habe ich durch Tests herausgefunden, daß das Zeichnen der Tickbox extrem viel Zeit verbraucht. Habe einen Patch wo ich die beiden Zustände der Tickbox durch Images ersetzt habe und das Scrollen geht deutlich schneller.

Ziel wäre, diese Sachen über Weihnachten deutlich weiter zu treiben.

*freu*
(Allerdings hatte ich für diese Verbesserungen als Weihnachtsgeschenk gehofft ;-) aber danach ist auch gut! - vielleicht checkst Du schon mal einen Patch ein, wenn Du ihn fertig hast (das scrollen, die schnellere Sortierung)?)

ich denke auch, XML ist überflüssiges Schickschnack... aber vielleicht sagt dazu besser Bilbowolf oder Kalli was... es wäre halt praktisch, wenn man einen schnellen XML-Reader und -Writer zur Verfügung hätte, dem man nur noch die zu verarbeitenden Daten zu geben braucht. Aber
a) haben wir keinen schnellen
b) nur einen sehr rudimentären, der auch aus Programmierersicht nicht von Praktischheit glänzt.

Andererseits ist die Umstellung des Dateiformates schon ein größerer Schritt, der viele neue Bugs produzieren könnte... Aber vielleicht kriegst Du das ja gut hin.

Gruß,
Pfeffer.

na da schließ ich mich mal an *freu*

XML hat Bilbowolf eingeführt, bzw. so wie ich den Code kenne war XML schon immer drin. Für die index.xml bringt XML wahrscheinlich keinen Vorteil, da dürfte CSV schneller sein, bei den Cachebeschreibungen sollte man bei XML bleiben. Wenn man auf CSV umstellen sollte (die Entscheidung sollte Bilbowolf treffen), muss darauf geachtet werden, dass der Trenner sauber "escaped" wird, ansonsten haut einem ein "," oder ";" im Cachenamen die Infomationen zu dem Cache durcheinander.

Zu den Preferences: Ich wäre auch für "etwas Globales", die Kopien, die heute genutzt werden, finde ich auch nicht so prickelnd. Die Vorschläge von Reini haben sich ganz vernünftig angehört, ich bin auch nicht so der Java-Experte. Die Trennung in Global und Lokal halte ich auch für sinnvoll. Man sollte die Trennung so vornehmen, dass es eingängig ist, was Global und was Lokal ist. Sachen wie Datenverzeichnis, Spaltenbreite etc. Global, Zentrum und so Lokal.

Zu der Sache mit der Datenbank und dem teilweisen lesen: Wenn ein Profil geöffnet ist, ist der CacheWolf grundsätzlich dazu bereit, alle Aktionen auf diesem Datenbestand zu machen, dazu gehört auch der Import neuer Daten via GPX-Import, OC-Sync oder Speicher. Bei diesem Import gibt es halt auch Updates, wenn schon Daten da sind. Wenn man hier nur einen Teil der Datenbank zur Verfügung stellt, funktioniert dies nicht mehr.

@greiol:
Wegen der Performanceoptimierung mit wenigen Caches: Du könntest Dir ein Profil anlegen (bald gibt es genügend), in das Du mit der Verwalten-Funktion die Caches kopierst, die Du Suchen willst. Dieses Verzeichnis gleichst Du dann mit dem PDA ab. Zur Sicherheit kannst Du ja die anderen Verzeichnisse auch auf die Speicherkarte laden, benutzt wird aber das Profil mit der "Hotlist". Die Verwalten-Funktion wirkt auf alle angezeigten Caches, als Caches in einem bestimmten Radius zu filtern und zu kopieren geht recht schnell.

Den Scrollpatch habe ich gerade hochgeladen. Bitte um Feedback ob ich irgend etwas übersehen habe (Könnte eventuell bei sehr kleinen oder sehr großen Schriften zu Problemen führen, da die Checkbox Bilder eine fixe Größe haben).

@Kalli: Ich würde ein Tab = hex(09) als Trenner nehmen. Dann gibt es keine Probleme mit Cachenamen die ein ; oder , beinhalten. Für die Caches selbst würde ich natürlich bei XML bleiben. Hier ist die Performance ja normalerweise kein Problem.

@kalli
so mache ich das meist auch. ich hab zwei recht umfangreiche profile und ein kleines "arbeitsprofile" in dem geplante touren abgelegt werden. so geht es während einer tour schnell und falls ich mal "einfach los gehe" habe ich alles dabei und muss halt einen moment länger warten. mit der speicherkarte im rechner geht das recht flott.

bei csv sollte man beachten, daß das ein zweischneidiges schwert ist. zum parsen ist es sicherlich um längen schneller als xml, aber man erkauft das mit größeren audwänden bei formatänderungen.

beim filtern und suchen macht es sicher sinn ein paar für die jeweilige aktion gleichbleibende aktionen schon vor der schleife zu klären.