Diese Website existiert nur weil wir Werbung mit AdSense ausliefern.
Bitte den AdBlocker daher auf dieser Website ausschalten! Danke.

rbgeo

Geocaching-Logs und -Listings zu Statistik-Webseiten und Opencaching konvertieren

Moderatoren: HSCA, Lapu-Lapu, fogg

Benutzeravatar
simonszu
Geocacher
Beiträge: 211
Registriert: Mo 18. Jan 2010, 19:08

rbgeo

Beitrag von simonszu » Do 27. Feb 2014, 14:54

Hallo zusammen,

ermutigt durch den Thread zu geolog++ und meinem ebenfalls bestehenden Unmut über geolog (ohne die Leistungen der Developer zu schmälern) habe ich angefangen, ein eigenes Scrape-and-Statistics-Script zu schreiben.

Ich habe mich von den Zielen erstmal an Geolog orientiert, mal gucken, was ich davon schaffe, und was da noch erweiterbar ist.

Der momentane Status der Implementation beinhaltet:
- Login auf GC.com
- Abrufen einer Liste aller Caches, an denen man beteiligt war (als Cacher oder als Owner)
- Scrapen der Daten zu den Caches
- Speichern der Daten in einer SQLite-Database

Was noch fehlt, aber noch kommen soll:
- Update der Datenbank bei erneuten Durchläufen, momentan klappt es nur beim ersten Mal
- Auswertung der Datenbank, wie auch immer das aussehen soll. Vermutlich:
- Statistikseite für den lokalen Webspace und
- Update des Profils auf GC.com

Wie gesagt, erstmal ein Nachbau von geolog.

Ich entschied mich dazu, das ganze in Ruby zu implementieren. Einfach, weil ich die Sprache am besten kann. Dies bedeutet: Kein Load-And-Play auf Windows, auch hier wird es wieder nötig, den Interpreter und die benötigten Libraries zu installieren.

Der Vorteil ist hierbei allerdings: Ruby ist eine weitaus modernere Sprache als Perl, und die Community bemüht sich, die Interpreter so einfach installierbar auf allen Systemen zu machen, wie möglich.

Es gibt auch diverse Möglichkeiten, ein Rubyscript als eigenständiges Programm zu verpacken, wovon ich aber hierbei Abstand nehmen möchte, weil das nicht wirklich effizient ist.

Es wird also bei allen nennenswerten Betriebssystemen auf folgende Schritte hinauslaufen:
- Den Ruby-Interpreter installieren
- SQLite installieren
- Einen Befehl eingeben, damit die Abhängigkeiten installiert werden

Ich geh mal davon aus, dass eine Cachergemeinde, die u.a. viel Zeit in das Lösen von Mysteries steckt, dieses hier auch schaffen sollte. ;)

Damit das nicht so eine Ungeduld wie beim Warten auf geolog++ erzeugt, möchte ich hier schon auf das rbgeo-Repository auf Github verweisen: https://github.com/simonszu/rbgeo

Zum einen, weil ich hoffe, dass hier eventuell auch der ein oder andere Mitcacher ist, der Ruby programmieren kann, und eventuell mithelfen mag.
Zum anderen, weil alle anderen unter https://github.com/simonszu/rbgeo/commits/master den Fortschritt beobachten können.

Und zum dritten, damit Leute, die sich trauen, es einzusetzen, unter https://github.com/simonszu/rbgeo/issues eine Möglichkeit haben, Bugs und ähnliches zu melden.

Ich hoffe, der ein oder andere wird was damit anfangen können, und ich hoffe, dass das Entwicklerteam von geolog nicht allzu sauer auf mich ist, dass ich deren Idee aufgreife, neu implementiere, und weiterverarbeite ;)
Leave nothing, but footprints; take nothing, but photos; kill nothing but time
Bild
Deine Mudda kloppt Tradis...

Werbung:
Benutzeravatar
moenk
Geoadmin
Beiträge: 13320
Registriert: Fr 8. Aug 2003, 19:20
Ingress: Enlightened
Wohnort: 12161 Berlin
Kontaktdaten:

Re: rbgeo

Beitrag von moenk » Do 27. Feb 2014, 16:24

Ich hab mir grad mal das eigentliche Programm angeguckt: https://github.com/simonszu/rbgeo/blob/master/rbgeo.rb
Das sieht aber sehr kompakt aus, mit den paar Zeilen kann man seine ganzen Einträge bei GC auslesen?
Bild Denkst Du noch selber oder bist Du schon Schwarm?

Benutzeravatar
simonszu
Geocacher
Beiträge: 211
Registriert: Mo 18. Jan 2010, 19:08

Re: rbgeo

Beitrag von simonszu » Do 27. Feb 2014, 16:38

Ja. Ich rufe zunächst die Liste aller Caches ab, und kann dann da schon einige Infos extrahieren. Dann rufe ich die Detailseite und alle Logs ab. Mehr ist das nicht.

Sehr viel aus geologs codebase besteht aus dem Setup-Wizard Anfang, sowie aus den Templates, aus denen nachher die Seiten generiert werden. Hinzu kommt, dass man durch die objektstruktur von Ruby viele Befehle als Einzeiler schreiben kann, für die Perl mehrere Zeilen braucht.
Leave nothing, but footprints; take nothing, but photos; kill nothing but time
Bild
Deine Mudda kloppt Tradis...

Benutzeravatar
moenk
Geoadmin
Beiträge: 13320
Registriert: Fr 8. Aug 2003, 19:20
Ingress: Enlightened
Wohnort: 12161 Berlin
Kontaktdaten:

Re: rbgeo

Beitrag von moenk » Do 27. Feb 2014, 16:40

Für Debian Wheezy reichte dieser Aufruf um alles zu installieren was man dafür braucht:
apt-get install ruby-mechanize ruby-sqlite3 ruby-nokogiri
Grad mal ausprobiert, sehr gelungen! :respekt:
Bild Denkst Du noch selber oder bist Du schon Schwarm?

DresdnerDuo
Geocacher
Beiträge: 103
Registriert: Mi 9. Jan 2013, 20:12

Re: rbgeo

Beitrag von DresdnerDuo » Fr 28. Feb 2014, 07:42

Hallo,

super..... :shocked: ich bin begeistert.

Ich schrieb ja schon in dem anderen Thread, dass ich mich beteiligen würde - aber eben Learning-by-doing, da ich Ruby nicht kann, aber mich gern einarbeite und kleinere, einfache Aufgaben auch übernehmen würde.

Bisschen schade finde ich schon, dass es wieder über diese Interpreter laufen wird - aber das kann man sicherlich verschmerzen.

Ist denn die Anbindung an OC geplant (davon stand jetzt nix im ersten Post).
Bild

Benutzeravatar
simonszu
Geocacher
Beiträge: 211
Registriert: Mo 18. Jan 2010, 19:08

Re: rbgeo

Beitrag von simonszu » Fr 28. Feb 2014, 10:19

Interpretierte Sprachen haben nun mal ihre Vorteile.

Über eine OC-Anbindung habe ich nachgedacht. Wieso eigentlich nicht.
Allerdings habe ich noch keine Ahnung, ob ich die Seite dann auch scrapen muss, oder ob es da eine API gibt, und, und, und.

Erstmal das Teil soweit fertig machen, dass es GC.com scraped, und eine halbwegs ordentliche Statistik anzeigen kann.

Ruby ist keine schwere Sprache. Das wäre bei kompilierten Sprachen anders, weil die alle schon relativ alt sind, oder, wie C# mit .NET oder Objective C nur auf bestimmten Systemen laufen.

Ich habe ein bis zwei Projekte in Go realisiert, und unglaublich viel geflucht, den Code auch für andere Betriebssysteme als dem Quellsystem anzupassen. Interpretierter Code ist einfacher zu portieren, weil nur der Interpreter für die Zielsysteme angepasst werden muss.

Ich werde aber versuchen, wenn das Script annähernd fertig ist, auch eine Installationsanleitung für Windows beizulegen.
Leave nothing, but footprints; take nothing, but photos; kill nothing but time
Bild
Deine Mudda kloppt Tradis...

Benutzeravatar
moenk
Geoadmin
Beiträge: 13320
Registriert: Fr 8. Aug 2003, 19:20
Ingress: Enlightened
Wohnort: 12161 Berlin
Kontaktdaten:

Re: rbgeo

Beitrag von moenk » Fr 28. Feb 2014, 11:15

Also ich würde nun schick finden wenn die ocprop-Funktionalität abgebildet werden könnte. Ich kann nämlich seit einiger Zeit meine OC-Listings nicht mehr automatisch pflegen, und das ist eigentlich das wichtigste Feature von geolog gewesen! Für die Statistik komme ich mit CSG auch ganz gut zurecht.
Bild Denkst Du noch selber oder bist Du schon Schwarm?

Benutzeravatar
simonszu
Geocacher
Beiträge: 211
Registriert: Mo 18. Jan 2010, 19:08

Re: rbgeo

Beitrag von simonszu » Fr 28. Feb 2014, 16:33

Jo. Kommt soweit noch.
Gerade eben habe ich erstmal die Funktion eingebaut, dass die Datenbank geupdatet wird, wenn sich an einem bekannten Cache irgendwas ändern sollte.

Ich stehe momentan mit meiner Logik vor dem Problem, was auftritt, wenn ein Cache 2 Logs hat, aus welchem Grund auch immer. Da der Parser erstmal nur stumpf "in der Zeit zurückreist", und die Datenbank updatet, wenn sich was verändert, würde also immer nur das allererste Log eines Caches gespeichert werden.
Ist vermutlich in 99% der Fälle egal, aber ich sehe mich zB schon gezwungen, die Will Attend Logs von Eventcaches zu ignorieren. Ist in dem Fall vermutlich nicht so wild, weil WA ja eher für den Owner nützlich sind, und die Attended Logs ja erst den Ausschlag geben.
Ich würde auch soweit gehen, Notes zu ignorieren. Entweder sind das Notes für den Reviewer, die in einer Statistik eh nix zu suchen haben, weil sie mit dem Publish obsolet werden, oder sonstige Notes, die im Vergleich zum Found/DNF nicht relevant sind.

Haarig wird es nur, wenn jemand einen Cache als DNF loggt, und ihn danach doch noch findet. In dem Fall würd ich das erste DNF einfach unter den Tisch fallen lassen, weil der Cache ja letztendlich als Found in der Statistik geführt wird.

Gibts da irgendwelche Einwände oder alternativideen? Es würd halt so aussehen, dass ein Foundlog definitiv feststeht, und weitere Logtypes für den Cache ignoriert werden würden, auch wenn sich sonst irgendwas an dem Cache verändert.

Und wenn jetzt ein Cacher wirklich 2 Foundlogs für einen Cache schreibt (wieso auch immer) würde das neuere Log Bestand haben, weil das vom Parser zu erst gefunden wird.
Leave nothing, but footprints; take nothing, but photos; kill nothing but time
Bild
Deine Mudda kloppt Tradis...

DresdnerDuo
Geocacher
Beiträge: 103
Registriert: Mi 9. Jan 2013, 20:12

Re: rbgeo

Beitrag von DresdnerDuo » Fr 28. Feb 2014, 17:25

Da ich mich programmier technisch nicht mit der Umsetzung auskenne kann ich nicht sagen ob/wie es anders umsetzbar wäre.
Aber ich denke, dass die von dir beschriebene Umsetzung (für den Anfang & meine persönlichen Bedürfnisse) ausreicht. Einzig die Auswertung DNF mit anschließendem Found wäre ein schöne Sache...aber es muss ja auch nicht immer alles sofort sein.
Bild

DresdnerDuo
Geocacher
Beiträge: 103
Registriert: Mi 9. Jan 2013, 20:12

Re: rbgeo

Beitrag von DresdnerDuo » Fr 28. Feb 2014, 20:22

Bild

Antworten

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder