GC Spider 2.0

[~Idefix~]

Beim Hinzufügen neuer Caches zu großen Profilen (ohne schon geladene zu akualisieren) sehe ich da Potential für einen großen Zeitgewinn.

Und das ist auch eine Funktion, die ich öfters nutze. Denn in den Bereichen, wo ich oft unterwegs bin, da habe ich den Datenbestand gerne vollständig. Allerdings ist es für mich nicht relevant, dass die Datensätze aktuell sind.

 

[MiK]

In den meisten Fällen will man aber alle Daten zu den Caches. Dann ist der Zeitgewinn nicht so groß. Außerdem funktioniert mit der Karte wahrscheinlich ein Teil der Aktualisierungsfunktionalität nicht. Wenn überhaupt. Ich sehe für meinen Anwendungsfall keine großen Vorteile. Und wegen der Nachteile braucht man die alte Funktionalität dann noch parallel.

 

[peter.poetzi]

Ja, beide Funktionen paralell würde auch genügen.

 

[arbor95]

Die gelieferten Infos sind ja zum Cachen recht spärlich :

{"lat": 48.767667, "id": 49161, "lon": 9.099833, "gc": "GCC009", "ctid": 3, "f": false, "o": false, "ia": true, "nn": "QuizCache 1"},
{"lat": 48.758333, "id": 408837, "lon": 9.091667, "gc": "GCWG77", "ctid": 8, "f": false, "o": false, "ia": true, "nn": "Bären Sudoku"},
{"lat": 48.76465, "id": 229243, "lon": 9.08495, "gc": "GCNFAW", "ctid": 2, "f": false, "o": false, "ia": true, "nn": "3Gigundus"},

Hast du ne Ahnung wofür "f","o" und "ia" stehen?
und was kann ich mit der "id" anfangen?

 

[peter.poetzi]

ia ist wenn true: enabled; wenn false disabled

ctid=art des caches; mit http://www.geocaching.com/images/WptTypes/sm/CTID.gif kann man das symbol kriegen

die id ist für nix gut

f und o weiß ich auch nicht; mit deaktivierten caches haben die nix zu tun, archivierte werden nämlich nicht geliefert . Ich habe schon über 30k heruntergeladen und f und o war immer false.

man kriegt allerding lat und longitude, somit kann man die cache Beschreibung anonym aufrufen, da man die Koordinaten schon hat.

 

[ElCid68]

f=1 ist found und o=1 heisst own cache

 

[peter.poetzi]

achso, deswegen waren die immer false, ich spidere nämlich anonym(ohne cookies)

 

[Wutschkow]

In den meisten Fällen will man aber alle Daten zu den Caches. Dann ist der Zeitgewinn nicht so groß. Außerdem funktioniert mit der Karte wahrscheinlich ein Teil der Aktualisierungsfunktionalität nicht. Wenn überhaupt. Ich sehe für meinen Anwendungsfall keine großen Vorteile. Und wegen der Nachteile braucht man die alte Funktionalität dann noch parallel.

Ich denke, das "2.0" ist etwas irreführend. Die neue Variante kann nur eine Ergänzung zur vorhandenen Spiderfunktion sein. Sie hat IMHO da Vorteile, wo man mit möglichst wenig Traffic und Zeitaufwand erstmal einen Überblick haben will, um dann einen Auswahl zu treffen. Das hier im Thread genannte Beispiel, für einen größeren Bereich (z. B. die Urlaubsregion) erstmal alle Caches runterzuladen, dann die GCVotes dazuzuladen und dann nur alle Caches >=x GCVote-Sterne ausführlich zu spidern, finde ich schon sehr schön. Da hätte diese Variante deutliche Vorteile gegenüber dem klassischen Spidern.

 

[arbor95]

man hat ja hierbei nur ein klein wenig mehr Info als beim loc-Import.

Danach würden dann diese Warndreiecke im Listing sein. Hier wird ja der Cachetyp angegeben,aber es fehlen noch andere Infos. Wenn der Cachetyp, wie beim loc-Import, auf Custom gesetzt würde, kämen diese nicht.
?

 

[Wutschkow]

Wo bekomme ich denn innerhalb weniger Sekunden und ohne viel Traffic eine loc-Datei her, die alle Caches z.B. im Großraum HH enthält? Hier sehe ich den entscheidenden Vorteil dieser Methode.

Um die GCVotes abzurufen, braucht man doch wohl nur die Waypoint-ID, oder?
Wenn der Typ zusätzlich gesetzt wird, könnte man auch danach filtern und z.B. als Mystery-Hasser alle Unknowns rausfiltern.

Das mit den Warndreiecken sehe ich nicht als Problem. Die Aussage, dass mit diesen Caches etwas nicht in Ordnung ist, stimmt ja. Man sollte halt (wie bei manch anderen CW-Funktionen auch) wissen was man tut.

Ich würde diese Funktion weniger als "Spidern 2.0", sondern eher als "Scannen 1.0" verstehen. Erstmal ein grober Überblick, um eine Vorauswahl zu treffen, dann geht es mit richtigem Spidern (oder vielmehr per Aktualisieren) in die Details.

Vielleicht wäre es ja auch ein Kandidat für ein weiteres Osterei, falls Bedenken bestehen, dass eine solche Funktion von der Mehreit der Nutzer nicht bzw. missverstanden wird.

 

[schwaller]

ich würde das ersteinmal als ergänzung, welche tatsächlich per prefs freigeschaltet werden kann, bevorzugen.
für eine generelle sichtbaren menuepunkt denke ich, sollten ersteinmal erfahrungen von ambitionierten anwendern gemacht werden, so das das ganze dann zu ausgereiften funktionen wachsen kann.

werden jedoch mit solch doch recht experimentellen features die unerfahrenen user konfrontiert, so sehe ich zu viele fragen und probleme.

von daher einbauen und das als "easteregg" - erfahrungen im handling gewinnen und dann brainstorming und endgültige umsetzung. eine komplette ablösung der bisherigen spiderengine sehe ich in dem verfahren eh nicht, da es zu wenig infos liefert. zum überblick gewinnen, aussortieren mittels gc-vote etc sehe ich aber gewaltiges potential.

 

[arbor95]

dann mal viel Vergnügen.

 

[Tritop99]

Das geht ja echt fix. Allerdings loggt sich CW vor dem Spidern mit dem Alias ein. Nicht dass man dann plötzlich doch gebannt wird.

Hab jetzt mal 5 km (ca. 200 Caches) mit der JAVA-Version gespidert. Das Einloggen hat dabei am längsten gedauert. Die GC-Votes waren in weniger als 2 Sekunden nachgeladen.

Die deaktivierten Caches werden auch entsprechend markiert.

Mal sehen, was sich noch so anstellen lässt.

 

[arbor95]

Bannen wegen was ? Bei 5 km hast du höchsten 3 Webseitenzugriffe! Die meiste Zeit vergeht mit dem Schreiben der cache.xml Dateien! So schonend gings noch nie!

 

[~Idefix~]

Gerade getestet.
Ich finde diese Funktion klasse!

Mit 15km Radius auf meinem Home-Profil ausprobiert.
Danach nach Terrain und Difficulty nach <= 0.5 gefiltert, um die neuen rauszukriegen und markieren zu können.
Und nach gefühlten 20 Sekunden wusste ich, dass ich bei Gegelenheit mal 46 Caches nachspidern müsste.

Und was das einloggen angeht. Obwohl es nach der Beschreibung im ersten Post dieses Threads eigentlich nicht nötig ist, sollte das ruhig beibehalten werden. Als kleine Sicherheit, falls es doch mal jemand übertreiben möchte...

Wieder mal daumen hoch für die tolle Arbeit!!
Gruß
~Idefix~

 

[arbor95]

wenn man sich nicht einlogged kann found und own nicht bestimmt werden. also der Schalter "funde nicht laden" wäre wirkungslos.
Aber man kann ja noch einen Schalter einbauen.

 

[~Idefix~]

Nö. Lass es so. Der soll sich ruhig einloggen.
Ich find das besser, wenn er es tut!

 

[Wutschkow]

Ich finde auch, dass es ruhig beim Einloggen bleiben kann.
Der Vorteil der Methode ist ja gerade, dass sie ziemlich wenig Traffic erzeugt.
Und wer das ausnutzen will, um die Caches von ganz Mitteleuropa einzuscannen, der soll halt ggf. die Konsequenzen tragen.

 

[jhohn]

Das geht echt fix, tolle Sache. Allerdings bekomme ich da mehr Caches als ich eigentlich will. Ich habe in einem Bereich von 16km gespidert um zu sehen was es da neues gibt. Da waren auch ein paar neue bei. Vor allem habe ich aber viele Caches bis 20km Entfernung bekommen, die ich gar nicht haben will.
Liegt das daran dass ein Rechteck gespidert wird und die 20km dann in die Ecken des Rechtecks reichen?

 

[Wutschkow]

Liegt das daran dass ein Rechteck gespidert wird und die 20km dann in die Ecken des Rechtecks reichen?

Ja. Diese Methode basiert auf der Kartenansicht von GC.com und die Karten sind nun mal rechteckig und nicht rund, von daher ist ein gewisser Overhead unvermeidlich. Aber Du kannst ja anschließend in CW nach Entfernung sortieren oder filtern und so alles wieder rausschmeißen, was tatsächlich über Deiner gewünschten Höchstgrenze liegt.