Beiträge von hedgehog

Zitat von kiozen

hedgehog Der Url scheint mit dabei zu sein. Ich habe den entpackten Block angehängt. Mit einem Hexeditor einfach nach "Pois" suchen. Der Url ist nicht mehr Teil der XML Cachebeschreibung sondern scheint ein eigenes Feld zu sein, dem Steuerdaten vorangehen. Jetzt wäre es interessant ob dieser URL auch relativ sein darf.

Na wunderbar, das sieht ja erst einmal gut aus.
Das letzte Mal als ich mit den Geocaching-Tags in wpts gespielt hatte war es so, daß ein Waypoint als Geocache erkannt wurde (nötig für die Fieldnotes, die aber in einer anderen Datei landen und die Aktivierung des Geocaching Menüs), wenn (hoffentlich schreib ich jetzt keinen Quatsch) <groundspeak:cache id="775490" ... vorhanden war. Die ID selber war egal, Hauptsache der Tag war vorhanden. Wenn also jetzt der ganze nutzlose Plunder wie Logs, Long description, Short description, TB'S etc. ausgelagert würde in eine Textdatei ohne HTML Tags aber mit Bildchen, sollte das Format doch noch einen Nutzen haben.

Sardinien:

Zitat

die via CGPSL in die bwpt geschriebenen PDF+html können nicht geöffnet werden.

Vorteil von JPEG/PNG/bmp + TXT VollIntegrierungen in BWPT:

eine 28 MB bwpt wird in ca. 40 % der Zeit geöffnet als eine WPT mit den gleichen Datenzugriffen jedoch extern in einem Ordner verlinkt
13.07.2012 12:28

Ich denke das hängt stark von deinen Systemressourcen ab. Unter Android sicher kein Problem. Ich hatte einmal eine Geocaching GPX (nur 2500 Caches) in BWPT ohne Verknüpfungen umgewandelt, das Ergebnis war so 30MB groß und brauchte mind. 5min um zu laden und machte das System auch sonst sehr sehr träge. Seitdem scheue ich das neue Format. Im alten BWPT Format habe ich auch schon 5000+3000 Waypoints offen gehabt und die Kiste lief noch. Und der Loox stellt wirklich nur ca. 40MB Ram für Twonav zur Verfügung.
Man müßte noch einmal schauen, ob TwoNav nicht die Bildtags auch in TXT Dateien anzeigt. Ich traue das den Spaniern zu.

Papaluna:
Danke fürs Bugreporten!

Zitat

Ich hab mal schnell meine gpx in eine aktuelle bwpt umgewandelt. Versuch doch mal bitte, diese zu extrahieren und schau nach, ob dort noch die Hyperlinks[url][\url] vorhanden sind. Wenn ja, lohnt es sich aus meiner Sicht, das neue BWPT-Format zu hacken. Ich bekomme leider beim Öffnen ein XML-format Error.

Das da meine ich. Es geht darum, ob jetzt Hyperlinks im bwpt format möglich sind.

kiozen:
Oliver ich hab meinen Text in der Zwischenzeit geändert. Kannst Du bitte mal auf die Sache mit den Links in der bwpt eingehen.

Zitat von Sardinien

Hallo Uwe,
Die bei der bwpt Generierung eingebetteten txt und bmp (png und jpeg wird konvertiert) Files sind in TwoNav/CGPSL -nur W7/32 bei mir- anzeigbar, eingebettete html und PDF dagegen nicht.

Danke Gert,
hast Du in die txt Dateien Bildchen verlinkt via <img ...><\img> oder direkt als zusätzliche Verknüpfung (die wird ja dann eingebettet).

Sinn der Frage:
Das binäre WPT Format ist nur schneller wenn es klein gehalten wird. Als ich das vor ein paar Monaten einmal genauer angesehen habe schien es mir, als ob Bildverknüpfungen dann in den binären Container verweisen und damit ins Leere laufen. Die alte BWPT Version hat ja die Links völlig entfernt.

http://www.naviboard.de/vb/showthread.php?t=51874

Ist aber eher als Overlay über eine gute Rasterkarte zu empfehlen und hat noch ein paar Macken.

Zitat von kiozen

Kann man den Pfad auch relativ eingeben? Also als Link einfach "./Testimage.html" und die Datei liegt im selben Ordner wie die GPX Datei. Absolute Pfade sind für mich ein no-go.

Nach Test mit diversen GPX Konfigurationen steht eindeutig fest:
absolute Pfade sind ein Muß, sowohl in den html Dateien als auch in der GPX Datei. Sind die Bilder in der html Datei relativ verlinkt, werden sie nicht angezeigt, selbiges gilt für die Verlinkung der html Datei in der gpx Datei. Wird in der gpx Datei der Pfad in Anführungstrichen angegeben, hängt sich TwoNav auf.

Zitat

Ich habe mir deine BWPT Datei genauer angesehen. Ab Byte 0x48 weisen die Daten eine ausgeglichene Entropie auf, was auf eine Kompression schließen lässt. Ein kleines c++ Programm zeigt, dass diese Vermutung zu stimmen scheint. Die Daten sind z komprimiert. An Adresse 0x40 steht die zu erwartende Länge (0xFFFE). Der Wert an Adresse 0x44 ist ein Rätsel, genauso wie der Kram vor 0x40.

Im entzipten Teil (den habe ich wieder angehängt) steht hauptsächlich Text UTF-8 kodiert. Irgendwie bin ich aber gerade zu doof die Koordinaten zu finden. Der binäre Müll zwischen den Textfeldern will keinen passende Floatzahl ergeben. Naja vielleicht brauch es noch einen weiteren Kaffee...

Wie dem auch sei. Ich weiß nicht ob ich mich dazu aufraffen kann das komplette Format zu hacken. BWPT geht zwar schneller und hat den Vorteil dass Bilder eingebettet werden können. Stellt zum aktuellen Zeitpunkt aber viel Arbeit dar. Ärgerlich dass Compe hier keine Specs herausgibt.

Das ist doch schon nicht schlecht für den Anfang, allerdings hat Compe das Format geändert, ich vermute ein Blick in eine mit einer aktuellen Version erstellte BWPT (incl. Geocaching Infos und includierte Textdatei) dürfte noch mehr erleuchten.

Ich hab mal schnell meine gpx in eine aktuelle bwpt umgewandelt. Versuch doch mal bitte, diese zu extrahieren und schau nach, ob dort noch die Hyperlinks[url][\url] vorhanden sind. Wenn ja, lohnt es sich aus meiner Sicht, das neue BWPT-Format zu hacken. Ich bekomme leider beim Öffnen ein XML-format Error.

Zitat

Wahrscheinlich liest Compe immer alles, anstatt nur die wichtigste Info einzulesen und den Rest per Index bei Bedarf.

Glaub ich auch. Daher mein Ansatz: schmeiß viele Wegpunkte in das alte BWPT Format (oder das neue BWPT Format, falls Hyperlinks funktionieren) und nutze im Bedarfsfall GPX Dateien für die Zusatzinfos. Nur so bleibt das System einigermaßen schnell. Der Rest ist doch nur Frust.

PS: Wenn ich mich nicht irre steht vor x40 die bwpt Versionsinfo.

Zitat von Sardinien

Hallo,
wird eine wpt mit 1200 txt Verknüpfungen von wpt in bwpt konvertiert, werden die txt in die bwpt geschrieben und die Öffnungszeit reduziert sich am Sportiva um 50%.

Es gibt noch einige Ungereimtheiten, die mir aufgefallen sind:

auf W7/64 und CGPSL 7.4 können die in der BWPT eingebetteten txt File nicht geöffnet werden
auf W7/64 TwoNav + W7/32 TwoNav + CGPSL 7.4 können die in der BWPT eingebetteten txt File geöffnet werden

Alles anzeigen

2 Probleme sehe ich hier:
1) Werden die mit der Textdatei verknüpften Bildchen auch angezeigt (evtl. sogar ohne in die bwpt integriert zu sein)?
2) Das Problem sind die vielen Geocaching Tags. Wandel ich eine GPX mit sagen wir 1000 Caches in eine bwpt um, verliere ich sämtliche Performance Vorteile der bwpt, da sie langsamer öffnet und das System träger macht als die ursprüngliche GPX. Ist zumindest bei meinem beschränkten Arbeitsspeicher der Fall.

Zitat

JPEGS+PDF können in W7/64 aus bwpt's geöffnet werden.

Als Verknüpfung zum Original oder integriert in die bwpt?

Gruß Uwe

Chris.50:
Danke für den Tip, die Darstellung wurde verbessert und tatsächlich konnte ich das Bildchen sichtbar machen:
Absolute Pfade scheinen bei der Grafik nötig.

Zitat

<img src="Storage Card\Pois\Images\Testimage.jpg" width="240" height="320">Hier wäre das Bild gewesen</img>

funktioniert.

Zitat

<img src="Storage Card/Pois/Images/Testimage.jpg" width="240" height="320">Hier wäre das Bild gewesen</img>

funktioniert nicht.

Das Ganze war eigentlich nur als "proof of concept" gedacht. Ehrlich gesagt finde ich die WinCe Geräte dafür nicht mehr wirklich zeitgemäß und habe meine Spoilerbildchen incl. 300000 Caches GSAK Datenbank auf meinem Androiden dabei, wo Locus das alles auch problemlos händelt.
Twonav funktioniert sehr gut mit dem alten BWPT Format, auf die Beschreibung und die Bildchen verzichte ich aus Performancegründen und weil ich eine Alternative habe.

Gruß Uwe

Nach ein wenig Suche habe ich tatsächlich eine Möglichkeit gefunden, Dateien aus einer Geocaching GPX heraus zu öffnen:
die URL.
Wird wie in meinem Fall die Url mit einem Link zu einer html-Datei ersetzt, öffnet TwoNav Pocket diese wie einen Link. Leider sind die Pfade genau zu beachten.
Im Beispiel mit folgendem Pfad zu der Beschreibungsdatei:
Storage Card\Pois\_1_tst\Testimage.html
sieht der URL Tag so aus:
<url>Storage Card\Pois\_1_tst\Testimage.html</url>
Geöffnet wird das ganze über Langclick auf den Poi:
Öffnen Link

Anbei die Testdateien zum Nachvollziehen (Achtung html ist nicht meine Stärke & die durch die html aufgerufene Bilddatei weigert sich standhaft, außerhalb des Rootverzeichnisses von Twonav dargestellt zu werden, im root als mit <img src="Testimage.jpg" width="240" height="320">Hier wär das Bild gewesen</img> klappt es, sonst nicht).

Nach der Lösung des Problems mit der Bilddarstellung müßte die GPX-Datei nur noch auf das Wesentliche reduziert werden, also mindestens die Beschreibung und die Logs und Spoilerbildchen in eine externe html Datei ausgelagert werden und schon dürfte TwoNav wesentlich schneller sein und besser zum Geocaching geeignet noch dazu.
Allerdings finde ich diesen Ansatz insofern problematisch, da mit einer doch recht großen Anzahl von zusätzlichen Dateien auf der SD garantiert bald mit Problemen im Filesystem und erhöhtem chkdsk /f Aufkommen zu rechnen ist. Besser scheint mir da die Erstellung einer einzigen Mobipocket/Ebook -Datei mit entsprechender Indizierung. Mobipocket erlaubt leider keinen Commandline Aufruf zu einer bestimmten Stelle, kommt aber hervorragend mit riesigen Dateien (1,6GB +) zurecht.

PS: Ich glaube langsam sollten wir die Diskussion in einen separaten Thread verlagern.

Zitat von kiozen

Ja, leider. Das wpt Format scheint halt das einzige Format zu sein, mit dem man alle Cacheinformationen bekommt und auch noch Dateien (z.B. Bilder) mit dem Cache verbinden kann.

GPX wäre schon fein, da lassen sich nur keine zusätzlichen Dateien wie Bilder anhängen. Könnte man mit BWPT alle Cacheinformationen und Bilder verarbeiten? Und ist das BWPT Format irgendwo dokumentiert?

Ja das stimmt, Bilder bekommt man nicht in das BWPT Format, ohne den Vorteil (Geschwindigkeit) zu verlieren und Links funktionieren nicht..
Hier hatte ich einmal versucht zusammenzufassen, was über das Format rauszukriegen ist. Eine brauchbare Dokumentation des Formats gibt es nicht. Ich vermute, daß das neuere BWPT Format die Geocaching Tags auch in den Waypoints ohne Geocaching Infos abspeichert, daraus resultieren wohl die längeren Öffnungs- und Speicherzeiten und die größere Dateigröße. Wenn Du Bilder und Cachebeschreibung brauchst, bastel Dir doch am besten eine Lösung mit minimalen Infos in den WPTs und Link zu einer Datei mit mehr Infos inkl. Bildern. Das geht allerdings nicht als BWPT und wird bei ich schätze mal so an die 1000-1500 Waypoints in einer Datei langsam an die Grenzen des System kommen. Aber das haben andere ausführlicher getestet.

Bei mir dauerte es:
bei deiner wpt Datei: 1:30min.
bei der original gpx-Datei (ohne Zusatzwegpunkte): 44s
bei meiner bwpt Datei: 10s
Probier es doch bitte selbst einmal aus. Angehängt das Ergebnis der GSAK/CGPSL Umwandlung. Vorher muß noch die Geocaching.zip im Symbols Verzeichnis gegen die beiliegende Datei ausgetauscht werden. Wichtig: die BWPT Datei wurde mit CGPSL v.7.03 erstellt (eine Version vor Unterstützung des Geocaching). Dadurch sind die BWPT's viel kleiner und öffnen erheblich schneller.

Edit:
PS: Die Symbole mit den Sternchen wurden bei GCvote mit 4(+) bewertet oder haben eine recht hohe Anzahl blauer Schleifchen. Die mit den roten Kletterern sind T5er.

Zitat von kiozen

Na klar kann ich das. Es ist natürlich eine *wpt Datei und keine *trk. Da bin ein ein bisserl durcheinander gekommen.

Edit: kallmunz.zip ist natürlich die falsche Datei Das ist das Pocketquery selber. caches.zip ist die *wpt Datei. Man soll nichts zwischen Tür und Angel machen.

Als Geocacher würde ich nicht das wpt Format wählen. Bei meinen letzten Tests gab es kaum Unterschiede zwischen der Performance von GPX und WPT Dateien mit Geocaching Informationen. BWPT-Dateien, die diese Informationen beinhalten sind schlechtweg unbrauchbar auch aus Performance Gründen. Für mich am brauchbarsten BWPT ohne Geocaching Infos aber mit Symbolen und Hints (bis zu 5000 gleichzeitig ohne Probleme, 3000 öffnen z.B. in ca. 20s auf meinem System [ca. 40MB RAM]) und fürs Paperless Caching noch GPX-Dateien, exportiert in kleinen Häppchen aus GSAK, z.B. nach Landkreisen.

Nachtrag:
Gerade habe ich noch einmal die aktuelle TwoNav Pocket 2.6 heruntergeladen und getestet.
Fazit:
Nun habe ich 3 offizielle Versionen TwoNav Pocket 2.6 auf der Festplatte, mit teils verschiedenen Produktionsdaten: 28.06.2012 (entspricht der ersten und zweiten Version [dem offiziellen Release eine Woche nachdem die 'erste Version' zurückgezogen wurde]) und eine aktualisierte Version mit Produktionsdatum 10.07.2012. Bei der letzten Version sind mindestens die CompePocketEngine.dll und die Idioma.def verändert, mehr Veränderungen sind mir erst einmal nicht aufgefallen.
Und ... die Performance ist wesentlich besser (zumindest auf den ersten Blick). Feldtests stehen noch aus.

Wie es aussieht hatten die Spanier "vergessen", die bugbehaftete finale Version auszutauschen. Das wurde scheinbar in den letzten Tagen nachgeholt.

Mir geht es wie Ray.
TwoNav WM6:
Die 2.6 Final gehört wirklich zu den lahmsten Versionen, die ich bisher auf dem Gerät hatte.

Am schwierigsten sind die Kontext- aber auch die normalen Menüs, eh die Aufklappen, Anfangs dachte ich der Touchscreen würde nicht reagieren, hab dann mehrmals gedrückt und damit das Menü wieder weggedrückt .... mittlerweile beruhige ich mich immer, indem ich bis 15 zähle. Vielleicht sollten die Jungs in Spanien eine Warteschlangenmelodie einprogrammieren.
Auch ich konnte eine Verbindung zwischen zunehmendem Tourverlauf und der Trägheit beim Aufrufen von Menüs feststellen. Mittlerweile bin ich zurück zu V.2.6 RC2 die etwas schneller ist. Gleichzeitig ist aber noch 2.4.3 auf dem Gerät und die ist rasend schnell (im Vergleich).
Konfiguration: Selbstgebastelte MPVF&RMAP, ca. 3000 POIs als bwpt (über Data aufgerufen - Reduktion auf nur 1000 POIs machen das Ganze aber auch nicht spürbar schneller), auschließlich Luftlinienrouting, beim Routen auf der MPVF kommt es neuerdings immer mal wieder zu NMEA-Fehlern, die durch aus und einschalten des Satempfangs wieder aufhören..

Zitat von ray

Der schlechte erste Eindruck von 2.6 hat sich leider bestätigt.

Beim Aventura ist primär der Aufruf der Pages klar langsamer.
Wird im Tourverlauf auch immer langsamer.

Beim Sportiva+ das gleiche, hinzu kommt das Zoomen und Scrollen langsamer ist als in 2.5.2.
Habe dann sogar 2d-Schattierung und Antialiasing abgeschaltet -> keine Verbessung.

sehr enttäuscht
ray

Alles anzeigen

Kann ich bezüglich der TwoNav Pocket Variante nur bestätigen. Aufruf der Menüs dauert ewig, Reaktion auf LongClick sehr träge .... Schade!

Bei iTunes
Aber eigentlich gilt für alle Versionen, daß die downloadbare Version normalerweise nicht freigeschaltet die Free Version ist. Erst durch eine Freischaltung durch Compe/iTunes/Android Store und/oder ein entsprechendes Keyfile wird sie zur Pro Version.
Davon einmal abgesehen, daß die FreeVersion aus meiner Sicht eine nicht wirklich nutzbare Version ist. Zumindest im PocketPCBereich ist die sogenannte Freeversion vom Funktionsumfang her nicht zu vergleichen mit der vorherigen Demoversion.
FreeVersion-nein, einfach nur ein Marketing-Version.

Die "neue" PocketVersion entspricht bit- & datums- genau der vor knapp einer Woche durchgesickerten finalen 2.6. Version.

Nachtrag:
Gerade getestet:
MD5 der Pocketversionen (zip) als auch der Androidversionen sind identisch

Schau mal hier. Eventuell hilft ja eine Reduktion der zu bearbeitenden Datenmenge auf das Wesentliche (speziell Punkt 2). Ich selbst kann es nicht mehr Testen, da der Demozeitraum abgelaufen ist.

Zitat von hedgehog

Nach einem Tag Geocaching mit der RC3 bin ich frustriert zur 2.4.3 zurückgekehrt.
Fazit: Viel schnellere Reaktion beim Auswählen von POIS auf dem Screen und auch bei der Reaktion der Menüs in der früheren Version auf meinem Gerät.

Die RC4 ist auch nicht wirklich schnell im Vergleich zur 2.4.3.
Mein Wegpunktfile ist eine bwpt Datei mit ca. 1400 Punkten.
Gibt es eine Mailadresse an die man die Bugs/Probleme der Betaversion melden kann?

Diese wären aus meiner Sicht:

1) Reihenfolge des Kontextmenüs bei langem Click auf einen Wegpunkt auf der Karte:
Jetzt:
[INDENT]Neu
Zentriere Karte hier
Beste Karte laden
Eigenschaften
Wegpunkte speichern
Wegpunkte schließen
Ziel
Wegpunkt ändern
[/INDENT]

Das erscheint recht unlogisch, da es noch ein anderes Kontext-Menü bei LangClick auf die Karte (nicht auf den Wegpunkt gibt).
Logischer wäre z.B.:
[INDENT]
Ziel
Eigenschaften
Wegpunkt ändern
Wegpunkte speichern
Wegpunkte schließen
Neu
Zentriere Karte hier
Beste Karte laden
[/INDENT]
Meinetwegen kann auch Neu ganz oben hin. Ich denke aber, daß die Mehrheit der Benutzer eher die wegpunktrelevanten Menüeinträge oben braucht.

2.) Im Vergleich zur Vorgängerversion langsame Reaktion bei der Auswahl der Menüs, die mit Wegpunkten zu tun haben. Das scheint an internen Sortiervorgängen für die Darstellung zu liegen.
Als temporäre Lösungsmöglichkeit für micht:
Conf-System-Erweitert-Info in Wegpunktliste
Nichts aktivieren

Macht zumindest die Listendarstellung der Wegpunkte etwas schneller. Allerdings scheinen die Wegpunkte trotzdem noch intern nach nicht nachvollziehbaren Kriterien (Entfernung?) sortiert zu werden. Hier fehlt es an der konsequente Umsetzung der vom Nutzer eingestellten Optionen bzw. an einer Option für die Standardsortierung. Außerdem beschleicht mich das Gefühl, dass es Situationen gibt, in denen eine Sortierung der Wegpunkte vor der Anzeige stattfindet, obwohl diese Sortierung zur Anzeige gar nicht notwendig ist (unnötiger Aufruf der Routine zur Sortierung).

Nach einem Tag Geocaching mit der RC3 bin ich frustriert zur 2.4.3 zurückgekehrt.
Fazit: Viel schnellere Reaktion beim Auswählen von POIS auf dem Screen und auch bei der Reaktion der Menüs in der früheren Version auf meinem Gerät.