Correctes coords und personal cache notes

[Klaas]

Ich suche in Cachebox die "corrected coordinates" und die "personal cache notes", aber kann sie nicht finden. Schaue ich falsch oder ist es nicht im Programm?

 

[cacheboxer]

Ist zurzeit beides nicht drin.

Einen Mystery markiert man in Cachebox als gelöst, in dem man einen Final-Wegpunkt mit den korrigierten Koordinaten anlegt. Außerdem werden die corrected coordinates aus GSAK unterstützt.

 

[arbor95]

Man sollte einen Mystery - Cache mit geänderten Koordinaten auf der Karte und im Listing an der grünen Farbe ( statt Blau) erkennen.

Du kannst bei einem Cache die Koordinaten ändern. (edit cache im cache kontextmenü)
Dann erhält er intern die Markierung, dass die Koordinaten geändert sind.

 

[cacheboxer]

Du kannst bei einem Cache die Koordinaten ändern. (edit cache im cache kontextmenü)
Dann erhält er intern die Markierung, dass die Koordinaten geändert sind.

Kann man diese Markierung nicht auch setzen, wenn die korrigierten Koordinaten aus GSAK kommen? Diese Markierung scheint nämlich bei Reload Cache (API) die korrigierten Koordinaten zu schützen.

Die GSAK-Koordinaten gehen dabei leider verloren - ziemlich übel, wenn man im Feld mal nach neuen Logs schauen will und plötzlich keine Koordinaten mehr von der Dose hat. Siehe auch Issue #802.

 

[arbor95]

keine Ahnung, aber da hilft ein Blick in die DB - Definition (oder in den Code)

Es könnte sein, dass die Koordinaten nicht doppelt (original und geändert) gespeichert werden.

Es stellt sich die Frage nach dem führenden System.
Koords in Gsak geändert , aber nicht in GC. Das ist fatal.

Das führende System ist natürlich GC. Also gelten die dortigen Koordinaten.
Ansonstzen muss man immer die Aktualisierung über GSAK machen.

 

[cacheboxer]

Das führende System bin ich.

Wenn ich in GSAK corrected coordinates hinterlegt habe, dürfen die nicht durch die Phantasiekoordinaten aus dem Listing überschrieben werden. ACB erkennt die corrected coordinates (Fragezeichen wird grün), schützt sie aber nicht vor Überschreiben durch die Listingkoordinaten.

 

[arbor95]

Du meinst ACB ist das führende Sytem?!

Wenn du dann noch mal in GSAK ändern würdest blieben die Koordinaten im ACB erhalten?

 

[cacheboxer]

Verstehe gerade nicht, worauf die hinaus willst...

 

[arbor95]

Warum sollte ACB irgendetwas schützen.
Es ist die Verantwortung des Anwenders ACB immer mit den korrekten Daten zu versorgen.
Das sind die Daten, die du zuletzt eingelesen hast, egal ob aus einer PQ oder einem Update von GC.

 

[hanknstone]

moin moin ...

Es ist die Verantwortung des Anwenders ACB immer mit den korrekten Daten zu versorgen.

Eiwei, zu diesem Thema habe ich noch einen Bug zu vermelden.
Folgender Fall:
- in der Datenbank (auf dem Endgerät) ein gelöster Mystery, mit eingetragenem Finalen Wegpunkt
- Du stehst vor Ort, findest die Dose nicht ..., also, um die letzten Logs zu sehen->
- Reload des Caches über die API
- Finaler Wegpunkt ist verschwunden, die Coords des Mystery liegen plötzlich 5750km entfernt...

Ist mir so in den letzten 2 Wochen dreimal passiert,
...und zwar immer dann wenn ich einen archivierten Cache über die API nachlade werden alle Wegpunkte des Caches "getötet" und die Coords auf 0 gesetzt.

Da schaut man als Anwender erstmal richtig schön blöd auf´s Gerät ....

 

[arbor95]

nur, wenn man "blöde" ist und archivierte Cache sucht.

Ist aber natürlich ein Fehler.

In dem anderen Fall sollte die Lösung natürlich so aussehen, dass die Koordinaten mit dem Merker korrigiert -->nie<-- automatisch überschrieben werden (pq, gc, cw über wcb, ...). Ein manuelles Ändern in ACB sollte aber möglich sein. Einen Abfragedialog für obige Fälle halte ich nicht für sinnvoll.

 

[cacheboxer]

Warum sollte ACB irgendetwas schützen.
Es ist die Verantwortung des Anwenders ACB immer mit den korrekten Daten zu versorgen.
Das sind die Daten, die du zuletzt eingelesen hast, egal ob aus einer PQ oder einem Update von GC.

Warum schützt ACB dann per "Edit" geänderte Koordinaten? Genau, weil vom Anwender eingegebene Daten heilig sind und nicht überschrieben werden dürfen! Erst recht nicht heimlich und unerwartet.

 

[Ging-Buh]

Warum schützt ACB dann per "Edit" geänderte Koordinaten? Genau, weil vom Anwender eingegebene Daten heilig sind und nicht überschrieben werden dürfen! Erst recht nicht heimlich und unerwartet.

Hab ich da was nicht mitbekommen?
Seit wann kann man in ACB denn überhaupt die gegebenen Cache-Koordinaten ändern? In den ursprünglichen Vesionen war dies doch nicht der Fall. Da konnte man nur selbst eingegebene Waypoints ändern.

Der angedachte Weg, in ACB die Lösungen eines Mysteries einzugeben sind Final Waypoints. Darauf ist ACB ausgelegt und mit diesen hat ACB beim PQ- und API-Import keine Probleme. Hier wird nichts überschrieben (außer dem Problem mit den archivierten Caches).

 

[cacheboxer]

War auch irritiert, aber der von arbor95 erwähnte Menüpunkt existiert tatsächlich (Nutze Rev. 1790).

Die Kommunikation untereinander und gegenüber den Kunden kann noch verbessert werden

 

[Ging-Buh]

Hab gerade nochmal genauer hingesehen. Das Ändern der Cache-Koordinaten geht in ACB nicht.
Sieht manchmal nur so aus.
Wenn ein Cache mind. 1 Waypoint hat dann erscheint dieser Menüpunkt auch wenn der oberste Eintrag der Waypoints-Liste markiert ist. Editiert wird in diesem Fall aber der zuletzt aktivierte Waypoint.

 

[arbor95]

Vielleicht versuchst du es mal mit einem anderen Menüpunkt.
Da geht es dann.

 

[cacheboxer]

Cacheliste, "Edit Cache", Koordinaten ändern, Fragezeichen wird grün.

Ich persönlich finde die "Edit Cache"-Variante übrigens besser, als die Final-Methode, da auch Mysteries mehrere Wegpunkte und einen richtigen Final haben können und sich das dann gerne mal beißt.

Wir haben das Thema Corrected Coordinates im Forum glaube ich schon mal diskutiert. Ich denke, ACB sollte sich merken, woher die korrigierten Koordinaten kommen und "niederwertige" durch "höherwertige" überschreiben, "höherwertigere" durch "niederwertigere" aber unangetastet lassen.

Wertigkeit:
1. Manuell in ACB geänderte Koordinaten
2. Aus GPX importierte Koordinaten, denen Original Coordinates mitgegeben wurden (GSAK und Kompatible)
3. API Corrected Coordinates
4. Alles andere

So wäre das Prinzip, dass vom Anwender eingegebene Daten heilig sind und nicht verloren gehen dürfen, gewahrt, alle (mir bekannten) Varianten würden unterstützt. WCB müsste den Cache dann so markieren, dass er wie 1. aussieht (die Variante präferiere ich) oder es müsste für WCB noch eine Stufe zwischen 1. und 2. eingeführt werden.

Wenn man's ganz perfekt machen will, würde man bei korrigierten Koordinaten noch einen vor manuellen Änderungen geschützten Wegpunkt mit den Listingkoordinaten erzeugen. Hab auch schon Mysteries gehabt, die einem am Vorfinal mitgeteilt haben, dass der Final x° und y Meter von den Listingkoordinaten entfernt liegt...

Wie man die bisherige Variante mit den Final-Waypoints in das Konzept unterbringt, weiß ich allerdings auch nicht. Ich fand sie immer unglücklich, auch schon bei CB.

 

[Ging-Buh]

Cacheliste, "Edit Cache", Koordinaten ändern, Fragezeichen wird grün.

Wow, geht wirklich. Das ist mir neu! Das habe ich noch nicht mitbekommend dass dies auch geht...

Ich persönlich finde die "Edit Cache"-Variante übrigens besser, als die Final-Methode, da auch Mysteries mehrere Wegpunkte und einen richtigen Final haben können und sich das dann gerne mal beißt.

Wo ist das Problem, wenn ein Mystery mehrere Wegpunkte und einen Final hat?

Wenn man's ganz perfekt machen will, würde man bei korrigierten Koordinaten noch einen vor manuellen Änderungen geschützten Wegpunkt mit den Listingkoordinaten erzeugen. Hab auch schon Mysteries gehabt, die einem am Vorfinal mitgeteilt haben, dass der Final x° und y Meter von den Listingkoordinaten entfernt liegt...

Ist das nicht etwas übertrieben wenn wir die Cache-Koordinate (die ja ursprünglich nicht geändert werden konnte) jetzt änderbar machen und den alten Wert dann in einen wiederum nicht änderbaren Waypoint schreiben sollen? Noch dazu weil ACB eine (für mich) sehr gute und funktionierende Umsetzung dieser Problematik hat (eben mit den Final Wypoints)?

Wie man die bisherige Variante mit den Final-Waypoints in das Konzept unterbringt, weiß ich allerdings auch nicht. Ich fand sie immer unglücklich, auch schon bei CB.

Ich denke, das ist nicht der richtige Zeitpunkt um dieses grundlegende Konzept von allen CacheBoxen über den Haufen zu werfen. Sämtliche CB-Produkte sind von Anfang an darauf ausgelegt, mit den Final Wegpunkten zu arbeiten.

Wenn jemand gerne dieses Verhalten in ACB integrieren möchte dann habe ich nichts dagegen, solange das ursprüngliche Verhalten (das mit den Finals) dadurch nicht angetastet wird. Dann müsste sich dieser jenige aber auch um die weiteren Konsequenzen (überschreiben der Koordinaten bei Update...) kümmern.

 

[hbr]

Ich denke, das ist nicht der richtige Zeitpunkt um dieses grundlegende Konzept von allen CacheBoxen über den Haufen zu werfen. Sämtliche CB-Produkte sind von Anfang an darauf ausgelegt, mit den Final Wegpunkten zu arbeiten.
....
kümmern.

Ich arbeite nur mit der Variante zusätzliche Wegepunkte und dem Final Wegepunkt!
Ich hoffe dies bleibt auch so erhalten!
Da werden beim Neuladen des Cache keine Koordinaten überschrieben.
Die Berarbeitung des Cache macht eventuell Sinn bei eigenen in Cachebox angelegten Caches, die nicht bei GC gelistet sind und ist eventuell auch NUR dafür gedacht?
Welchen Sinn macht es, einen Cache der bei GC als Multi gelistet ist in Tradi oder sonst was
zu ändern oder die D / T Wertung zu ändern (als dies ist ja möglich)?

Viele Grüße
Heiner

 

[Koblenzer]

Das Thema Mystery Fake/Final Wegpunkt wurde hier im Forum schon mehrfach intensiv diskutiert, im vorausgegangenen Thread zu dem Thema http://forum.geoclub.de/viewtopic.php?f=114&t=70307 wurden auch mögliche Lösungen aufgezeigt, leider mangelt es bisher allerdings an der Umsetzung.