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

CSG (CacheStatGenerator)

OP
Nachtfalke

Nachtfalke

Geowizard
Bastelecke schrieb:
- Es gibt wohl ein Problem mit Umlauten, die werden nicht korrekt eingelesen, oder in der DB falsch angezeigt. In der Ausgabe führt es bei mir dazu, dass für Thüringen und Baden-Württemberg keine Flagge angezeigt wird und diese auch nicht auf der Karte markiert werden. Dänemark wird dagegen korrekt angezeigt.

Ich kann das Problem leider nicht reproduzieren. Wenn ich auf meinem Rechner Deine GPX einlese, wird alles korrekt dargestellt. Kann das irgendwie mit den Codepages zusammenhängen? Welches Betriebssystem benutzt Du?
 
OP
Nachtfalke

Nachtfalke

Geowizard
Die Version 0.40beta ist online.

Bugfixes:
  • Die Höhen von Caches deren Koordinaten im Meer liegen werden auf 0 gesetzt
  • Größenbeschränkung beim GPX-Import eliminiert

Sonstige Änderungen:
  • Erstellung der Kalendertagematrix und der D/T-Matrix ca. 90% beschleunigt
  • Anzahl der pro Aufruf einzulesenden TBs kann limitiert werden.
  • TB-Daten fremder TBs und TB-Logs werden inkrementell eingelesen, Daten eigener TBs nur bei Bedarf
  • Einbeziehung der eigenen Traveller in die allgemeinen Travellerstatistiken abschaltbar

Die interessanteste Neuerung dürfte wohl sein, daß man die Anzahl der Traveller, die pro Aufruf der Funktion eingelesen werden, in den Optionen limitieren kann. Man kann also die Daten portionsweise einlesen. Zunächst werden die TB-Daten eingelesen. Wenn alle Traveller eingelesen sind, werden die Logs portionsweise eingelesen.

Bereits eingelesene Travellerdaten werden kein zweites Mal eingelesen. Lediglich die Daten der eigenen Traveller werden öfter eingelesen, um die Kilometerstände aktuell zu halten. Wie oft die eigenen Traveller gelesen werden (alle X Tage) kann man ebenfalls in den Optionen konfigurieren.

Eigene Travellerdaten werden ebenfalls nicht eingelesen, falls sowohl die eigene Travellerübersicht als auch die Einbeziehung der eigenen Traveller in der allgemeinen Travellerstatistik über die Optionen der Statistik abgeschaltet sind.
 

baer

Geowizard
Nachtfalke schrieb:
Die Version 0.40beta ist online.
Sehr schön! Mein reproduzierbarer Komplett-Hänger bei der Statistik-Erzeugung bei der Version 0.32 ist nämlich auch weg! Und damit sehe ich nun auch, dass die Verarbeitung mehrfach gefundener Caches und damit meine Milestones korrekt sind.

Abgesehen von dem noch nicht gelösten Problem der Behandlung von Funden ohne Bundesland-Zuordnung ist damit CSG für mich schon praktisch perfekt! Danke!
 

Emili Erdbeer

Geocacher
Einlesen der TBs hat diesmal nicht zum Absurz geführt. Insgesamt fiel mir ein ositiver Performance-Unterschied auf.
Bei der Auswertung und Darstellung als HTML werden jedoch nicht meine eigenen Caches angezeigt und auch nicht die TBs ausgewertet.
 

Anhänge

  • csg.JPG
    csg.JPG
    31,6 KB · Aufrufe: 268

baer

Geowizard
Jetzt habe ich glaube ich doch noch einen Fehler gefunden.

Ich habe jetzt eine Statistik mit Höhenprofil erzeugt. An der Stelle, wo dieses stehen sollte, erscheint aber nur ein "broken link". Beim Blick in die HTML-Source fällt auf, dass hier anscheinend alle Höhen als Parameter einer URL übergeben werden. Mutmasslich ist mit meiner Anzahl Funde die URL zu lang...
 
OP
Nachtfalke

Nachtfalke

Geowizard
So ist es. Aber einer bestimmten Anzahl an Caches funktioniert das Höhenprofil nicht mehr und sollte abgeschaltet werden. Ich habe dafür auch noch keine Lösungsidee zumal es von mehreren Faktoren abhängt, wie lang eine URL sein darf. Per Definition ist die Länge nicht beschränkt, aber in der Realität beschränken sowohl Server als auch Clients die Länge einer URL. Es ist aber nirgendwo festgelegt, auf wieviel Zeichen die URL beschränkt werden sollte. Vielleicht hat ja irgendjemand einen Lösungsansatz? Ich hatte schon überlegt, das Höhenprofil auf Jahre aufzuteilen. Funktioniert aber im ungünstigsten Fall auch nicht, da bei entsprechenden Find-Zahlen auch die Anzahl der Caches pro Jahr zu groß sein könnte.
 
OP
Nachtfalke

Nachtfalke

Geowizard
Das macht mich jetzt fertig. Ich habe Deine GPX auch eben nochmal eingelesen. Bei mir (Win7) ist die Anzeige sowohl in der Tabelle als auch in der Statistik einwandfrei. Hat zufällig irgendjemand eine Idee, woran das liegen könnte? btw: Welche Java-Version benutzt Du?
 
OP
Nachtfalke

Nachtfalke

Geowizard
Um nochmal auf das Höhenprofil zurückzukommen: Ich habe jetzt mal ein bisschen mit gezippten Strings experimentiert und festgestellt, daß ich in einer URL Höhendaten für ca. 800 Caches unterbringen kann. Glaubt ihr, daß das reicht, wenn ich für jedes Jahr eine eigenes Höhenprofil erstelle? Oder gibt es viele Cacher, die mehr als 800 Funde pro Jahr haben?

Edit:
Andere Idee: Wenn ich die Höhen der Caches durch 10 teile, kann ich locker Höhen für mehrere tausend Caches transportieren. Darunter würde natürlich die Genauigkeit leiden, da das Höhenprofil statt auf den Meter nur noch auf 10 Meter genau wäre. Was haltet ihr von dieser Idee?
 

Emili Erdbeer

Geocacher
Immer das, was für dich machbar ist.
Ich glaube auch, dass es Cacher gibt, die im Jahr auf 800+ Caches kommen. Wenige, aber wohl einige.
 

Bastelecke

Geocacher
Nachtfalke schrieb:
btw: Welche Java-Version benutzt Du?
Wie finde ich das heraus?

Nachtfalke schrieb:
Oder gibt es viele Cacher, die mehr als 800 Funde pro Jahr haben?
Es gibt schon ein paar, ich gehöre dazu.

Nachtfalke schrieb:
Darunter würde natürlich die Genauigkeit leiden, da das Höhenprofil statt auf den Meter nur noch auf 10 Meter genau wäre. Was haltet ihr von dieser Idee?
Wenn es nur so geht, dann ist es natürlich absolut in Ordnung.
Allerdings ist bei mir der niedrigste Cache knapp unter der NN-Grenze, bei 10 Meter Genauigkeit würde es wahrscheinlich ziemlich viele geben, die alle als niedrigster Cache in Frage kommen.

Wie bekomme ich eigentlich die -9999 m Werte bei mir aus der DB raus?
 
OP
Nachtfalke

Nachtfalke

Geowizard
Die Javaversion findest Du heraus, indem Du auf Kommandozeilenebene (in einer DOS-Box)

java -version

eingibst.

Die Genauigkeit würde nur bei der Anzeige des Höhenprofils leiden. Alle anderen Höhenberechnung würden weiterhin mit den genauen Werte erfolgen.

Um das -9999 Problem zu beheben, wäre es am einfachsten, wenn Du das Verzeichnis csgdb zippst und mir zuschickst. Ich repariere Dir die DB und schicke sie Dir umgehend zurück.
 

t31

Geowizard
Nachtfalke schrieb:
Um nochmal auf das Höhenprofil zurückzukommen:

ganz andere Idee: erster Gedanke hexadezimal, aber man kann ja auch gleich die Basis 36 nehmen und diese läsß sich mit Zahlen und Buchstaben darstellen 0...9...Z sprich so wie es GC mit den GC-Codes macht. Bis 1295m währe ZZ (36*36-1), erst ab 1295 wird es dreistellig ZZ0
 
OP
Nachtfalke

Nachtfalke

Geowizard
t31 schrieb:
ganz andere Idee: erster Gedanke hexadezimal, aber man kann ja auch gleich die Basis 36 nehmen und diese läsß sich mit Zahlen und Buchstaben darstellen 0...9...Z sprich so wie es GC mit den GC-Codes macht. Bis 1295m währe ZZ (36*36-1), erst ab 1295 wird es dreistellig ZZ0
Die Idee hatte ich auch schon. Das Problem ist, daß dann aufgrund des erhöhten Zeichenbedarfs die ZIP-Komprimierung nicht mehr so effektiv ist. Funktioniert somit leider auch nicht.
 
OP
Nachtfalke

Nachtfalke

Geowizard
CSG benötigt mindestens Java 1.6.

Unter Win7 gibt es in der Systemsteuerung den Punkt Java. Dort kannst Du unter dem Reiter Java die installierten Versionen sehen.
 

baer

Geowizard
Ich glaube, ich habe noch einen einfach zu behebenden Fehler in CSG gefunden.

Ich habe ja 3 Caches zweimal gefunden, also Moment 4840 Funde an 4837 Caches.

Bei den Milestones soll ja zusätzlich zu den eigentlichen Milestones der jüngste Fund angezeigt werden.

Bei mir wird aber der 4837te Fund angezeigt und nicht der 4840te... (siehe meine mit CSG erzeugte Statistik in meinen Profil) Da wird wohl einfach die falsche Variable verwendet.
 
Oben