-
Willkommen im Geoclub - dem größten deutschsprachigen Geocaching-Forum. Registriere dich kostenlos, um alle Inhalte zu sehen und neue Beiträge zu erstellen.
Neuer Programmierer TweetyHH - Herzlich willkommen!
- Ersteller pfeffer
- Erstellt am
Dann will ich mich noch schnell selbst vorstellen:
Ich bin Informatikstudent und daher sicher nicht unerfahren was Programmierung in Java angeht. Ich komme aus Hamburg und Cache hier begeistert mit Rad und ÖPNV.
Mein Ziel wird es vorallem sein den Cachewolf als Tool für das spontan Cachen mit einem Magellan und HTML Ausgaben auf meinem Handy zu optimieren. Häufig ist man mit dem Rad irgendwo in der Stadt und kann sicher noch ne Stunde vor Ort verbringen. Da in Hamburg nahezu Überall Massen von Filmdosen liegen (man, muss es hier viele Fotografen geben) komm ich in dem Umkreis wo ich mich potentiell aufhalte (ÖPNV Endhaltestellen) leicht auf über 1000 Caches.
Dafür ist es notwendig alle Infos auch auf einem wirklich kleinen Display mit noch weniger Rechenleistung zur Verfügung zu haben.
Da ich keinen PDA hab und das Handy nicht EWE fähig ist benutz ich den CacheWolf also nur Zuhause/auf meinem Laptop zur preventiven Vorbereitung!
Das heißt sowas wie Karten/GPS Anbindung wird mich erstmal nicht interessieren.
Dafür die Themen exportieren, gpx importieren oder spidern um so mehr.
Also auf ein fröhliches Zusammensein:
Grüße Florian
P.S. Es gibt immer was zu tun!
Ich bin Informatikstudent und daher sicher nicht unerfahren was Programmierung in Java angeht. Ich komme aus Hamburg und Cache hier begeistert mit Rad und ÖPNV.
Mein Ziel wird es vorallem sein den Cachewolf als Tool für das spontan Cachen mit einem Magellan und HTML Ausgaben auf meinem Handy zu optimieren. Häufig ist man mit dem Rad irgendwo in der Stadt und kann sicher noch ne Stunde vor Ort verbringen. Da in Hamburg nahezu Überall Massen von Filmdosen liegen (man, muss es hier viele Fotografen geben) komm ich in dem Umkreis wo ich mich potentiell aufhalte (ÖPNV Endhaltestellen) leicht auf über 1000 Caches.
Dafür ist es notwendig alle Infos auch auf einem wirklich kleinen Display mit noch weniger Rechenleistung zur Verfügung zu haben.
Da ich keinen PDA hab und das Handy nicht EWE fähig ist benutz ich den CacheWolf also nur Zuhause/auf meinem Laptop zur preventiven Vorbereitung!
Das heißt sowas wie Karten/GPS Anbindung wird mich erstmal nicht interessieren.
Dafür die Themen exportieren, gpx importieren oder spidern um so mehr.
Also auf ein fröhliches Zusammensein:
Grüße Florian
P.S. Es gibt immer was zu tun!
TantchensOnkelchen
Geowizard
TweetyHH schrieb:
Goil !
Der GPX-Export brennt unter den Fingernägeln.
Wenn Du den deutlich beschleunigen kannst, gebe ich Dir bei nächster Gelegenheit ein Bier - oder was anderes - aus !
Im Vorfeld schon mal vielen Dank für Deine Mühe.
Viele Grüße
Onkelchen
Na, wieviel Prozent sind denn deutlich? Beim Exporter selber seh ich durchaus die Möglichkeit noch ein wenig was rauszuholen (dafür wird leider der Quelltext ein wenig unübersichtlicher).
Kann mir vielleicht ein anderer Entwickler nen Tipp geben, ob es eher am GPX Exporter oder am Zugriff auf die Cacheelemente liegt?
P.S. Ich komme auf meinem Laptop beim exportieren von 500 Caches auf 1.7 sekunden? DARF ich bitte fragen was du da so treibst?
P.P.S. Bier wär ok ;-)
Wieviele Caches sind das zum Henker?
Schon mal die eine aktuelle Nightlybuild probiert? macht bei mir deutlichliche unterschiede aus. Scheint also schon mal überarbeitet worden zu sein. Ein wenig lässt sich da auch noch rausholen, aber ob das lohnt ist die Frage.
Hab werder das eine noch das andere ... Es handelt sich bei der GPX datei um eine die Groundspeak konform geocaches enthält, können die beiden dass? Ansonsten ist GPX ja ein XML-Sammelformat. Ich seh hier einen Export zu PCX5 Mapsource, hilft der nicht?
snaky
Geowizard
Na, dann poste ich doch auch mal meine Wunschliste:
Erstmal die "Kleinigkeit" (vermute ich mal): Beim Exportieren nach Google Earth passt der Prozentsatz nicht. Der zählt munter über die 100% hinaus teilweise bis 160%.
Ansonsten würde ich mir einen einfachen Export zu GPX getrennt nach Cacheart wünschen. Ich habe auf meinem 60CSx Icons für Multi, Virtual, Tradi usw. Gestern habe ich einige Stunden damit verbracht, meine Caches nach Cacheart zu filtern, zu exportieren, usw.
Ich glaube beim Tomtom-Export werden da doch auch Unterschiede gemacht. Dort habe ich verschiedene Icons...
Erstmal die "Kleinigkeit" (vermute ich mal): Beim Exportieren nach Google Earth passt der Prozentsatz nicht. Der zählt munter über die 100% hinaus teilweise bis 160%.
Ansonsten würde ich mir einen einfachen Export zu GPX getrennt nach Cacheart wünschen. Ich habe auf meinem 60CSx Icons für Multi, Virtual, Tradi usw. Gestern habe ich einige Stunden damit verbracht, meine Caches nach Cacheart zu filtern, zu exportieren, usw.
Ich glaube beim Tomtom-Export werden da doch auch Unterschiede gemacht. Dort habe ich verschiedene Icons...
Achja: Eine Bitte: Wenn ihr einen "Fehler" findet oder einen wunsch im vergleich zu etwas habt, schreibt bitte dazu welche Version ihr benutzt. Also 0.9n oder was aktuelleres.
(Hab nur nen Exorzisten, da hab ch mit diesen komischen Geräten nicht so die Erfahrung)
Ich hab da einen verdacht wenn du die Entwicklerversion benutzt.
Beim KML Export werden auch Unterschiede gemacht. hier könnte man wahrscheinlich einen ähnlichen Ansatz wählen. Du hättest also gerne ein gpx je cacheart ?
(Hab nur nen Exorzisten, da hab ch mit diesen komischen Geräten nicht so die Erfahrung)
snaky
Geowizard
TweetyHH schrieb:
Sorry, hätte ich natürlich dazusagen sollen. Aktuell benutze ich die BE 1120 unter Linux. (Und BE1115 auf dem PPC, aber da exportiere ich nicht)
Ja, genau. Also quasi Tradi.gpx, Multi.gpx, Mystery.gpx - und wenn's geht auch Parking.gpx, Stage.gpx, Question.gpx...
Letzteres bekomme ich aber nicht mal über die Filterfunktion so hin, dass Mapsource sie freiwillig importiert. Ist mir allerdings jetzt auch nicht so wichtig.
Also ich hab da mal ein klein wenig gebastelt. Da ich nur noch Messungen gegen ein System mit meinem Rot13 Patch machen konnte (der dürfte bei langen Hints auch schon ein wenig bringen). Gegenüber der vorherigen developerversion komm ich so also auf Zeiten von 10 bis 20 % weniger (mehrfach handgestoppt). Der code war schon ziemlich optimiert im Gegensatz zu 0.9n muss ich sagen.
[DEVELOPER only]
Wer das hier liest muss wirklich an der Programmierung mit Java interessiert sein - das ich das hier so "lehrbuchartig" aufschreibe liegt einfach daran dass ich lange im Bereich der Softwaretechnik in der Lehre als SHK engagiert war.
An viele Stellen ist ja schon von langen String Verkettungen zurückgerudert worden. Das sowas wie
Code:
String s = ""
s = s + "irgendwas" + var1.toString();
s = s + "blablue" + " var2;
s = s + var.toString() + "ein text";
Code:
StringBuffer sb = new StringBuffer()
sb.append("irgendwas" + var1.toString());
sb.append("blablue" + " var2);
sb.append(var3.toString() + "ein text");
String s = sb.toString();z.B. wird in der ersten append-Zeile erst der String "irgendwas" mit var.toString() = "42" zu einem neuen Stringobjekt "irgendwas42" zusammengesetzt, der erst dann dem StringBuffer übergeben wird.
Da StringBuffer.append(String) eine Referenz auf sich selbst zurückgibt ist es also möglich append()-Anweisungen aneinander zu hängen. Ein noch besserer Code wäre also:
Code:
StringBuffer sb = new StringBuffer()
sb.append("irgendwas").append(var1.toString());
sb.append("blablue").append(" var2);
sb.append(var3.toString()).append("ein text");
String s = sb.toString();Mir ist klar, dass eine solche Optimierung an vielen Stellen wirklich überflüssig ist. Aber wenn zum Beispiel in einem Exporter eine Methode 1000 mal aufgerufen wird wird es natürlich interessant.
Wenn man gegen eine modernen Javaversion programmiert ist es noch interessanter den StringBuilder zu benutzen. Der ist noch ein wenig schneller als der StringBuffer, dafür aber nicht mehr Threadsicher.
P.S. Ogott, worüber schreib ich hier Abhandlungen, ich sollte ins Bett ;-)
P.P.S. Wäre nett, wenn das noch mal jemand anderes Testen könnte was ich eingestellt habe, vorallem wegen des Encodings - bin mir nicht sicher ob das alles hier korrekt eingestellt ist.
OP
pfeffer
Geowizard
danke für diese Hinweise - habe davon keine Ahnung (gehabt).
Funktioniert das bei encoding mit Grad-Zeichen usw. bei Dir immernoch nicht korrekt?
habe das mit [ ] gerade mal bei mir getestet: es funktioniert. Allerdings musste ich eine Weile suchen, bis ich einen Cache hatte, bei dem [xxx] vorkam. Und bei diesem Cache ist das, was in [] steht auch ROT13 -> das entschlüsselt CacheWolfs jetzt nicht mehr :-(
... habe jetz noch ein paar mehr durchgeguckt: Hier in der Gegend ist der Text in [] auch immer verschlüsselt. Steht das irgendwo, dass man den Text darin nicht verschlüsseln soll? - Ich wäre dafür, die ROT13-Codierung wieder auch auf diesen Bereich anzuwenden. Denn dann kann man beides haben. So wie Du es jetzt gemacht hast, bekommt man den Text in [] leider überhaupt nicht entschlüsselt.
Gruß,
Pfeffer.
Funktioniert das bei encoding mit Grad-Zeichen usw. bei Dir immernoch nicht korrekt?
habe das mit [ ] gerade mal bei mir getestet: es funktioniert. Allerdings musste ich eine Weile suchen, bis ich einen Cache hatte, bei dem [xxx] vorkam. Und bei diesem Cache ist das, was in [] steht auch ROT13 -> das entschlüsselt CacheWolfs jetzt nicht mehr :-(
... habe jetz noch ein paar mehr durchgeguckt: Hier in der Gegend ist der Text in [] auch immer verschlüsselt. Steht das irgendwo, dass man den Text darin nicht verschlüsseln soll? - Ich wäre dafür, die ROT13-Codierung wieder auch auf diesen Bereich anzuwenden. Denn dann kann man beides haben. So wie Du es jetzt gemacht hast, bekommt man den Text in [] leider überhaupt nicht entschlüsselt.
Gruß,
Pfeffer.
UUS
Geocacher
Hallo TweetyHH,
erstmal herzlichen Dank, dass du auch mithilfst uns nicht-Programmierer mit so einer tollen Software zu beglücken. Da du dich ja mit den Export-Möglichleiten des Cachewolf beschäftigst, möchte ich noch einmal eine meiner früheren Anregungen zum HTML-Export ins Gespräch bringen.
Ich fände es sehr interessant, wenn die Möglichkeit bestünde, verschiedene HTML-Templates für die Untersortierungen zu verwenden.
Wenn ich z.B. den Index nach Waypoint oder Name angezeigt bekommen möchte, interessiert mich auf der Waypoint-Seite eigentlich nur Waypoint und Cache-Name nach den entprechenden Sortierung. Die anderen Daten (Koordinaten, Size, ...) möchte ich nicht angezeigt bekommen.
Gibt es eine Möglichkeit, das zu realisieren. Irgendwie gelingt mir das nicht. Der Aufbau sieht ja leider bei jeder Seite aus, wie im index.tpl vorgegeben.
Auf meinem Palm Tungsten T5 ist das mit den "gepluckerten" Tabellen aber überhaupt nicht zu gebrauchen. Also habe ich die index.tpl so umgebaut, dass die Informationen einigermassen lesbar sind, also ohne Tabellen. Aber es wäre natürlich schöner, wenn es verschiedene Index-Seiten geben könnte. Das würde vielleicht auch die Lesbarkeit beim HTML-Export für Handys verbessern.
Praktisch wäre es dabei, wenn im Cachewolf-Programmverzeichnis für die verschiedenen Unterseiten separate Templates (z.B. index_alpha.tpl, index_dist.tpl, index_size.tpl, index_type.tpl, index_wp.tpl) angelegt werden könnten, die dann benutzt werden würden, wenn sie vorhanden sind. Fehlen diese Templates, könnte dann alternativ auf das Standard-Template (index.tpl) zurückgegriffen werden.
Übrigens scheinen beim Export die Variablen SHORTTYPE und SHORTSIZE nicht zu funktionieren.
Wenn diese Ideen auch für andere interessant und auch relisierbar sind, würde ich mich über eine Implementation freuen.
Gruß
Uwe.
erstmal herzlichen Dank, dass du auch mithilfst uns nicht-Programmierer mit so einer tollen Software zu beglücken. Da du dich ja mit den Export-Möglichleiten des Cachewolf beschäftigst, möchte ich noch einmal eine meiner früheren Anregungen zum HTML-Export ins Gespräch bringen.
Ich fände es sehr interessant, wenn die Möglichkeit bestünde, verschiedene HTML-Templates für die Untersortierungen zu verwenden.
Wenn ich z.B. den Index nach Waypoint oder Name angezeigt bekommen möchte, interessiert mich auf der Waypoint-Seite eigentlich nur Waypoint und Cache-Name nach den entprechenden Sortierung. Die anderen Daten (Koordinaten, Size, ...) möchte ich nicht angezeigt bekommen.
Gibt es eine Möglichkeit, das zu realisieren. Irgendwie gelingt mir das nicht. Der Aufbau sieht ja leider bei jeder Seite aus, wie im index.tpl vorgegeben.
Auf meinem Palm Tungsten T5 ist das mit den "gepluckerten" Tabellen aber überhaupt nicht zu gebrauchen. Also habe ich die index.tpl so umgebaut, dass die Informationen einigermassen lesbar sind, also ohne Tabellen. Aber es wäre natürlich schöner, wenn es verschiedene Index-Seiten geben könnte. Das würde vielleicht auch die Lesbarkeit beim HTML-Export für Handys verbessern.
Praktisch wäre es dabei, wenn im Cachewolf-Programmverzeichnis für die verschiedenen Unterseiten separate Templates (z.B. index_alpha.tpl, index_dist.tpl, index_size.tpl, index_type.tpl, index_wp.tpl) angelegt werden könnten, die dann benutzt werden würden, wenn sie vorhanden sind. Fehlen diese Templates, könnte dann alternativ auf das Standard-Template (index.tpl) zurückgegriffen werden.
Übrigens scheinen beim Export die Variablen SHORTTYPE und SHORTSIZE nicht zu funktionieren.
Wenn diese Ideen auch für andere interessant und auch relisierbar sind, würde ich mich über eine Implementation freuen.
Gruß
Uwe.
Auf meiner Linuxkiste nicht. Brennt mir aber auch nicht unter den nägeln. , solange nur die Commits von mir für die anderen keinen Unsinn verzapfen. Für die tatsächliche Anwendung werde ich es sowieso auf meiner Windowskiste laufen lassen (da laufen einfach die Mails mit den GPX-Dateien auf).
Wenn ich das Richtig sehe haben wir hier ein Importer Problem. Irgendwer hat sich da schon mal Gedanken drum gemacht und wenn ein Cache per GPX importiert wird, wird der Text in [] einfach beim Importieren zusätzlich mit Rot13 kodiert.
Dadurch ist dann der ganze String mit Rot13 kodiert.
Beim Spidern von GC scheint der Effekt nicht aufzutreten, weil dieser wahrscheinlich weniger "Klug" ist.
Kannst du daher nochmal in die Orginalbeschreibungen gucken wie die Leute es online eingetragen haben?
Achja, es steht zumindest bei GC.com im Cachelegeformular über dem Hint Feld, dass Text in [] nicht codiert wird. Also ist schon eine "offizielle" Funktion. Um es falsch zu machen muss man sich wahrscheinlich schon anstrengen und den Text selber in rot13 eingeben ;-)
Schon wieder:
Zum Thema Rot13: Ich ruder zurück und behaupte das Gegenteil. Nach kurzem studium des Quellcodes seh ich, dass das Problem ist, dass Groundspeak die Hints (korrekt) unverschlüsselt überträgt. In der Datenbank des Cachewolfs werden sie aber verschlüsselt gespeichert. Daher hattest du in deiner lokalen Datenbank falsch verschlüsselte Daten. Wenn du deine Datenbank neu befüllen würdest, würde alles richtig funktionieren.
Ist also ein Bug aufgrund der Änderung des intertnen Verhaltens.
Daher wäre ich dafür, dass dieses Verhalten beim 1.0 Release drin zu haben als später bei einem minor-Release.
Da ich z.B. auf Ausdrucken bewusst darauf verzichte decodierte Hints mitzunehmen wäre mir ein korrektes Verhalten schon wichtig, da ich ungern erst 3 Seiten decodiere bis der Hint zur richtigen Station finde
@Uwe/UUS
Demnächst werde ich mal eine erweitere HTML-Exportfunktion fertig machen. Die wird dann sowas wie die vorschlägst enthalten. Dafür wird man wahrscheinlich mal die Template-Dateien anpassen müssen wenn man es genauso haben will wie man es selbst möchte. Dafür aber ein bisschen Mächtiger das ganze.
Grüße Florian
Zum Thema Rot13: Ich ruder zurück und behaupte das Gegenteil. Nach kurzem studium des Quellcodes seh ich, dass das Problem ist, dass Groundspeak die Hints (korrekt) unverschlüsselt überträgt. In der Datenbank des Cachewolfs werden sie aber verschlüsselt gespeichert. Daher hattest du in deiner lokalen Datenbank falsch verschlüsselte Daten. Wenn du deine Datenbank neu befüllen würdest, würde alles richtig funktionieren.
Ist also ein Bug aufgrund der Änderung des intertnen Verhaltens.
Daher wäre ich dafür, dass dieses Verhalten beim 1.0 Release drin zu haben als später bei einem minor-Release.
Da ich z.B. auf Ausdrucken bewusst darauf verzichte decodierte Hints mitzunehmen wäre mir ein korrektes Verhalten schon wichtig, da ich ungern erst 3 Seiten decodiere bis der Hint zur richtigen Station finde
@Uwe/UUS
Demnächst werde ich mal eine erweitere HTML-Exportfunktion fertig machen. Die wird dann sowas wie die vorschlägst enthalten. Dafür wird man wahrscheinlich mal die Template-Dateien anpassen müssen wenn man es genauso haben will wie man es selbst möchte. Dafür aber ein bisschen Mächtiger das ganze.
Grüße Florian
TantchensOnkelchen
Geowizard
TweetyHH schrieb:
Hmmm...
Als ich es das letzte Mal verwendet habe, hat der GPX-Export von 200 Caches über 2 Stunden gebraucht.
Für den gleichen Bestand auf dem gleichen Rechner brauchte TTQV zum Einlesen und zum Rausschreiben nur wenige Sekunden.
War allerdings die BE925. Seither soll aber nichts aktiv daran beschleunigt worden sein.
Wenn es allerdings jetzt schon auf ein paar Sekunden reduziert ist, dann ist's bereits okay.
Die 2 Stunden waren für mich halt unbrauchbar, deshalb habe ich Cachewolf seither nicht mehr genutzt.
Ich probiere dann mal die aktuelle BE und melde mich wieder ...
Viele Grüße
Onkelchen
P.S.: Alleine der Tipp, dass es evtl. schon geht, ist das Bier schon wert
