Gelöster Mystery, scheint Cachebox 1706/1707 nicht erkennen?

[cacheboxer]

Was mich in dem Zusammenhang noch interessieren würde: kann vielleicht die API zusätzlich auch vom User hinterlegte Notizen übermitteln

Ja. Wenn ich in GSAK "refresh cache data" wähle, bekomme ich die mal testweise eingetragenen Notizen geliefert.

Falls das jemand in ACB einbauen möchte: Vorsicht: Für Notizen von groundspeak sollte unbedingt ein separates Datenbankfeld aufgenommen werden (macht GSAK auch so). Sonst sind nach einem Refresh die im Feld erfassten Notizen weg und man kann den Multi von vorne anfangen...

 

[KoiMuggele]

Das Thema hatten wir Anfang des Jahres schonmal diskutiert, dabei sind wir hierauf gestoßen:
http://gsak.net/board/index.php?showtopic=23701&st=0&#entry176306

Für mich stellt sich das aktuell so dar, wenn man die Corrected Coordinates(CC) nutzt.

Fall 1: Import einer PQ. Automatisch werden die CC mitgeliefert, auch wenn aus der gpx nicht ersichtlich ist, ob es die ursprünglichen oder die manuell geänderten Daten sind.
So oder so, die Koordinaten sind aus Nutzersicht korrekt.
Fall 2: Import über API stand heute. Es werden immer die Listingkoordinaten geliefert. Das heißt vorher vorhandene CC werden überschrieben, weil keine Unterscheidung möglich ist. Daten gehen verloren.
Fall 3: Import über API mit UserWaypoints: Wenn vorhanden, können die CC gezogen werden, wenn nicht, die Listingkoordinaten. Am zweckmäßigsten wohl in das gleiche Feld, nachdem im GPX Userwaypoints wohl noch nicht vorgesehen sind (?) und immer die Listingkoordinate befüllt wird.

Stand heute haben wir den Fehler, dass Daten verloren gehen. Das sehe ich kritisch.

Falls Fall 3 ohne großen Aufwand umsetzbar wäre, sind wir auch noch nicht ganz sauber, würden aber wenigstens keine Daten verlieren.
Für User, die die CC nicht nutzen, sollte es eigentlich keine Nebeneffekte geben.
Gelöste von ungelösten Mysteries zu unterscheiden geht so zwar nicht, ist aber eher ein "Luxus", auf den man m. E. im Zweifel weiter verzichten kann.
Das Problem, dass das Löschen von UserWaypoints wohl nicht funktioniert, wird vermutlich nicht so oft auftreten wie der Fall, dass ein Mystery mit CCs aus Versehen über API aktualisiert wird...

Also mein Fazit: das Handling von CC in Pocket Queries ist nicht optimal, aber momentan auch kein schwerwiegender Fehler, der das Cachen behindert.
Beim API Download sieht das anders aus, da kann man schon mal blöd im Feld stehen, wenn man vergessen hat, das Final manuell als WP anzulegen...

 

[cacheboxer]

Wenn das einer einbauen will, bitte auch dran denken, dass es Menschen gibt, die Corrected Coordinates aus GSAK per GPX importieren. GSAK liefert die Corrected Coordinates als Listingkoordinaten und in einem separaten Tag die Originalkoordinaten, so dass xCB den Mystery als gelöst erkennt.

Die korrigierten Koordinaten aus GSAK und der Gelöst-Status sollten bitte nicht von irgendwelchen API-Funktionen überschrieben werden. Wer GSAK nutzt, wird kaum korrigierte Koordinaten bei GC eintragen.

 

[Ging-Buh]

Ok, ich bin kein Entwickler, aber ich schätze das Kernproblem ist überhaupt nicht schwer zu lösen. Nochmal: die PQ liefert immer die korrigierten Daten! Nur der bisherige API-Aufruf liefert immer die Fake-Koordinaten. Dadurch entsteht die Inkonsistenz!
Klar wäre es schön, wenn ACB die Änderung darstellen könnte, aber Hauptsache der richtige Koordinatenwert wird immer angezeigt! Und dafür braucht es doch nur eine andere API-Abfrage, die die korrigierte und nicht die Fake Koordinate liefert!

Überhaupt nicht schwer zu lösen ist vielleicht ein bischen sehr optimistisch ausgedrückt.

Ich hab gerade die GetUserWaypoints API Funktion getestet. Die liefert tatsächlich diese CorrectedCoordinate zurück.
Jetzt stellt sich die Frage, was soll mit dieser CorrectedCoordinate gemacht werden.

• Ändern der Cache-Coordinate mit einem Flag "gelöst".
• Einfügen eines Final Waypoints mit dieser Koordinate?

Ich weiß dass es auch Nutzer gibt, die die Caches aus anderen Programmen importieren (CacheWolf...) und in CacheBox CorrectedCoordinates nutzen, für CacheBox das von Anfang an auf dem System der Final Waypoints aufgebaut ist wäre aber aus meiner Sicht eigentlich nur die 2. Variante die "richtige".

Wenn das einer einbauen will, bitte auch dran denken, dass es Menschen gibt, die Corrected Coordinates aus GSAK per GPX importieren. GSAK liefert die Corrected Coordinates als Listingkoordinaten und in einem separaten Tag die Originalkoordinaten, so dass xCB den Mystery als gelöst erkennt.

Die korrigierten Koordinaten aus GSAK und der Gelöst-Status sollten bitte nicht von irgendwelchen API-Funktionen überschrieben werden. Wer GSAK nutzt, wird kaum korrigierte Koordinaten bei GC eintragen.

Was passiert bei dir wenn du einen Cache mit einer CorrectedCoordinate aus GSAK über die API aktualisierst?
Wird dir dann diese Koordinate mit der Fake-Koordinate aus dem Listing überschrieben?
Wenn nicht dann sollte dies ja kein Problem darstellen. Dann braucht der entsprechende User nur keine CorrectedCoordinates in GC.com eintragen.

Generell ist hier auf jeden Fall zu sagen dass dies hier sehr vorsichtig gehandhabt werden müsste und dass alle möglichen Gegebenheiten in Betracht gezogen werden müssten da einerseits in CB die Mystery Lösungen schon auf 2 Arten verwaltet werden (CC und Finals) und andererseits von GC.com die Infos auch noch auf 2 Arten reinkommen (API und PQ).

 

[cacheboxer]

Was passiert bei dir wenn du einen Cache mit einer CorrectedCoordinate aus GSAK über die API aktualisierst?
Wird dir dann diese Koordinate mit der Fake-Koordinate aus dem Listing überschrieben?

Ja. Dazu habe ich gestern auch schon einen Eintrag im Tracker erstellt.

Zuerst hatte ich die Frage andersrum gelesen: Wenn ich den Cache in GSAK über die API aktualisiere, bleiben die korrigierten Koordinaten natürlich erhalten.

Generell ist hier auf jeden Fall zu sagen dass dies hier sehr vorsichtig gehandhabt werden müsste und dass alle möglichen Gegebenheiten in Betracht gezogen werden müssten da einerseits in CB die Mystery Lösungen schon auf 2 Arten verwaltet werden (CC und Finals) und andererseits von GC.com die Infos auch noch auf 2 Arten reinkommen (API und PQ).

Wohl war. Dazu kommt ja auch noch, dass auch von GC.com korrekte (Challenge Caches, Field Puzzles) und falsche (0° / 0°) Final-Waypoints kommen können...

 

[Koblenzer]

Überhaupt nicht schwer zu lösen ist vielleicht ein bischen sehr optimistisch ausgedrückt.

Möglicherweise, aber ich wollte nicht gleich desillusionieren.

Ich hab gerade die GetUserWaypoints API Funktion getestet. Die liefert tatsächlich diese CorrectedCoordinate zurück.

Das ist doch schon mal sehr gut dass es prinzipiell funktioniert!

Jetzt stellt sich die Frage, was soll mit dieser CorrectedCoordinate gemacht werden.

• Ändern der Cache-Coordinate mit einem Flag "gelöst".
• Einfügen eines Final Waypoints mit dieser Koordinate?

Wenn ACB sich hier "einfach" genau so verhalten würde, als wenn man in ACB die Finalkoordinate von Hand einträgt, wäre es vermutlich die beste Lösung, zumindest bleibt es dem bisherigen Konzept treu. Dann bleibt die veränderte Koordinate auch bei einem späteren PQ-Import erhalten. Allerdings ist dann anschließend die Fake-Koordinate nicht mehr vorhanden, sondern das Final doppelt. Das wäre ein kleines Übel. Möchte man das vermeiden, müsste hier eine Logik einsetzen, die bei einem PQ-Import prüft, ob die übergebene Cachekoordinate bereits einem Final-Wegpunkt enspricht. Dann könnte man ggf. den falschen Wegpunkt erhalten (macht das Sinn?) und die Dublette vermeiden.

 

[Koblenzer]

Kleiner Nachtrag: das Ergebnis des von mir beschriebenen Verfahrens würde dann wohl demjenigen entsprechen, wenn Groundspeak irgendwann einmal beide Wegpunkte in einer PQ liefert.

 

[cacheboxer]

Hier noch ein neuerer Eintrag im GSAK-Forum http://gsak.net/board/index.php?showtopic=24977&st=0, aus dem hervorgeht, was aktuelle Versionen der API liefern und wie GSAK das handhabt (zweite Seite, Post von Clyde).

Für Cachebox müsste man sich zusätzlich noch einen Kopf machen, wie man mit Final-Wegpunkten als "Gelöst-Anzeiger" umgehen will (oder ganz auf sie verzichtet und eine Eingabemöglichkeit für "corrected coordinates" vorsieht).