CB und WinCB - GpxFilenames

[Ging-Buh]

Ich hab mir jetzt lange Gedanken gemacht über die Art und Weise gemacht, wie in CB und WinCB momentan die GpxFilenames verwaltet werden.
Bitte entschuldigt, es ist viel zu lesen, aber hoffentlich verständlich.

Momentan ist es ja so, dass bei jedem GPX-Import ein neuer Eintrag in den GpxFilenames erstellt wird mit dem aktuellen Datum/Uhrzeit. Alle neuen oder geänderten Caches werden diesem neuen Eintrag zugeordnet. Caches, die in der letzten GPX nicht enthalten ware, bleiben dem alten GpxFilename zugeordnet.

Dieses Verhalten (mit den mehrfachen Einträgen mit gleichem Namen) ist doch ausschließlich dazu da, evtl. archivierte Caches zu erkennen, oder?

Mit diesem Verhalten habe ich in WinCB, speziell beim Thema SDF-Synchronisation ein paar Probleme.
Bei der Synchronisation speichere ich in der DB für jede SDF die erzeugt wird einen Eintrag zu dem ich speichere, welche Caches aus welchen GpxFilenames in diese SDF geschrieben werden sollen (bzw. intern wird gespeichert, welche GpxFilenames nicht exportiert werden sollen). Dies funktionierte bei mir soweit ganz gut, solange ich meine Daten aus CacheWolf importierte. Beim CB-Import wird pro CB-Profil ein GpxFilename erzeugt und dieser bleigt in Zukunft immer gleich.

Da ich aber jetzt seit neuestem Premium Member bei GC.com bin habe ich (und sicher viele andere auch) jetzt folgendes Problem:

• Wenn ich 2 PQ's importiere bekomme ich 2 GpxFilenames (Gpx1 und Gpx2).
• Im Export erstelle ich 2 CB-Synchronisations Einträge (Sdf1 und Sdf2, für jede Gpx einen).
• Export und Import funktioniert erst mal
• Wenn ich danach (am nächsten Tag, nächste Woche...) aktualisierte PQ's einlese passiert folgendes:
  • Es werden 2 neue GpxFilenames erzeugt.
  • Die meisten Caches werden diesen 2 neuen GpxFilenames zugeordnet (bis auf evtl. archivierte)
  • Der GpxFilenames Filter der Synchr.-Einträge funktioniert momentan genauso wie der von CB. Es wird nicht gespeichert, welche Gpx exportiert werden sollen, sondern genau umgekehrt, welche nicht exportiert werden sollen.
  • Dies hat zur Folge, dass dann die Zuordnung der GpxFilenames zu den Sdf's geändert ist:
    Sdf1 z.B. bekommt jetzt den alten Gpx1 (falls noch vorhanden) und die beiden neuen Gpx1 und Gpx2.
  • Das heist, dass momentan nach jedem GPX-Import die Filter des SDF-Exports angepasst werden müssten!

Deshalb habe ich mir überlegt, ob man dies nicht ändern könnte:

• Für jede GPX immer nur einen GpxFilenames Eintrag (würde das Problem mit dem SDF-Export beheben)
• Beim GPX-Import einfach zu jedem Cache Datum und Uhrzeit des letzten Imports speichern.
  Damit könnte man ja dann auch die zuletzt nicht mehr aktualisierten (evtl. archivierte) Caches filtern.
• Zusätzlich könnte man meinetwegen auch noch zu jedem Cache Datum und Uhrzeit speichern, wann der Cache das erste mal in WinCB/CB importiert wurde. Damit könnte man neu hinzugekommene Caches filtern.

Ausserdem würde ich (zumindest in WinCB) gerne noch die Möglichkeit schaffen, Caches fest zu bestimmten GpxFilenames zuzuordnen (zu pinnen).
Grund: Eine bestimmte Cache-Serie (In 80 Tagen...) mit 84 Caches geht teilweise mitten durch meine Home-Zone, ist aber nicht komplett darin enthalten (die Caches dieser Serie sind in einem Kreis rund um München mit einem Durchmesser von ca. 55km angeordnet). D.h. teilweise sind diese Caches in meiner Daheim.gpx enthalten, teilweise nicht. Ich habe eine PQ, in der genau diese 84 Caches enthalten sind und ich möchte dass diese in WinCB immer dieser QP zugeornet bleiben, auch wenn ich eine aktuelle Daheim.gpx importiere.

So, jetzt wäre meine Frage an euch, ob derartige Änderungen gewünscht wären, ob ich irgenwas übersehen habe, ob das Ganze so Probleme machen würde...

 

[cacheboxer]

Hallo,
danke, dass Du das vorher hier fragst. Ich verstehe Dein Problem und auch, wenn ich WCB nicht nutze, bin ich sehr dafür, dass gleiche Funktionen in CB und WCB sich gleich verhalten.

Kannst Du Deinen Alternativ-Vorschlag noch weiter ausführen? Wie ungefähr würde das UI aussehen, was könnte man mit den neuen Filterfunktionen alles anstellen, was ginge nicht mehr?

Es ist ja die Kombination aus Dateiname und Datum, die die jetzige Funktionalität ausmacht. Die Information, dass ein Cache seit drei Tagen nicht mehr importiert wurde, hat nur zusammen mit dem Dateinamen eine Relevanz: Bei meinen täglichen PQs wäre es ein Hinweis darauf, dass der Cache evtl. nicht mehr suchbar ist, bei den wöchentlichen hingegen wäre das völlig normal.
Dass ein Cache nicht mehr importiert wurde, muss auch nicht notwendigerweise bedeuten, dass er nicht mehr findbar ist. Ein möglicher Grund wäre z.B. auch, dass ich ihn gefunden habe.

Mit der momentanen Lösung sieht man auch auf einen Blick, ob man sich überhaupt 'mal wieder mit dem Thema "archivierte Caches" beschäftigen muss.

Denkbar wäre vielleicht auch, den bisherigen GPX-Filename Filter unter anderem Namen beizubehalten (GPX-Imports Filter o.ä.), und in einem weiteren Bereich nochmal den eindeutigen (DISTINCT) GPXFilename anzubieten. Das würde beim Filtern eine weitere Abfrage auf die (kleine) GPXFilenames-Tabelle erfordern. Vom UI her finde ich das glaube ich nicht so prickelnd, aber etwas Schwund ist ja immer...

 

[Ging-Buh]

Kannst Du Deinen Alternativ-Vorschlag noch weiter ausführen? Wie ungefähr würde das UI aussehen, was könnte man mit den neuen Filterfunktionen alles anstellen, was ginge nicht mehr?

Wie man für diesen Fall die UI gestalten könnte, darüber bin ich mir noch nicht im klaren.
Um eine ähnliche Funktionalität zur Verfügung zu stellen wären dafür sicherlich wesentlich komplexere Filter-Funktionen notwendig.
Für WinCB auf dem PC sicherlich kein Problem. Auch wenn die Filter und Abfragen deutlich komplexer werden würden, Rechenleistung steht da ja genug zur Verfügung.
Für die mobile CB könnte das aber durchaus zu einem absoluten Ausschlußkriterium werden (zu langsam...)

Denkbar wäre vielleicht auch, den bisherigen GPX-Filename Filter unter anderem Namen beizubehalten (GPX-Imports Filter o.ä.), und in einem weiteren Bereich nochmal den eindeutigen (DISTINCT) GPXFilename anzubieten. Das würde beim Filtern eine weitere Abfrage auf die (kleine) GPXFilenames-Tabelle erfordern. Vom UI her finde ich das glaube ich nicht so prickelnd, aber etwas Schwund ist ja immer...

Bin mir jetzt nicht ganz sicher, ob ich dich richtig verstehe.
Meinst du damit, dass das komplette Verhalten der jetztigen [GpxFilenames] Tabelle beibehalten bleiben sollte mit der Ausnahme, dass in den Einträgen dieser Tabelle nicht mehr die GXPDateinamen als String gespeichert werden, sondern ein Verweis auf eine übergeordnete Tabelle, in der die Dateinamen und jeweils eine ID gespeichert sind?
Das würde mir für den SDF-Export denke ich auch helfen. Die Abfragen würden möglicherweise etwas komplexer, aber auf dem PC kein Problem.
Für die mobile CB würde sich dann intern so gut wie nichts ändern. Die Filter blieben gleich (schnell). Das einzige wäre, dass man beim Füllen der GpxFilenames Liste im Filterdialog die Namen der Dateien zusätzlich aus der übergeordneten Tabelle holen müsste. Wäre aber sicherlich kein Problem, sind ja sehr übersichtliche Datenmengen.
Mit dieser übergeordneten Tabelle könnte ich dann auch das andere Problem mit den gleichen Caches in mehreren PQ's lösen. Einfach zu den Einträgen dieser Tabelle ein Flag "Pinned" hinzfügen und beim GPX-Import werden alle Caches, die einem "gepinnten" GPX-Filename angehören nicht in einen anderen GPX-Fillenamen verschoben.
Vielleicht könnte man diese übergeordnete Tabelle dann ja z.B. Kategorien nennen und in WinCB die Möglichkeit schafen, neue Kategorien manuell zu erstellen, Caches manuell von einer in eine andere Kategorie zu verschieben...

 

[cacheboxer]

Meinst du damit, dass das komplette Verhalten der jetztigen [GpxFilenames] Tabelle beibehalten bleiben sollte mit der Ausnahme, dass in den Einträgen dieser Tabelle nicht mehr die GXPDateinamen als String gespeichert werden, sondern ein Verweis auf eine übergeordnete Tabelle, in der die Dateinamen und jeweils eine ID gespeichert sind?

Gedacht hatte ich wieder 'mal komplizierter, aber so ginge es natürlich auch
Ohne Änderung der Datenstrukturen hätte man "Deinen" Teil des Filters aus select distinct GPXFilename from GPXFilenames; aufbauen können.

 

[Ging-Buh]

Gedacht hatte ich wieder 'mal komplizierter, aber so ginge es natürlich auch
Ohne Änderung der Datenstrukturen hätte man "Deinen" Teil des Filters aus select distinct GPXFilename from GPXFilenames; aufbauen können.

Das Einrichten einer übergeordneten Tabelle (z.B. Kategorie) hatte gegenüber dem select distinct 2 Vorteile:

1) Ich kann zu jeder "Kategorie" den Schalter "Pinned" einbauen. Caches, die einer "gepinnten" Kategorie zugeordnet sind, bleiben beim GPX-Import in dieser.

2) Auf dieses "Problem" bin ich erst jetzt gestoßen, da ich erst seit kurzem Premium Member bin und erst jetzt PQ's nutze. Ich hab eine PQ um meine Homezone mit 1000 Caches. Jedes mal, wenn mitten drin ein neuer Cache hinzukommt, fällt am Rand einer weg, der aber nicht unbedingt archiviert sein muß und daher auch nicht unbedingt entfernt werden muß.
Dadurch wird vermutlich im Laufe der Zeit die Anzahl der GpxFilenames Einträge für die selbe PQ immer mehr werden. Wenn ich nun für den Filter der CacheListe einzelne PQ's ein- oder ausschalten will, müsste ich momentan jeden einzelnen dieser Einträge "Daheim.gpx" markieren und umschalten. Wenn ich aber eine Globale Kategorie "Daheim" habe, könnte ich dies mit einem Klick umschalten.

Und außerdem dürfte es für die Kompatibilität mit CB kein Problem sein, wenn ich diese "Kategorie" nur in WinCB einbaue. Das Verhalten der GPXFilenames dahinter bliebe absolut gleich. Beim SDF-Export könnte einfach die neue Tabelle weggelassen werden, und CB funktioniert (ohne Änderugen) wie bisher.

Danke für deine Unterstützung.