Doppellistings abgleichen -- cmanager

[FriedrichFröbel]

Update: habe gerade im Issue Tracker gelesen, dass die OKAPI nicht nach GC-Code suchen kann. Wäre es dann nicht sinnvoll, die OKAPI entsprechend zu erweitern?

Es gab mal eine funktionierende Shadow-List-API, die extra für den cmanager eingeführt wurde (unter https://www.opencaching.de/api/gc2oc.php) und genau diese Funktionalität (über eine komprimierte CSV-Datei) zur Verfügung stellte. Dort gab es neben den offiziell eingetragenen Wegpunkten (durch den Owner angegeben) auch manuell gepflegte - unter anderem wurden dazu die geloggten Duplikate des cmanagers verwendet. Wie die Zukunft dieser Funktionalität bzw. eines entsprechenden OKAPI-Parameters aussieht, weiß ich nicht. Aktuell ist mir - wie auch im Issue erwähnt - nur der Umweg über einen OKAPI-Dump bekannt, der aber für eine direkte Integration nicht praktikabel (und auf direktem Wege auch nicht wirklich erlaubt) ist.

[mic@]

Update: habe gerade im Issue Tracker gelesen, dass die OKAPI nicht nach GC-Code suchen kann.

Wozu in die Ferne schweifen (OKAPI), wenn das Gute liegt so nah:
Wenn der GC-Wegpunkt eingetragen ist, dann klappt auch ein https://opencaching.de/GCVYH3
Wenn der GC-Wegpunkt nicht eingetragen wurde, kommt ein Fehler: https://opencaching.de/GC3724A

[j-he]

Wozu in die Ferne schweifen (OKAPI), wenn das Gute liegt so nah:
Wenn der GC-Wegpunkt eingetragen ist, dann klappt auch ein https://opencaching.de/GCVYH3
Wenn der GC-Wegpunkt nicht eingetragen wurde, kommt ein Fehler: https://opencaching.de/GC3724A

Die Funktionalität kannte ich noch nicht - sehr coole Sache! 
Aber für eine Nutzung im cmanager erscheint mir das eher nicht praktikabel. Denn dann müsste man das Resultat-HTML parsen, um da den OC-Code (und ggf. die weiteren benötigten Infos) irgendwie draus zu extrahieren, oder? Da wird dann ja, wenn eine 10000-Funde gpx-Datei geprüft werden soll, ganz schön viel an langen Listings inklusive Logs unnötig abgerufen.
Aber nun gut, ich bin kein Programmierer (mehr) und halte mich daher lieber zurück mit mehr oder weniger klugen Kommentaren. 

[FriedrichFröbel]

Update: habe gerade im Issue Tracker gelesen, dass die OKAPI nicht nach GC-Code suchen kann.

Wozu in die Ferne schweifen (OKAPI), wenn das Gute liegt so nah:
Wenn der GC-Wegpunkt eingetragen ist, dann klappt auch ein https://opencaching.de/GCVYH3
Wenn der GC-Wegpunkt nicht eingetragen wurde, kommt ein Fehler: https://opencaching.de/GC3724A

Das funktioniert allerdings nur eingeschränkt und lässt sich (wie von j-he angemerkt) auch schlecht verarbeiten.

Warum eingeschränkt? Es gibt rund 450 GC-Codes, die mehr als einmal gesetzt sind (bis zu viermal, manche davon sind auch ungültig) - beim Aufruf der Seite wird dann der alphabetisch erste OC-Code verwendet, der nicht unbedingt der gesuchte sein muss.

[FriedrichFröbel]

Mittlerweile sind die genannten APIs (Shadow List und XML) durch eine Aktualisierung des Server-Codes verschwunden.

Wer allerdings das Ganze ein wenig auf GitHub verfolgt hat, weiß möglicherweise, dass ich mittlerweile die Erstellung der Mapping-Table auf Basis der OKAPI-Daten (mit Fulldump) selbst implementiert habe. Die Erzeugung selbst scheint mittlerweile automatisiert mittels Cron einigermaßen verlässlich zu laufen, auch wenn die Daten bisher noch nicht öffentlich verfügbar sind (da ich noch ein paar Dinge testen möchte). Wann das integriert wird, kann ich noch nicht sagen, aber ich bin auch offen für PRs.

[mic@]

Hier ein Feature-Wunsch, der sich beim gestrigen Newbie-Event gezeigt hat:
Es wäre toll, wenn man parallel zum Logtext auch eventuelle Fotos übertragen könnte? Wäre ja gerade für Webcam Caches nicht ganz unwichtig...


Ansonsten DANKE nochmal für dieses tolle Tool. Es erleichtert die Arbeit mit OC ungemein!

[FriedrichFröbel]

Hier ein Feature-Wunsch, der sich beim gestrigen Newbie-Event gezeigt hat:
Es wäre toll, wenn man parallel zum Logtext auch eventuelle Fotos übertragen könnte? Wäre ja gerade für Webcam Caches nicht ganz unwichtig...

Siehe https://forum.opencaching.de/index.php?topic=4348.msg64771#msg64771. In der aktuellen Entwicklungs-Version sollte aber zumindest mittlerweile der gesendete Log auf Knopfdruck aufrufbar sein.

[Christian]

Hallo zusammen,

ich wurde von Mic@ auf dieses Forum aufmerksam gemacht.

Habe ebenfalls das Problem, dass nicht alle Caches erkannt werden.

Getestet mit Version 0.2.48 / 0.4.0 / 53393931 (beim öffnen steht da aber auch 0.4.0)
Java Version 8 Update 251 (Build 1.8.0_251-b08)

Hier mal 4 Beispiele:

Mehrheitlich bei Multis. Koords sind bei GC geändert...

https://coord.info/GC3D2DZ
https://opencaching.de/OCE61A

https://coord.info/GC1QKNW
https://opencaching.de/OCF919

https://coord.info/GC35JG2
https://opencaching.de/OCDFB9

Aber auch z.B. diesen Tradi findet er bei mir nicht:

https://coord.info/GC5Q8MR
https://opencaching.de/OC11E0B


Hab die 4 genannten Beispiele mal in eine separate GPX gepackt und auf die ursprünglichen Koordinaten zurück gesetzt.
Selbst damit wurde keiner dieser 4 Caches gefunden.

Auch erscheint mir die Synchronisierung sehr schnell. (ca. 2sec. für gut 4000 Caches)
Bei "Find on OC" werden dafür ca. 25sec benötigt, dennoch werden lediglich 93 double gefunden.

Gruß Chris

[FriedrichFröbel]

Die Versionsdifferenz bei den Entwicklungsversionen ist gewollt - das macht unter anderem die Updatesuche einfacher.

Bei den Problemen müsste ich mir das bei Gelegenheit genauer anschauen, aber bei GC3D2DZ sind D, T und Größe unterschiedlich, bei GC5Q8MR D und T. Bei dem Rest habe ich keine Ahnung, es gibt aber teilweise anwendungsintern (oder in den verfügbaren Daten) Rundungsprobleme bei den Koordinaten. Ob allgemein eine Änderung der Ähnlichkeit von 80 % auf einen niedrigeren Wert etwas bringt, keine Ahnung. Zumindest teilweise sollte aber die geplante Wiedereinführung der Übersetzungstabelle GC -> OC nach Angaben der Owner etwas bringen.

Zur Geschwindigkeit: Keine Ahnung, aber erfolglose Suchen werden temporär gespeichert und nicht wiederholt. Bereits auf OC geloggte Caches werden zudem nicht mit angezeigt und es gibt auch - wie du bereits gesehen hast - möglicherweise False Negatives, zudem sind nicht alle GC-Caches auch bei OC.

[Christian]

Bei den Problemen müsste ich mir das bei Gelegenheit genauer anschauen, aber bei GC3D2DZ sind D, T und Größe unterschiedlich, bei GC5Q8MR D und T. Bei dem Rest habe ich keine Ahnung, es gibt aber teilweise anwendungsintern (oder in den verfügbaren Daten) Rundungsprobleme bei den Koordinaten. Ob allgemein eine Änderung der Ähnlichkeit von 80 % auf einen niedrigeren Wert etwas bringt, keine Ahnung. Zumindest teilweise sollte aber die geplante Wiedereinführung der Übersetzungstabelle GC -> OC nach Angaben der Owner etwas bringen.

Aber: gleicher Owner, gleicher Cachename, gleiche Koords und das Listing ist auch identisch.

D/T und Größe wurde möglicherweise mal bei GC angepasst und in OC "vergessen"

[FriedrichFröbel]

Gerade nachgeschaut (mit einem aktuellen Build (Commit 5393931) unter Java 11.0.7):

• GC3D2DZ: Übereinstimmung zu 50 % (< 80 %), da D und T abweichend und der OC-Name mit einem Leerzeichen endet.
• GC1QKNW: Übereinstimmung zu 100 %, wenn keine Koordinaten geändert sind, da der gesetzte GC-Wegpunkt erkannt wird.
• GC35JG2: Übereinstimmung zu 100 %, wenn keine Koordinaten geändert sind.
• GC5Q8MR: Übereinstimmung zu 2/3 (< 80 %), da D und T abweichend.

Owner, Größe und Beschreibung werden zum aktuellen Zeitpunkt nicht verglichen, da diese nicht initial mit abgerufen werden (die Beschreibung an sich ist auch tendenziell eher schwierig für einen ordentlichen Abgleich verwendbar). Ich habe an den eigentlichen Vergleichskritieren nichts verändert - die stammen noch aus der ursprünglichen Version. Möglicherweise lassen sich aber zumindest Owner und Größe noch mit vergleichen (nach Evaluation, vgl. GitHub-Issue) und der Name für den Vergleich "strippen".

Auf die durch den Owner nicht getätigten Anpassungen habe ich logischerweise keinen Einfluss.

[fraggle_DE]

Möglicherweise lassen sich aber zumindest Owner und Größe noch mit vergleichen und der Name für den Vergleich "strippen".

Sind die beiden Sachen wirklich so einfach vergleichbar? Wenn ich mir meinen GC-Namen "fraggle_[de]" und meinen OC-Namen "fraggle_DE" anschaue, würde dieser beim Vergleich durchfallen.

Ähnlich sehe ich es bei den Containergröße. Die werden auch gerne nach Belieben verteilt. Zumal bei sie bei OC anders eingeteilt sind.

[FriedrichFröbel]

Möglicherweise lassen sich aber zumindest Owner und Größe noch mit vergleichen und der Name für den Vergleich "strippen".

Sind die beiden Sachen wirklich so einfach vergleichbar? Wenn ich mir meinen GC-Namen "fraggle_[de]" und meinen OC-Namen "fraggle_DE" anschaue, würde dieser beim Vergleich durchfallen.

Ähnlich sehe ich es bei den Containergröße. Die werden auch gerne nach Belieben verteilt. Zumal bei sie bei OC anders eingeteilt sind.

Ich hatte meinen Kommentar nachträglich noch angepasst und auf den GitHub-Issue verwiesen. Dort erwähne ich bereits die Problematik mit der Größe (brauchbares Mapping wird benötigt), das mit dem Namen habe ich dort auch ergänzt. Bevor das endgültig Einzug hält, müsste man (nach einer ersten Implementierung) erst noch ordentlich evaluieren, ob es wirklich den gewünschten Fortschritt bringt.

[hmpfgnrrr]

Ich habe einen Cache, den ich bei OC archiviert habe und bei GC zur Adoption weggegeben habe (und dann selbst geloggt habe, ich gebe es zu). Korrekterweise bekomme ich den als Duplikat angezeigt. Viel Sinn macht es aber nicht, meinen eigenen Cache nachzuloggen.

Das wird wohl auch Caches betreffen, die man gefunden und später adoptiert hat und dann bei OC reinstellt.

Das ist zwar ein Fall, der bestimmt nicht sonderlich häufig vorkommt, aber vielleicht kann man in der Ergebnisliste die Caches ausblenden, bei denen man selbst Owner ist.

[FriedrichFröbel]

Ich habe einen Cache, den ich bei OC archiviert habe und bei GC zur Adoption weggegeben habe (und dann selbst geloggt habe, ich gebe es zu). Korrekterweise bekomme ich den als Duplikat angezeigt. Viel Sinn macht es aber nicht, meinen eigenen Cache nachzuloggen.

Das wird wohl auch Caches betreffen, die man gefunden und später adoptiert hat und dann bei OC reinstellt.

Das ist zwar ein Fall, der bestimmt nicht sonderlich häufig vorkommt, aber vielleicht kann man in der Ergebnisliste die Caches ausblenden, bei denen man selbst Owner ist.

Lässt sich sicherlich realisieren und ich habe auch einen entsprechenden GitHub-Issue angelegt. Da das Ganze aber relativ selten vorkommen und beim Prüfen vor dem Loggen auch auffallen sollte, dürfte die Priorität relativ niedrig sein.