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

[Koblenzer]

Hi,
ich habe auf der geocaching.com Webseite einen Mystery Cache gelöst und die Finalkoordinaten dort hinterlegt. Leider scheint Cachebox 1706/1707 das nicht zu erkennen. Wenn ich den Cache über die API aktualisiere ändert sich weder die Farbe des "?", noch ändert sich der Wegpunkt bzw. es wird auch keiner hinzugefügt. Also genaugenommen passiert gar nichts.
Ist das richtig so?

 

[Ging-Buh]

Hi,
ich habe auf der geocaching.com Webseite einen Mystery Cache gelöst und die Finalkoordinaten dort hinterlegt. Leider scheint Cachebox 1706/1707 das nicht zu erkennen. Wenn ich den Cache über die API aktualisiere ändert sich weder die Farbe des "?", noch ändert sich der Wegpunkt bzw. es wird auch keiner hinzugefügt. Also genaugenommen passiert gar nichts.
Ist das richtig so?

Richtig oder nicht, das ist hier die Frage.

Ich weiß aktuell nicht, ob GS in letzter Zeit was geändert hat, aber zu der Zeit als wir die Einbindung der API gemacht haben gab es mit dieser Funktion Probleme.
Soweit ich mich erinnern kann konnten wir nicht feststellen, ob überhaupt eine Koordinate geändert wurde oder nicht. Von daher haben wir erstmal festgelegt dass diese Funktion auf der Webseite erstmal nicht in Verbindung mit CB genutzt werden sollte.

Sollte sich da seitens GS was geändert haben könnte man durchaus überlegen, dies entsprechend einzubinden. Ich würde so eine Funktion durchaus auch sinnvoll finden.

 

[Koblenzer]

Also über eine PQ kommen die geänderten Daten mit und der Wegpunkt wird an das Final verschoben. Allerdings ist das Fragezeichen nach wie vor blau statt grün. Da der ursprüngliche Wegpunkt nach dem Import nicht mehr enthalten ist, erkennt man im Zweifel so leider nicht, ob denn der Cache gelöst ist oder nicht.

 

[Timo TA93]

Ein Kommunikationsproblem?
Zwischen Softwar
entwicklern und "Grundsprech" ?

 

[GeoSilverio]

Aber war das nicht genau DAS Problem?
Groundspeak handled es wohl so, dass die Finalkoordinaten einfach fix ersetzt werden. In der PQ kommt aber kein Flag oder Merkmal mit, dass es dich um manuell geänderte Koordinaten handelt. Da war die Frage, wie CacheBox das nun erkennen soll?

 

[Longri]

Genau DAS wars.

Gesendet von meinem GT-I9300 mit Tapatalk 2

 

[Koblenzer]

Ich möchte noch einmal auf das Thema zurück kommen, denn scheinbar ist es (mittlerweile) doch möglich, die Fake/Final Wegpunkte unterscheidbar über die API zu bekommen. Für einen Test habe ich Locus (Pro) sowie das zugehörigen Geocaching-Addon installiert. Das Addon nutzt wie ACB die offizielle Groundspeak-API. Damit wird zunächst auch der Fake-Wekpunkt angezeigt. Geht man jedoch darauf, erscheint in den Details die tatsächliche Finalkoordinate. Drückt man dann auf Kartenansicht, springt Locus dorthin und zeigt das Cachesysmbol mit einem zusätzlichen roten Stern.
Wenn Locus das mit der API kann, sollte das doch mit den gegebenen Informationen auch in ACB möglich sein!?

 

[Ging-Buh]

Ich möchte noch einmal auf das Thema zurück kommen, denn scheinbar ist es (mittlerweile) doch möglich, die Fake/Final Wegpunkte unterscheidbar über die API zu bekommen. Für einen Test habe ich Locus (Pro) sowie das zugehörigen Geocaching-Addon installiert. Das Addon nutzt wie ACB die offizielle Groundspeak-API. Damit wird zunächst auch der Fake-Wekpunkt angezeigt. Geht man jedoch darauf, erscheint in den Details die tatsächliche Finalkoordinate. Drückt man dann auf Kartenansicht, springt Locus dorthin und zeigt das Cachesysmbol mit einem zusätzlichen roten Stern.
Wenn Locus das mit der API kann, sollte das doch mit den gegebenen Informationen auch in ACB möglich sein!?

Hallo Koblenzer,

über die PQ's (die ja für die meißten noch der Hauptlieferant der Daten in CB sein dürfte) kommt diese Info defintiv noch nicht rüber. Da wird die eingegebene Koordinate als die Cache-Koordinate angegeben. Ein Wegpunkt ist nicht vorhanden und eine Info dass es sich bei dieser Koordinate um einen Korrektur handelt habe ich zumindest noch nicht gefunden.

Über die API (normale Suche anhand Koordinate) bekomme ich seltsamerweise die Orginal-Koordinaten, nicht die korrigierten. Einen Wegpunkt mit den korrigierten Koords bekomme ich da nicht. Da scheint sich GS nicht ganz einig zu sein was hier zu tun ist!?!?!

Was wir in Verbindung mit der API machen können um diese korrigierten Koords zu bekommen müssen wir dann noch herausfinden.

Ich finde es aber generell extrem unglücklich (höflich ausgedrückt) dass GS hier einen Unterschied zwischen PQ und API macht. Wenn wir hier beim PQ-Import für jeden einzelnen Cache wieder eine API-Funktion aufrufen müssen, nur um festzustellen ob hier eine Koordinate korrigiert wurde das kann es doch auch nicht sein, oder?

 

[GeoSilverio]

Ja, vielleicht wurde da noch was gemacht von Groundspeak.
Andererseits währe es natürlich overkill, nach jedem PQ-Import (bei mir sind das immer 3 PQ mit etwa 2700 Caches) alle 2700 Caches dann nochmal über die API gegen zu prüfen.

Die Frage ist, ob man das vielleicht automatisieren kann, beim Aufruf eines einzelnen Caches dann einmal zu schauen was über die API kommt.
Oder wie macht Locus das genau?

Edit: Zu langsam

 

[Koblenzer]

Ja, vielleicht wurde da noch was gemacht von Groundspeak.
Andererseits währe es natürlich overkill, nach jedem PQ-Import (bei mir sind das immer 3 PQ mit etwa 2700 Caches) alle 2700 Caches dann nochmal über die API gegen zu prüfen.

Die Frage ist, ob man das vielleicht automatisieren kann, beim Aufruf eines einzelnen Caches dann einmal zu schauen was über die API kommt.
Oder wie macht Locus das genau?

Edit: Zu langsam

Wie Locus das intern genau abwickelt weiß ich natürlich nicht. Aber bei meinem Test über die Funktion "Live-Karte" war es so, dass das Mysterycache-Symbol zuerst an der offiziellen, falschen Koordinate auf der Karte angezeigt wurde. Als ich dann auf der Karte auf das Mysterycache-Symbol geklickt hatte um mir Details anzeigen zu lassen, kam kurz die Meldung "Aktualisiere Cache" und dann stand direkt die richtige Finalkoordinate im Fenster und nicht die falsche. Dabei springt dann auch sofort das Symbol zu der korrekten Finalkoordinate und zeigt dann dort das Mystery-Symbol mit dem roten Stern. Dabei wird das Symbol an der Fake-Position entfernt.
Allerdings scheint das Verfahren in Locus auch nicht perfekt umgesetzt, denn wenn man nur etwas die Karte verschiebt oder zoomt, dann verschwindet die korrigierte Cacheposition samt Symbol wieder und das ursprüngliche Symbol an der Fakekoordinate wird wieder gezeigt.
Ich vermute daher, dass die Übersicht über die Caches über irgendeine andere API-Funktion (für die Grobübersicht !?) abgerufen wird, die die Fake-Position liefert. Erst beim konkreten Zugriff auf den einzelnen Cache wird dann die korrigierte Finalposition geliefert.
Wenn das so ist, müsste man womöglich einen zweistufigen Prozess für die Abfrage der Mysterycaches einrichten. Wobei das ja dann auch z.B. bei Multicaches relevant sein könnte, auch hier hat man die Möglichkeit auf der geocaching.com Webseite die Finalkoordinaten anzupassen. Ob das sinnvoll in ACB zu implementieren ist müssen die Entwickler beurteilen.
Aber irgendeine ansatzweise Lösung für das Problem würde ich mir schon wünschen

 

[GeoSilverio]

Letztendlich wäre es schön, wenn Groundspeak mal die Informationen liefern würde, wann sie die geplanten Änderungen in der GPX-Struktur ausliefern, angekündigt ist das ja schon seit vielen Monaten, wenn das dann mal kommt, wäre es sicher überhaupt kein Problem.

Ich habe nur gerade keinen Überblick, vielleicht gibts da auch schon grobe Zeitschätzungen im Groundspeak-Forum?

 

[cacheboxer]

Ich finde es aber generell extrem unglücklich (höflich ausgedrückt) dass GS hier einen Unterschied zwischen PQ und API macht.

Die trauen sich halt nicht mehr. Als die das letzte mal was neues in die GPX aufgenommen haben (die Attribute), sind ja massenhaft unsauber programmierte Caching-Programme und GPS-Empfänger abgeschmiert und es gab Mega-Ärger, so dass dann kurzfristig die Option hinterhergeworfen wurde, statt GPX-Version 1.0.1 das bisherige Format 1.0.0 in den Account Details einzustellen...

Wenn ich mich recht erinnere, kam CB auch mit dem neuen Format klar - war aber trotzdem ohne Druck eines der ersten Programme, die mit den Attributen dann auch was anfangen konnten.

 

[Ging-Buh]

Ja, das könnte evtl. der Grund für das aktuelle Verhalten sein.
Aber hilft uns diese Erkenntnis weiter?

Fakt ist dass

• in einer PQ kommen nur die Corrected Coords ohne Hinweis darauf dass diese Coords eben geändert wurden
• Über die API kommen zum Cache erstmal die orginal Coords. Es scheint aber eine API Funktion zu geben über die man die Corrected Coords bekommen kann.

Die einzige Möglichkeit, an die Corrected Coords zu kommen wäre vermutlich, nach dem PQ-Import jedesmal für alle Caches zusätzlich noch eine API-Funktion aufzurufen was dann aber natürlich den Import extrem verlangsamen würde.

Ich für meinen Teil habe mich erstmal damit abgefunden dass ich diese Funktion der GS-Webseite nicht nutze und meine Lösungen in WinCB oder ACB eintrage.

 

[Koblenzer]

Die einzige Möglichkeit, an die Corrected Coords zu kommen wäre vermutlich, nach dem PQ-Import jedesmal für alle Caches zusätzlich noch eine API-Funktion aufzurufen was dann aber natürlich den Import extrem verlangsamen würde.

Das Thema würde ich erst einmal ausklammern. GS liefert in der PQ die korrigierte Koordinate. Das ist ja in Ordnung. Scheinbar fehlt hier leider nur ein Merkmal, woran man erkennen könnte, dass es sich nicht mehr um die Fake-Koordinaten handelt, sodass man das in ACB entsprechend darstellen könnte. Hier könnte ACB evtl. nur anhand des Unterschieds der alten Daten zu neuen Import-Daten bemerken, dass sich die Hauptkoordinate geändert hat und das evtl. ersichtlich machen.

Ich für meinen Teil habe mich erstmal damit abgefunden dass ich diese Funktion der GS-Webseite nicht nutze und meine Lösungen in WinCB oder ACB eintrage.

nicht wirklich, oder?
Eigentlich beschränkt sich das Hauptproblem doch darauf, dass der ACB-Aufruf der API immer die Fake Koordinaten liefert, selbst wenn korrigierte vom Benutzer hinterlegt sind. Und aufgrund meiner Tests mit Locus scheint es ja so, dass es einen anderen/zusätzlichen API-Aufruf gibt, der eben auch die korrigierten Koordinaten liefern kann.
Also sollte das Problem doch mit überschaubarem Aufwand lösbar sein?
PQ-imporierte Caches nochmal mit einem API-Aufruf nachzubehandeln, um zu prüfen, ob die Daten der PQ nun Fake oder echt sind, ist ein anderes Thema. Das könnte man ja evtl. manuell pro Cache oder Filterauswahl anstoßen. Aber wie gesagt, da würde ich zunächst nicht den Fokus drauf legen.

Was mich in dem Zusammenhang noch interessieren würde: kann vielleicht die API zusätzlich auch vom User hinterlegte Notizen übermitteln oder gar synchronisieren? Das wäre genial!
Gibt es hier GS-API-Experten?

 

[hbr]

Die einzige Möglichkeit, an die Corrected Coords zu kommen wäre vermutlich, nach dem PQ-Import jedesmal für alle Caches zusätzlich noch eine API-Funktion aufzurufen was dann aber natürlich den Import extrem verlangsamen würde..

Oder immer dann eine API Funktion aufzurufen wenn der Mystery entweder in der Cacheliste oder auf der Karte angewählt wird - also den Cache aktualisieren.
All dies setzt aber immer und überall eine Mobilnetz - Verbindung voraus.
Ich sehe auch so gar keinen Vorteil darin (oder ich sehe den einfach nicht ?), die ermittelten Koordinaten eines Mysterys bei GC zu speichern. Alles was ich offline speichere habe ich immer dabei.
Viele Grüße
Heiner

 

[Koblenzer]

Meine kurze Recherche hat ein paar Anhaltspunkte anhand der API-Aufrufliste unter https://staging.api.groundspeak.com/Live/V6Beta/geocaching.svc/help geliefert. Leider habe ich noch keine Informationen gefunden, was sich im Detail dahinter verbirgt bzw. was die genau zurück liefern.

Zu Wegpunkten:

GetUserWaypoints 	GET 	Service at https://staging.api.groundspeak.com/Live/V6Beta/geocaching.svc/GetUserWaypoints?accessToken={ACCESSTOKEN}&cacheCode={CACHECODE}
SaveUserWaypoint 	POST 	*Note* The ID field in the request should only be set with an ID returned from the service (when you are updating a waypoint) Otherwise this field should be left null.

Scheinbar kann man so auch geänderte WPs zu GS hochladen?

Vielleicht liegt hier ein Unterschied (Fake/korrigiert) bei den API-PQ-Abfragen vor:

GetFullPocketQueryData 	GET 	Returns a complete Geocache object without those full caches counting against user's cache limit.
GetMoreGeocaches 	POST 	Service at https://staging.api.groundspeak.com/Live/V6Beta/geocaching.svc/GetMoreGeocaches
GetPocketQueryData 	GET 	Returns a Lite Geocache object without those lite caches counting against user's cache limit.

Notizen scheint man tatsächlich zumindest abrufen zu können, vielleicht sogar updaten?!

GetUsersCacheNotes 	GET 	Service at https://staging.api.groundspeak.com/Live/V6Beta/geocaching.svc/GetUsersCacheNotes?accessToken={ACCESSTOKEN}&startIndex={STARTINDEX}&maxPerPage={MAXPERPAGE}
UpdateCacheNote 	POST 	Service at https://staging.api.groundspeak.com/Live/V6Beta/geocaching.svc/UpdateCacheNote

Das könnte zusammen mit dem Wegpunktupload sogar evtl. die im Nachbarthread gewünschte Archiv-Funktion überflüssig machen!?

Auch interessant:

AddFavoritePointToCache 	GET 	Service at https://staging.api.groundspeak.com/Live/V6Beta/geocaching.svc/AddFavoritePointToCache?accessToken={ACCESSTOKEN}&cacheCode={CACHECODE}

Man könnte direkt im Feld Favoritenpunkte vergeben!

Aber jetzt bin ich doch etwas weit abgeschweift, zurück zum Hauptthema:
in der Nachbarabteilung hat sich schon mal jemand mit der Problematik beschäftigt und da steht womöglich auch die Lösung für das Koordinatenproblem Fake/korrigiert:
http://forum.geoclub.de/viewtopic.php?f=147&t=68109

 

[GeoSilverio]

Ja, so würde das wohl funktionieren...
Allerdings eben pro Cache. Da muss man eben sehen, wie das zu lösen ist.
Datenverbindung MUSS bestehen etc...

Evtl. könnte man es, wie der Image- / Spoiler-Import optional nach dem PQ-Import laufen lassen.
Ich weiß auch nicht, ob diese UserWaypoint-Abfrage am Kontigent der API-Aufrufe zehrt etc...

 

[Koblenzer]

Ja, so würde das wohl funktionieren...
Allerdings eben pro Cache. Da muss man eben sehen, wie das zu lösen ist.
Datenverbindung MUSS bestehen etc...

Evtl. könnte man es, wie der Image- / Spoiler-Import optional nach dem PQ-Import laufen lassen.
Ich weiß auch nicht, ob diese UserWaypoint-Abfrage am Kontigent der API-Aufrufe zehrt etc...

Ja, aber wie gesagt würde ich das PQ-Thema erst einmal hinten anstellen. Da kommt ja die korrekte Koordinate mit! Man sieht nur den Unterschied nicht.
Und was in den PQs nunmal nicht drin steht kann man nunmal auch nicht ohne weiteres ergänzen bzw. nur mit Krücken und Aufwand. Da sehe ich keinen zwingenden Handlungsbedarf. Vielleicht könnte sich ACB nach einer manuellen API-Abfrage merken, wenn die Koordinaten geändert wurden und es beim nächsten PQ-Import als Änderungskennzeichen behalten.

Wichtig ist aber in meinen Augen, dass die API-Abfrage, wenn man sie denn nutzt, keine falschen Daten sondern den richtigen Wert und möglichst alle Details zum Cache liefert! Also möglichst auch Notizen usw. Und das ist, wie wir nun wissen, über die API machbar!
Aktuell ist der Zustand doch m.E. so, dass der richtige Wert, über eine PQ importiert, durch die API-Abfrage/Cache aktualisieren wieder mit einem falschen Wert überschrieben wird! Das ist doch fatal!?
Upload ist dann wieder ein anderes Thema, sollte man aber auch mal im Hinterkopf behalten!

 

[GeoSilverio]

Ich glaube das ist schon extrem schwer zu "lösen"...
Mache ich nach einer PQ eine API-Abfrage, können die Koordinaten überschrieben werden.
Dummerweise ändern sich auch bei ganz normalen Caches ab und an die Koordinaten.
Habe ich nun also per PQ Koordinaten X importiert und sagen dann im Programm: "Aktualisiere ich aber nicht, weil mit der API andere Koordinaten kommen", wäre das schlichtweg falsch.

Sonst eben irgendwie:
1. PQ importieren
2. Cache über API aktualisieren, merken, dass sich die Koordinaten geändert haben
3. Nochmal diese GetUserWaypoints aufrufen, um so evtl. heraus zu bekommen, ob Koordinaten von Punkt 1 oder von Punkt 2 denn nun eigentlich die richtigen sein müssten....

Vielleicht denke ich zu negativ oder zu kompliziert, das sind eben nur so die Fallstricke, die mir einfallen. Allerdings verwende ich die Funktion bei gc.com auch nicht.
Vielleicht wäre auch eine Möglichkeit das zu beschleunigen, wenn man nochmal im GS-Forum oder so, auf eine Umsetzung für die PQ und die API drängt.
kann doch nicht sooo schwer sein, zumindest in der API, Original UND korrigierte Koordinaten zu schicken. Das Format hat Groundspeak doch selbst in der Hand.

 

[Koblenzer]

Ich glaube das ist schon extrem schwer zu "lösen"...
Mache ich nach einer PQ eine API-Abfrage, können die Koordinaten überschrieben werden.
Dummerweise ändern sich auch bei ganz normalen Caches ab und an die Koordinaten.
Habe ich nun also per PQ Koordinaten X importiert und sagen dann im Programm: "Aktualisiere ich aber nicht, weil mit der API andere Koordinaten kommen", wäre das schlichtweg falsch.

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!