• Willkommen im Geoclub - dem größten deutschsprachigen Geocaching-Forum. Registriere dich kostenlos, um alle Inhalte zu sehen und neue Beiträge zu erstellen.

rbgeo

simonszu

Geocacher
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 ;)
 

moenk

Administrator
Teammitglied
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?
 
OP
simonszu

simonszu

Geocacher
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.
 

DresdnerDuo

Geocacher
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).
 
OP
simonszu

simonszu

Geocacher
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.
 

moenk

Administrator
Teammitglied
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.
 
OP
simonszu

simonszu

Geocacher
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.
 

DresdnerDuo

Geocacher
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.
 

moenk

Administrator
Teammitglied
Kannst mal davon ausgehen dass hier die OKAPI jeder kennt - aber was willst Du uns damit sagen?
 

DresdnerDuo

Geocacher
Kannst mal davon ausgehen dass hier die OKAPI jeder kennt

Denkste? :p Ich habe es deswegen erwähnt:

Ü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.

Vielleicht habe ich da ja auch was falsch verstanden - soll vorkommen... :???: :D
 
OP
simonszu

simonszu

Geocacher
richtig, die OKAPI kannte ich noch nicht. Ich nutzte OC nie so wirklich, weil die Caches da irgendwie alle immer kaputt oder sonstwie schlecht maintained waren, und hab das lediglich mit ocprop gespiegelt.
 

moenk

Administrator
Teammitglied
Das Problem bei OC ist schon immer dass die meisten Dosen eben nicht dort zu finden sind. Von Gummipunkten mal ganz abgesehen! Es wäre aber schön wenn man OC zumindest mit den Daten füttern kann, die bei GC schon drin sind - dort sind sie nämlich im Gegensatz zu GC frei zugänglich.
 
OP
simonszu

simonszu

Geocacher
Zu der letzte Woche angesprochenen Problematik der "doppelten Logs" für einige Caches: Ich parse die Liste aller Logs nun einfach in chronologischer Ordnung, und das jeweils letzte Log für einen Cache bleibt bestehen. Ich kann verstehen, dass ihr teilweise gerne mehrere Logs für einen Cache haben und speichern wollt, aber das würde die Datenbankstruktur (erstmal) nur unnötig aufblähen.
Die OC-API scheint echt nicht so kompliziert zum Zugriff zu sein. Das kriege ich also früher oder später auch hin.

Ich werd allerdings parallel so grob gucken mit ner Statistikseite, weil ich auch in dem Fall gucken kann, wie ich GC-Caches zwischen Owned und nicht-owned untersuchen kann.

Ich werde dafür aber erstmal den letzten Schliff an den Scraper mit der DB-Anbindung legen, weil es nervig ist, wenn man sich dem nächsten Aspekt zuwendet, und erst später merkt, dass andere Teile doch nicht ganz gut laufen, und man sich da wieder einarbeiten muss. Auch hoffe ich immer noch auf Mitcacher, die mitmachen wollen (also auch an der Umsetzung, nicht am Brainstormen, was noch machbar wäre ;) )
 
OP
simonszu

simonszu

Geocacher
So. Das Script kann nun die Datenbank rudimentär auswerten. Momentan noch nicht viel mehr als eine Indexseite mit allen Caches, und Detailseiten pro Cache, die nicht viel mehr als das Log anzeigen, aber es ist eine Grundlage, auf der aufgebaut werden kann.
 

DresdnerDuo

Geocacher
Auch hoffe ich immer noch auf Mitcacher, die mitmachen wollen

Am wollen tut es nicht liegen tun...leider kann ich nicht programmieren, aber ich finde die Idee hervorragend, vor allem wenn dann irgendwann die Anbindung an OC möglich sein sollte. Danke, dass du dir die Arbeit machst.
Solltest du in irgendeiner Weise (außer programmieren) Hilfe brauchen, kannst du mich gerne anschreiben und wir schauen dann mal was so geht.. :handy:

VG
 

Inder

Geowizard
Da der letzte Kommentar vor eineinhalb Jahren war, muss man davon ausgehen, dass das Programm leider auch eine Luftnummer war.
 
OP
simonszu

simonszu

Geocacher
Das Programm war alles andere als eine Luftnummer. Auf https://github.com/simonszu/rbgeo (genauer: Auf https://github.com/simonszu/rbgeo/commits/master) könnt ihr den aktuellen Fortschritt sehen. Ich gebe allerdings zu, dass sich da für eine lange Zeit nichts getan hat, und ich auch wieder seit 2 Monaten da eher inaktiv bin, weil Arbeit und Uni gerade genug Zeit fressen. ;)
Auch ist die Motivation nicht gerade hoch, wenn ich kein Feedback bekomme, daher baue ich das gerade erstmal primär für mich, also ohne Roadmap oder Deadlines, sondern immer mal wieder zwischendurch etwas. In letzter Zeit habe ich mich erstmal um die Statistiken gekümmert, die generiert werden sollten. Wenn das fertig ist, gucke ich mir mal die Details eines jeden Caches an. Also um in etwa die Feature-Completeness zu erreichen, die ich von geolog bis jetzt benutzt habe. Wenn das soweit fertig ist, und das Tool "narrensicher" zu installieren ist, dann gucke ich mal weiter Richtung Opencaching.
Bis dahin seid ihr aber gerne schonmal eingeladen, euch den aktuellen Work in Progress anzusehen, das Teil mal mit euren Caches durchlaufen zu lassen, und euch bei mir zu melden, wenn irgendwas nicht klappt, oder ihr Hilfe braucht.
Falls ihr aber momentan primär ein Tool braucht, um OC und GC zu syncen, dann solltet ihr fürs Erste einfach noch weiterhin geolog benutzen.
 
Oben