Doppellistings abgleichen -- cmanager

[Slini11]

Ich vermute, dass es daran liegt?
[quote="Samsung1"]
Das mit den potentiell falschen Logs hat mir keine Ruhe gelassen...

• Die Vergleichsentscheidung stützt sich jetzt auch auf mehr Daten (unter andrem jetzt auch Owner-Name, Behälter, Archivierungsstatus). Wenn 80% der Merkmale übereinstimmen oder ein GC-Code hinterlegt ist, wird er als Treffer ausgegeben.
• Der Copy-Log-Dialog ist jetzt schön bunt
• Der Export ist auch unter Windows in UTF-8
• Die Fenster auch Maximieren zu können war etwas tricky. Ich habe einen Workaround geschustert, der hoffentlich gut funktioniert .

[/quote]
Optimaler wäre wohl, wenn alle Treffer ausgegeben werden, aber dahinter in einer Tabelle die Prozent-Anzahl steht (vllt. noch >80% = grün hinterlegt, 60-80 gelb, < 60 rot (oder so)). Dann kann man selbst einschätzen, ob der Cacher ein potentieller Treffer ist.

[Slini11]

Der D/T-Abgleich funktioniert nicht bzw. wird dieser falsch dargestellt.

[Samsung1]

Oh man... danke @Slini11. Ist behoben. Ich hoffe, dass jetzt nicht die FalsePositives-Rate explodiert, wo Terrain und Difficulty berücksichtigt werden 


Durch Anklicken eines Caches wird jetzt das Listing ausgewählt und mit Strg+Linksklick wird der Cache in der Liste ausgewählt.


Das Problem von Dr.Acula macht mich aber etwas ratlos. Warum liefert die OKAPI bei

Code: Alles auswählen

http://www.opencaching.de/okapi/services/caches/search/nearest?consumer_key=$key&format=xmlmap2&center=51.43890|7.464567&radius=0.02&status=Available|Temporarily%20unavailable|Archived

nicht  [url=http://opencaching.de/OCD346]http://opencaching.de/OCD346[/url] zurück?

[Dr.Acula]

Super, also die 0.2d war auf jeden Fall schon mal wieder erfolgreicher als die 0.2c - ich konnte noch zwei weitere Caches nachloggen.

Ich habe leider noch nicht die weiteren fehlenden zuordnen können, nur von der Anzahl her. Aktuell gibt die Gesamtliste 126 Kandidaten her. Dem gegenüber stehen aber meine 159 OC Gesamtfunde abzüglich 18 OC only, Rest 141 - also müßte das Tool eigentlich noch 15 weitere Caches aus meiner GPX ausgeben (bei V0.2c waren es noch 22 ungeklärte).

Ich finde es aber schon mal klasse, was das Prog schon alles kann. Den Rest findet Ihr sicherlich auch noch. Leider bin ich auf Java-Ebene keine Hilfe bei der Recherche.

Viele Grüße, Dr.Acula

[hmpfgnrrr]

Ich habe die neueste Version noch einmal ausprobiert - und war echt begeistert. Das meiste hatte ich zwar bereits nachgetragen, aber ein paar Duplikate hat er doch noch entdeckt. Und auch das vollautomatische Übertragen hat super funktioniert.

Da wäre es jetzt vielleicht Zeit für ein Feature Request? Ich habe etwa 150 Caches, die bei OC und GC (zum Teil seit etlichen Jahren) archiviert sind. Die möchte ich nicht unbedingt nachtragen. Wenn ich allerdings irgendwann das Tool wieder laufen lasse, werden sie mir die Ergebnisliste verstopfen. Daher würde ich mir wünschen, dass es
- entweder eine Option gibt, dass Caches, die auf beiden Plattformen archiviert sind, nicht angezeigt werden, oder
- die Ergebnisliste sortiert wird nach dem Funddatum bei GC, so dass meine neuesten Funde unten (oder oben) in der Liste auftauchen.

[OConly]

Um herauszufinden, ob ein Cache bei GC archiviert ist, muss entweder die PQ sehr aktuell sein, oder eine Abfrage von GC erfolgen. Letzteres dürfte ausfallen.

Wobei sich mir nicht erschließt, weshalb man diese Caches nicht nachloggen möchte. Gefunden hat man sie ja schließlich.

[Samsung1]

[quote="Dr.Acula"]
Ich habe leider noch nicht die weiteren fehlenden zuordnen können, nur von der Anzahl her. Aktuell gibt die Gesamtliste 126 Kandidaten her. Dem gegenüber stehen aber meine 159 OC Gesamtfunde abzüglich 18 OC only, Rest 141 - also müßte das Tool eigentlich noch 15 weitere Caches aus meiner GPX ausgeben (bei V0.2c waren es noch 22 ungeklärte).
[/quote]
Also aktuell verhält sich das für mich noch wie mit den Socken und der heimischen Waschmaschine. Keinen Schimmer, wo die verschwinden . Ich habe meine API-Frage mal im Entwickler Bereich gestellt – vielleicht bringt das ja noch etwas Licht ins Dunkel.
Alternativ ist noch eine potentielle Erklärung in der Art deiner Rechnung zu finden: Es wird ja leider nicht jeder OC-Only mit dem entsprechenden Attribut als solcher gekennzeichnet.

[quote="hmpfgnrrr"]
- die Ergebnisliste sortiert wird nach dem Funddatum bei GC, so dass meine neuesten Funde unten (oder oben) in der Liste auftauchen.
[/quote]
Ja, so eine Funktion habe ich auf der Todo-Liste

[Samsung1]

Mit ein klein wenig Stolz darf ich euch cmanager in der Version 0.2e vorstellen, die für mich ein persönlicher Meilenstein ist. Jetzt neu hinzugekommen sind

• Filter für D und T
• Cacheauswahl durch ziehen eines Quadrats auf der Karte

Damit sollte die rudimentäre Grundausstattung komplett sein, um sich in größeren PQs orientieren zu können

[url=http://www.rq-project.net/others/cm/cm.zip]http://www.rq-project.net/others/cm/cm.zip[/url]

[Samsung1]

Ein kleines Update ist online mit Korrekturen / Ergänzungen hier und da und einer nach Logdatum sortierten Liste der Duplikate

[Samsung1]

following war so nett den OKAPI-Bug zu fixen. Damit sollten jetzt ein paar mehr Treffer zu Stande kommen 

[Slini11]

Hi, ich hab gerade vergessen bei der neuen Version den OKAPI-Token anzufordern und dann sprang mir erstmal so ne komische Fehlermeldung entgegen. Es wäre cool, dass, wenn man das "Find on OC" ausführt und noch keinen Token angeforderthat, eine Infobox kommt, dass man noch einen Token benötigt (und für Neulinge am besten noch ein "Menu->Settings->opencaching.de" dazu ). Sonst irritiert diese aktuelle Fehlermeldung vielleicht ein wenig  .

[Dr.Acula]

Hallo,

[quote="Samsung1"]
Alternativ ist noch eine potentielle Erklärung in der Art deiner Rechnung zu finden: Es wird ja leider nicht jeder OC-Only mit dem entsprechenden Attribut als solcher gekennzeichnet.[/quote]

Nein, das wußte ich schon. Von den 18 OConly sind nur 12 als solche markiert. Daran liegt es aber nicht.

In Version 0.2e und f wurden nochmal 2 Caches mehr gefunden.

Mit der sortierten Ausgabe konnte ich jetzt mal auf die Suche gehen, wo denn noch etwas fehlen könnte. Ergebnis:

- Das mit der Sortierung paßt noch nicht so 100%. OC2A30 / GCHTA7 wurde von mir auf beiden Plattformen am 09.03.2014 geloggt, steht in der Liste aber noch vor meinem ersten Cache vom 11.10.2004.

- fehlende Duplikate; wie angekündigt genau 13:
OC948B / GC1ZRDV Reiglersbachsee
OC174D / GCTBWH Crailsheim per Auto
OC1467 / GCQJZP Helgoland Catamaran Quicky
OC4551 / GC16Q2H Motte Keyenberg
OC8F33 / GC1P7V2 Donald´s Badewanne
OCF83C / GC4675C Klaus Autowerkstatt (Kinder-Cache)
OCD85A / GC39105 Ein “Schatz” aus der Antike
OCE5D1 / GC33W4R Kleine Prinzessin in der Stemke
OC1158E / GC4VRCT Händel oder Bruckner
OC110D9 / GC58CJT Tu was Gutes...
OC11577 / GC598KJ SPY
OC111B6 / GC53AX3 Piep Piep Piep
OC1120F / GC58YWX Ein Nano an der Kreuzung klebt...

Ich hoffe mal, daß diese Liste Dir nun hilft dem Bug auf die Spur zu kommen. Und ja, diese Caches sind in der verwendeten GPX tatsächlich enthalten. 

Viele Grüße, Dr.Acula

[Samsung1]

Dank tatkräftiger Unterstützung von Dr.Acula konnte ich die Erkennungsrate noch ein wenig erhöhen. Meine Hauptveränderung hierfür ist, dass cmanager die OKAPI jetzt nicht mehr nach Cachen im 20m sondern 1km Radius befragt. Damit die OKAPI nicht mit sinnlosen Anfragen bombardiert wird, habe ich einen lokalen Cache (*höhö*) eingebaut, der ca. 2/3 der anfallenden Abfragen abfängt, weil die Antwort schon vorliegt. Dieser große Radius ist scheinbar nötig, da zumindest Mystery-Owner scheinbar gerne ihre ? durch die Landschaft schieben.

Die verbleibenden Nicht-gefundenden untergliedern sich in die folgenden Eigenschaften:

• Koordinaten weichen >1km ab.
• Listing ist gesperrt (dann kennt die OKAPI den Cache nicht).
• Die Caches haben keinen GC-Code und sind sich zu unähnlich.

Zusätzlich enthält die 0.2g jetzt einen rudimentären Text-Export im Duplikats-Fenster.

[DL3BZZ]

Hej, wollte mal wiede rdie aktuelle Version laden, aber der Link funtz net

[Slini11]

Stimmt, alternativ gibt die Datei meinst auch immer noch auf https://drive.google.com/folderview?id= ... aring#grid.