Doppellistings abgleichen -- cmanager
Moderator: mic@
-
following
Der cmanager erzeugt eine recht hohe Systemlast auf dem OC-Server - dreimal soviel Rechenzeit wie alle übrigen OKAPI-Clients zusammengenommen. Gibt es hier noch Optimierungsmöglichkeiten?
-
Samsung1
[quote="following"]
Der cmanager erzeugt eine recht hohe Systemlast auf dem OC-Server - dreimal soviel Rechenzeit wie alle übrigen OKAPI-Clients zusammengenommen. Gibt es hier noch Optimierungsmöglichkeiten?
[/quote]
Ich fürchte eine nicht unwesentliche Systemlast ist prinzipbedingt. Die würde sich nur reduzieren lassen, wenn man die Duplikatssuche auf dem Server machen würde - um Suchergebnisse dort zentral zu cachen.
Der Suchradius ist aktuell recht groß gewählt, um auch Mysteries mit abweichenden Mysterykoordinaten zu finden. Der ließe sich reduzieren, aber mein Eindruck war, dass da trotzdem nicht sonderlich viele OC-Codes zurückgegeben werden. (Ein mal nach Details abgefragte werden lokal zwischengespeichert.)
Was sich jedoch optimieren ließe, wäre alte Funde nicht zwei mal abzufragen. Das habe ich auf meinem Zettel - werde aber leider vor Mitte Januar zu nichts kommen.
Der cmanager erzeugt eine recht hohe Systemlast auf dem OC-Server - dreimal soviel Rechenzeit wie alle übrigen OKAPI-Clients zusammengenommen. Gibt es hier noch Optimierungsmöglichkeiten?
[/quote]
Ich fürchte eine nicht unwesentliche Systemlast ist prinzipbedingt. Die würde sich nur reduzieren lassen, wenn man die Duplikatssuche auf dem Server machen würde - um Suchergebnisse dort zentral zu cachen.
Der Suchradius ist aktuell recht groß gewählt, um auch Mysteries mit abweichenden Mysterykoordinaten zu finden. Der ließe sich reduzieren, aber mein Eindruck war, dass da trotzdem nicht sonderlich viele OC-Codes zurückgegeben werden. (Ein mal nach Details abgefragte werden lokal zwischengespeichert.)
Was sich jedoch optimieren ließe, wäre alte Funde nicht zwei mal abzufragen. Das habe ich auf meinem Zettel - werde aber leider vor Mitte Januar zu nichts kommen.
-
kamuckel
Guten abend und ein frohes neues jahr erst mal 
wollte eben mal den manager ausprobieren, aber irgendwie... ich häng' da mal meine fehlermeldung mit dran, vielleicht kann einer helfen (runtergeladene version ist die 0.2j)
edit:Betriebssystem ist Linux
wollte eben mal den manager ausprobieren, aber irgendwie... ich häng' da mal meine fehlermeldung mit dran, vielleicht kann einer helfen (runtergeladene version ist die 0.2j)
edit:Betriebssystem ist Linux
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Zuletzt geändert von kamuckel am 01.01.2016, 21:04, insgesamt 1-mal geändert.
-
Bananeweizen
- Nano
- Beiträge: 97
- Registriert: 18.02.2013, 13:18
Feature Request: Bitte beim Auffinden des eigenen Logs den GC-Usernamen case insensitive vergleichen. Hatte grad das gleiche Phänomen wie wolkenstein (kein Button zum Kopieren der Logs). Da Groundspeak Usernamen nicht in verschiedener Groß-/Klein-Schreibung zulässt, führt diese Änderung auch nicht zu Problemen.
Feature Request: Escape zum Schließen jedes Dialogs.
Feature Request: Fenstergrößen merken. Es macht nicht viel Sinn, dass auf meinem großen Monitor jedesmal nur ein Zehntel der Fläche für den Dialog verwendet wird.
Feature Request: Escape zum Schließen jedes Dialogs.
Feature Request: Fenstergrößen merken. Es macht nicht viel Sinn, dass auf meinem großen Monitor jedesmal nur ein Zehntel der Fläche für den Dialog verwendet wird.
Zuletzt geändert von Bananeweizen am 02.01.2016, 15:56, insgesamt 1-mal geändert.
-
following
[quote="Samsung1"]
[quote="following"]
Der cmanager erzeugt eine recht hohe Systemlast auf dem OC-Server - dreimal soviel Rechenzeit wie alle übrigen OKAPI-Clients zusammengenommen. Gibt es hier noch Optimierungsmöglichkeiten?
[/quote]
Ich fürchte eine nicht unwesentliche Systemlast ist prinzipbedingt. Die würde sich nur reduzieren lassen, wenn man die Duplikatssuche auf dem Server machen würde - um Suchergebnisse dort zentral zu cachen.
Der Suchradius ist aktuell recht groß gewählt, um auch Mysteries mit abweichenden Mysterykoordinaten zu finden. Der ließe sich reduzieren, aber mein Eindruck war, dass da trotzdem nicht sonderlich viele OC-Codes zurückgegeben werden. (Ein mal nach Details abgefragte werden lokal zwischengespeichert.)
Was sich jedoch optimieren ließe, wäre alte Funde nicht zwei mal abzufragen. Das habe ich auf meinem Zettel - werde aber leider vor Mitte Januar zu nichts kommen.
[/quote]
Ok. Vielleicht können wir auch in der OKAPI noch etwas optimieren.
[quote="following"]
Der cmanager erzeugt eine recht hohe Systemlast auf dem OC-Server - dreimal soviel Rechenzeit wie alle übrigen OKAPI-Clients zusammengenommen. Gibt es hier noch Optimierungsmöglichkeiten?
[/quote]
Ich fürchte eine nicht unwesentliche Systemlast ist prinzipbedingt. Die würde sich nur reduzieren lassen, wenn man die Duplikatssuche auf dem Server machen würde - um Suchergebnisse dort zentral zu cachen.
Der Suchradius ist aktuell recht groß gewählt, um auch Mysteries mit abweichenden Mysterykoordinaten zu finden. Der ließe sich reduzieren, aber mein Eindruck war, dass da trotzdem nicht sonderlich viele OC-Codes zurückgegeben werden. (Ein mal nach Details abgefragte werden lokal zwischengespeichert.)
Was sich jedoch optimieren ließe, wäre alte Funde nicht zwei mal abzufragen. Das habe ich auf meinem Zettel - werde aber leider vor Mitte Januar zu nichts kommen.
[/quote]
Ok. Vielleicht können wir auch in der OKAPI noch etwas optimieren.
-
hike_biker
Hallo,
hatte von diesem Tool gehört und wollte es mit myfinds.gpx ausprobieren, habe neueste cmanager Version, neuestes JAVA, Windows 7.1 und bekomme identisches Fehlerbild wie oben user "kamuckel". Das Tool will die myfinds-Datei bei OPEN nicht einlesen.
Dann aber mal eine andere GPX eingelesen (PQ über GC erstellt) und die funktioniert!!
Grüße,
hike_biker
hatte von diesem Tool gehört und wollte es mit myfinds.gpx ausprobieren, habe neueste cmanager Version, neuestes JAVA, Windows 7.1 und bekomme identisches Fehlerbild wie oben user "kamuckel". Das Tool will die myfinds-Datei bei OPEN nicht einlesen.
Dann aber mal eine andere GPX eingelesen (PQ über GC erstellt) und die funktioniert!!
Grüße,
hike_biker
-
following
Wie ist der genaue Suchalgorithmus von cmanager?
Es gibt viele Locations, an denen OC- und GC-Caches nahe beieinander liegen, teils sogar im gleichen Versteck. Ein unscharfer Koordinatenvergleich alleine wäre also gefährlich. Mir sind bei Prüfungen von gemeinsam genutzten Locations in den letzten Tagen auch diverse falsch von GC rüberkopierte Logs aufgefallen, wobei ich nicht sagen kann ob das Ocprop oder cachemanager war. Handkopie war oft auszuschließen, dafür waren die Beschreibungen zu verschieden.
Einen perfekten Algorithmus, um passende Caches zu finden, gibt es nicht. Ich denke so ein Tool muss im Zweifelsfall konservativ vorgehen und auf das Kopieren von Logs verzichten, vor allem wenn die Ownernamen nicht übereinstimmen. Allerdings haben geschätzte 10% der Owner unterschiedliche Namen, sodass hierdurch bereits 10% der Logs mit so einem Verfahren nicht abgleichbar sind. Cachenamen weichen relativ oft ab, da kann man wohl nur mit einem Ähnlichkeitsvergleich arbeiten.
Für die Zuordnung von GC- zu OC-Caches gibt es aber eine handgewartete OC-interne Datenbank, die sich z.B. wie folgt nutzen lässt:
http://www.opencaching.de/searchplugin.php?sourceid=waypoint-search&userinput=GC3TX7N
Wie ihr sehr wird OC11ABF gefunden. Der Owner hat keinen GC-Wegpunkt eingetragen, aber wir haben festgestellt dass er identisch mit GC3TX7N ist und das intern vermerkt. (Diese Information wird auch für das Ausblenden von Doppellistings bei der Suche und auf der Karte verwendet.) Diese Wegpunktzuordnung ist bei auf OC aktiven Caches sehr zuverlässig, wesentlich besser als eigene Versuche mit dem Vergleich von Koordinaten, Cache- und Ownernamen. Und sie ist sehr schnell. Caches, die vor Jahren auf OC archiviert wurden, sind allerdings nur unvollständig erfasst.
Es gibt viele Locations, an denen OC- und GC-Caches nahe beieinander liegen, teils sogar im gleichen Versteck. Ein unscharfer Koordinatenvergleich alleine wäre also gefährlich. Mir sind bei Prüfungen von gemeinsam genutzten Locations in den letzten Tagen auch diverse falsch von GC rüberkopierte Logs aufgefallen, wobei ich nicht sagen kann ob das Ocprop oder cachemanager war. Handkopie war oft auszuschließen, dafür waren die Beschreibungen zu verschieden.
Einen perfekten Algorithmus, um passende Caches zu finden, gibt es nicht. Ich denke so ein Tool muss im Zweifelsfall konservativ vorgehen und auf das Kopieren von Logs verzichten, vor allem wenn die Ownernamen nicht übereinstimmen. Allerdings haben geschätzte 10% der Owner unterschiedliche Namen, sodass hierdurch bereits 10% der Logs mit so einem Verfahren nicht abgleichbar sind. Cachenamen weichen relativ oft ab, da kann man wohl nur mit einem Ähnlichkeitsvergleich arbeiten.
Für die Zuordnung von GC- zu OC-Caches gibt es aber eine handgewartete OC-interne Datenbank, die sich z.B. wie folgt nutzen lässt:
http://www.opencaching.de/searchplugin.php?sourceid=waypoint-search&userinput=GC3TX7N
Wie ihr sehr wird OC11ABF gefunden. Der Owner hat keinen GC-Wegpunkt eingetragen, aber wir haben festgestellt dass er identisch mit GC3TX7N ist und das intern vermerkt. (Diese Information wird auch für das Ausblenden von Doppellistings bei der Suche und auf der Karte verwendet.) Diese Wegpunktzuordnung ist bei auf OC aktiven Caches sehr zuverlässig, wesentlich besser als eigene Versuche mit dem Vergleich von Koordinaten, Cache- und Ownernamen. Und sie ist sehr schnell. Caches, die vor Jahren auf OC archiviert wurden, sind allerdings nur unvollständig erfasst.
-
Samsung1
[quote="following"]
Wie ist der genaue Suchalgorithmus von cmanager?
[/quote]
Der Algorithmus ist der folgende. Bei >=80% wird eine Übereinstimmung angenommen
In kürze werde ich wieder etwas mehr Zeit haben. Ich plane dann Bugs zu fixen und cmanager als opensource online zu stellen. Dann kann sich dort jeder mit Ideen einbringen, auch wenn mir gerade mal die Zeit fehlt.
Die DB kannte ich noch nicht. Für die enthaltenen Cache ist sie eine interessante Option.
Wenn dich interessiert, ob cmanager für eine falsche Zuordnung verantwortlich ist, kannst du den GC-Cache mit geotoad in eine PQ stecken und cmanager nach Duplikaten suchen lassen.
Wie ist der genaue Suchalgorithmus von cmanager?
[/quote]
Der Algorithmus ist der folgende. Bei >=80% wird eine Übereinstimmung angenommen
Code: Alles auswählen
public double claculateSimilarity(Geocache g)
{
if( ( this.code_gc != null && this.code_gc.equals(g.code) )
|| (g.code_gc != null && g.code_gc.equals(this.code) ) )
return 1;
double dividend = 0;
double divisor = 0;
divisor++;
if( name.equals( g.getName() ) )
dividend++;
divisor++;
if( coordinate.distance(g.getCoordinate()) < 0.001 )
dividend++;
divisor++;
if( Double.compare(difficulty, g.getDifficulty()) == 0 )
dividend++;
divisor++;
if( Double.compare(terrain, g.getTerrain()) == 0 )
dividend++;
divisor++;
if( type == g.getType() )
dividend++;
if( owner != null )
{
divisor++;
if( owner.equals(g.getOwner()) )
dividend++;
}
if( container != null )
{
divisor++;
if( container == g.getContainer() )
dividend++;
}
if( available != null && archived != null )
{
divisor++;
if( statusAsString().equals(g.statusAsString()) )
dividend++;
}
return dividend / divisor;
}
Die DB kannte ich noch nicht. Für die enthaltenen Cache ist sie eine interessante Option.
Wenn dich interessiert, ob cmanager für eine falsche Zuordnung verantwortlich ist, kannst du den GC-Cache mit geotoad in eine PQ stecken und cmanager nach Duplikaten suchen lassen.
-
following
[quote="Samsung1"]
Der Algorithmus ist der folgende. Bei >=80% wird eine Übereinstimmung angenommen
[/quote]
Interessant. Das ist ein guter Algorithmus, der Fehlerkennungen von Caches verschiedener Owner praktisch ausschließt - denn dort sind die Ownernamen verschieden, in den allermeisten Fällen auch die Cachenamen und mindestens eines von D und T (zwei Owner, zwei Einschätzungen). Hab mal einige kritische Fälle durchgeschaut, die werden alle korrekt behandelt.
Bei Typ und Größe ist Folgendes zu beachten:
OC-Nano = GC-Mikro oder Sonstige Größe
OC-Extra groß = GC groß
OC-Drive-In = GC-Tradi
OC-Mathe/Physikcache = GC Mystery
GC-Earthcache = OC Virtual
GC-Mystery wird auf OC oft versehentlich als "unbekannter / sonstiger Cachetyp" gelistet, wegen des ?:
-> [img]http://www.opencaching.de/resource2/ocstyle/images/cacheicon/unknown.gif[/img]
Der Status-Vergleich schließt ziemlich viele Doppellistings aus, die nur auf OC archiviert wurden. Die fehlen dann in der OC-Fundstatistik des Benutzers. Vielleicht kann mann stattdessen das Datum vergleichen: Der OC-Cache darf nicht nach dem GC-Logdatum gelegt worden sein (date_hidden, bei Events date_created) und nicht vorher archiviert (Datum des Archivierungslogs, oder last_modified falls es fehlt). Die OC-Logs sollten aber nur bei Bedarf abgerufen werden, aus Performancegründen.
Probleme gibt es, wenn ein Owner absichtlich mehrere Caches an gleicher Stelle legt, z.B. [url=http://www.opencaching.de/viewcache.php?wp=OC12599]OC12599[/url] vs. GC6321G mit 80% Übereinstimmung. Für alle Problemfälle könnte man eine zentrale, handgewartete Liste von GC-Only Caches anlegen, die dann vom Abgleich ausgeschlossen werden.
Der Algorithmus ist der folgende. Bei >=80% wird eine Übereinstimmung angenommen
[/quote]
Interessant. Das ist ein guter Algorithmus, der Fehlerkennungen von Caches verschiedener Owner praktisch ausschließt - denn dort sind die Ownernamen verschieden, in den allermeisten Fällen auch die Cachenamen und mindestens eines von D und T (zwei Owner, zwei Einschätzungen). Hab mal einige kritische Fälle durchgeschaut, die werden alle korrekt behandelt.
Bei Typ und Größe ist Folgendes zu beachten:
OC-Nano = GC-Mikro oder Sonstige Größe
OC-Extra groß = GC groß
OC-Drive-In = GC-Tradi
OC-Mathe/Physikcache = GC Mystery
GC-Earthcache = OC Virtual
GC-Mystery wird auf OC oft versehentlich als "unbekannter / sonstiger Cachetyp" gelistet, wegen des ?:
-> [img]http://www.opencaching.de/resource2/ocstyle/images/cacheicon/unknown.gif[/img]Der Status-Vergleich schließt ziemlich viele Doppellistings aus, die nur auf OC archiviert wurden. Die fehlen dann in der OC-Fundstatistik des Benutzers. Vielleicht kann mann stattdessen das Datum vergleichen: Der OC-Cache darf nicht nach dem GC-Logdatum gelegt worden sein (date_hidden, bei Events date_created) und nicht vorher archiviert (Datum des Archivierungslogs, oder last_modified falls es fehlt). Die OC-Logs sollten aber nur bei Bedarf abgerufen werden, aus Performancegründen.
Probleme gibt es, wenn ein Owner absichtlich mehrere Caches an gleicher Stelle legt, z.B. [url=http://www.opencaching.de/viewcache.php?wp=OC12599]OC12599[/url] vs. GC6321G mit 80% Übereinstimmung. Für alle Problemfälle könnte man eine zentrale, handgewartete Liste von GC-Only Caches anlegen, die dann vom Abgleich ausgeschlossen werden.
-
following
[quote="Samsung1"]
Der Suchradius ist aktuell recht groß gewählt, um auch Mysteries mit abweichenden Mysterykoordinaten zu finden. Der ließe sich reduzieren, aber mein Eindruck war, dass da trotzdem nicht sonderlich viele OC-Codes zurückgegeben werden. [/quote]
Aktuell wird anscheinend bei allen Cachetypen in 1 km Umkreis gesucht. Ich schlage vor, dass zumindest für Tradis auf 50 Meter zu reduzieren; das sollte die Systembelastung wesentlich senken.
Der Suchradius ist aktuell recht groß gewählt, um auch Mysteries mit abweichenden Mysterykoordinaten zu finden. Der ließe sich reduzieren, aber mein Eindruck war, dass da trotzdem nicht sonderlich viele OC-Codes zurückgegeben werden. [/quote]
Aktuell wird anscheinend bei allen Cachetypen in 1 km Umkreis gesucht. Ich schlage vor, dass zumindest für Tradis auf 50 Meter zu reduzieren; das sollte die Systembelastung wesentlich senken.
Zuletzt geändert von following am 14.01.2016, 20:59, insgesamt 1-mal geändert.
-
Samsung1
Ein kleines Update, dass mir wichtig genug erschien, um es in meinen Zeitplan zu quetschen: Version 0.2k kopiert jetzt nicht mehr die von GC.com generierte Log-Uhrzeit aus der Pocket-Querry in die Logs auf OC, da diese etwas.... willkürlich erscheint. Weitere Bugs behebt die Version noch nicht.
Zuletzt geändert von Samsung1 am 16.01.2016, 21:32, insgesamt 1-mal geändert.
-
Samsung1
Version 0.2l hat das Ziel die Last auf die OC-Datenbank zu reduzieren. Hierfür gibt es jetzt einen lokalen Cache, der sicher merkt, wenn es zu einem GC-Cache in der Vergangenheit keine Treffer gab. Diese Resultate sind zwischen 3 und 12 Monaten gültig, damit nicht alle Cache auf einen Schlag erneut online überprüft werden. Nach dieser Zeit wird wieder der Server angefragt. Als netter Nebeneffekt sollten sich wiederkehrende Abgleiche damit deutlich beschleunigen.
Ferner gilt der große Suchradius jetzt nur noch für "Unknown" Cache.
Leider enthält auch diese Version noch keine Bugfixe.
Ferner gilt der große Suchradius jetzt nur noch für "Unknown" Cache.
Leider enthält auch diese Version noch keine Bugfixe.
Zuletzt geändert von Samsung1 am 17.01.2016, 00:21, insgesamt 1-mal geändert.
-
Samsung1
Leider bin ich kein GC-Premium Mitglied und mit alten PQs kann ich die Fehler nicht reproduzieren. Mag mir jemand eine PQ zur Verfügung stellen, mit der es kracht? Vielleicht per Dropbox o.ä. als PM?
-
following
[quote="Samsung1"]
Ferner gilt der große Suchradius jetzt nur noch für "Unknown" Cache.
[/quote]
Es gibt viele Multis bei denen auf GC die Station1 und auf OC der Parkplatz oder sonstwas eingetragen ist. Manchmal auch umgekehrt. :-) Könnte also Sinn machen, auch Multis im großen Radius zu suchen.
Ferner gilt der große Suchradius jetzt nur noch für "Unknown" Cache.
[/quote]
Es gibt viele Multis bei denen auf GC die Station1 und auf OC der Parkplatz oder sonstwas eingetragen ist. Manchmal auch umgekehrt. :-) Könnte also Sinn machen, auch Multis im großen Radius zu suchen.