Maximale Länge von Beschreibungen in GPX-Dateien

[netztier]

Hallo zusammen

 

Wir kennen ja dieses Problem bereits: Multi-Cache mit vielen Stationen wird nicht komplett angezeigt. Ist zwar vielleicht Garmin/Oregon spezifisch, aber andere Geräte haben damit vielleicht auch ihre Probleme, drum nach Geotalk gepostet. Forum-Moderators: schiebt's nach Gutdünken in eine andere Kategorie, falls es hier zu unpassend ist.

 

Ich hab daraufhin bei Garmin angeklopft und es hat sich folgender Mailrattenschwanz zusammengefunden (ein bisschen optisch herausgeputzt, damit es lesbar wird)

 

Hi again

 

The US have got back to us saying there is a limit of 8000 chcracters in

the cache description.

 

If there is anything else I can help you with then please let me know.

Alternatively you can search for a solution here: http://www.garmin.com/support

 

 

Kind regards

Mark Beckett

 

Garmin ( Europe ) Ltd

The Global leader in satellite navigation

 

 

 

 

Dear Marc Luethi,

 

Thank you for contacting Garmin Europe. We have passed your enquiry to

our US software developers to look at. We will get back to you as soon

as we get a reply from them.

 

If there is anything else I can help you with then please let me know.

Alternatively you can search for a solution here: http://www.garmin.com/support

 

 

Kind regards

Mark Beckett

 

Garmin ( Europe ) Ltd

The Global leader in satellite navigation

 

 

 

Original Message Follows: ------------------------

 

 

Form Message

Knowledge Job Ticket: {147830a0-3ed9-11de-c88f-000000000000}

KnowledgeBase: garmin

Subject: long_description in GPX file gets truncated Message Body:

 

Hi Garmin Support

 

Geocache GC113EA has a rather large GPX file (about 52kB) with some

33kB of embedded HTML in the <groundspeak:long_description> ...

</groundspeak:long_description> tags. The HTML code in there was

generated with Coffe Cup HTML editor and then copy&pasted into

Groundspeak's web interface, the author says. The code itself looks

horribly bloated, though. My Oregon 400t however truncates

long_description after circa 9 of the 33kB embedded HTML.

 

The displayed text ends like this:

 

*** snip ****

Verangenheit zurückversetzt.

&n

 

***snip ****

 

The rest of the file, such as <groundspeak:encoded_hints> ...

<groundspeak:encoded_hints> and the long tail of

<groundspeak:logs> ... </groundspeak:logs> is perfectly well

displayed. Is there some size/lenght limitation for content within

tags in a GPX file? Thanks for looking at this and maybe providing

a fix.

 

best regards

 

Marc

 

PS: I have the authors permission to forward the GPX file, should

it be unavailable to you.

 

 

Also: haltet die Textmenge für die detaillierte Beschreibung unter 8kByte, dann sind auch alle Oregon-Benutzer glücklich :-)

 

 

Gruss

 

Marc

Bearbeitet 2. Juni 2009 von netztier

[chjasipa]

Also: haltet die Textmenge für die detaillierte Beschreibung unter 8kByte, dann sind auch alle Oregon-Benutzer glücklich :-)

 

Dem gibts nichts beizufügen...

Ich habe auch schon einige Posts in diese Richtung geschrieben, meistens, wenn es um das Formatieren von Listings ging...

[Gast Vatanen73]

Ich denke eher, dass sich Garmin da anpassen muss.

 

Das wäre doch eine grobe Behinderung in der Darstellung der Listings.

Oder die Gremlin/Oregon User müssen halt bei solch überlangen Multi-Listing wie früher ihren Drucker bemühen.

 

Es grüsst de HP vo Oute.

[netztier]

Ich denke eher, dass sich Garmin da anpassen muss.

 

Klar sollten sie das - nachgerade da sie ihre Geräte ja als besonders für Geocaching geeignet anpreisen.

 

Oder die Gremlin/Oregon User müssen halt bei solch überlangen Multi-Listing wie früher ihren Drucker bemühen.

 

Das Problem liegt ja nicht an den Multi-Listings an sich - weil der rest vom GPX-File, namentlich die Waypoints und Logs, sind alle dabei und werden angezeigt - es geht nur um den "langen Beschreibungstext". 8000 Zeichen für eine "Long Description" sind doch nennenswert viel Text. Wenn allerdings davon über 80% als HTML-Code "verpuffen" (unabsichtlich, z.B. durch Einsatz von HTML-Editoren, die jede Leerzeile unnützerweise auch noch mit Farb-, Positionierungs- und Sprachinformationen versehen), bleibt nicht mehr viel Platz, auch noch etwas Inhalt unterzubringen.

 

Auf der anderen Seite sollte sich geocaching.com bzw Groundspeak (oder wer immer das GPX-Format festgelegt hat) in Zusammenarbeit mit Garmin vielleicht mal drum kümmern, wie Bildverweise, die in die GPX-Dateien eingebettet sind, so aufgelöst werden können, dass die Bilder dann auch automatisch auf den Geräten erscheinen - sowohl für bilder in der Beschreibung als auch angehängte Spoiler-Bilder. Bei den versteckten Tips klappt das ja auch...

 

Hm, die Leute von https://garminoregon.wikispaces.com/ haben da schon ein paar konkrete Vorstellungen, was die Kistchen noch lernen sollten. Dann werd ich mich da mal anhängen...

 

Gruss

 

Marc

Bearbeitet 22. Mai 2009 von netztier

[chjasipa]

Ich denke eher, dass sich Garmin da anpassen muss.

 

Das ist Ansichtssache...

 

Aber was ich im Feld zuletzt brauche, sind farbige Texte, andere Schriftarten, überlange Beschreibungen u.s.w. Ein kurzer, aussagekräftiger Text reicht mir. Und das lässt sich mit einfachsten Mitteln erreichen....

Auch wenn die 8000er Grenze fällt und das Gerät in Zukunft mehr HTML-Code interpretieren kann - das Display wird deshalb nicht grösser und z.B. überbreite Tabellen bleiben unübersichtlich... Abgesehen davon sind blinkende Schriften, animierte GIFs, Comic-Schriften u.s.w. schon seit Ende der Neunziger nicht mehr wirklich in ;-)

Wünschenswert wäre allerdings eine Verlinkung zu Bildern.

 

Aber eben, das ist die Meinung von einem, der auch formatierte Emails hasst und konsequent im "nut Text"-Modus schreibt. Zudem sympathisiere ich mit Leuten, die den Blocksatz verbieten möchten ;-)

 

Gruss chjasipa

[Hibu und Enrice]

Ein kurzer, aussagekräftiger Text reicht mir. Und das lässt sich mit einfachsten Mitteln erreichen....

 

Die meisten unserer Cachebeschreibungen leben halt mit Bildern und Skizzen. Sie sind Voraussetzung diese Caches überhaupt realisieren zu können. Z.B. hier oder hier.

Beim parierlosen Cachen mit meinem Palm, der doch meines Wissens mit älterer Technologie arbeitet, werden Bilder und Skizzen perfekt dargestellt, bei den neuen Garmin Geräten jedoch nicht. Ist das wirklich ein derart schwieriges technisches Problem?

 

Na ja, wenigstens hatte ich bisher nicht das Gefühl, das dies euch davon abgehalten hat unsere Caches zu besuchen.

[Paravan]

Ist das wirklich ein derart schwieriges technisches Problem?

An sich ist es möglich, zumal das Oregon als auch das Colorado problemlos Bilder anzeigen können. Ich kann mir vorstellen, dass das bei Pocket-Queries aber ein Problem darstellen kann:

Nehme wir an, eine Pocket Query enthalte 500 Cache-Beschreibungen. Eine solche Query ist bei mir heute rund 4 MB gross. Nehmen wir weiter an, bei jedem Cache würde noch ein 40 kB grosses Bild mitgeliefert (wie das z.B. bei Deinem Cache GC14T2C "Nippel" der Fall ist). Dann würde eine solche Poekt-Query plötzlich 4 MB + 500*40 kB = 24 MB gross. Da Bilder als JPG schon komprimiert sind, kann man diese auch mit Zippen nicht noch viel kleiner machen.

Ich erhalte wöchentlich 4 Pocket-Queries, um die Limite meines Oregon (aktuell 2000 Cache) zu nutzen, d.h. Mein Postfach würde regelmässig mit mehr als 80 MB gefüllt. Mein Mailkonto hat damit kein Problem, aber die meisten Postfächer sind nicht so gross.

Zugegeben: Nicht jeder Cache hat ein Bild in der Beschreibung, dafür haben andere mehrere (wie der andere von Dir aufgeführte Cache), aber die Schätzung soll zeigen, wo das Problem liegen könnte.

Das nur eine Vermutung von mir, warum man das nicht einfach so einrichten kann.

 

Schön wäre es aber, wenn man wenigstens für einzelne Caches die Bilder automatisch laden und in der Beschreibung anzeigen lassen könnte.

[chjasipa]

An sich ist es möglich, zumal das Oregon als auch das Colorado problemlos Bilder anzeigen können. Ich kann mir vorstellen, dass das bei Pocket-Queries aber ein Problem darstellen kann:

Nehme wir an, eine Pocket Query enthalte 500 Cache-Beschreibungen. Eine solche Query ist bei mir heute rund 4 MB gross. Nehmen wir weiter an, bei jedem Cache würde noch ein 40 kB grosses Bild mitgeliefert (wie das z.B. bei Deinem Cache GC14T2C "Nippel" der Fall ist). Dann würde eine solche Poekt-Query plötzlich 4 MB + 500*40 kB = 24 MB gross. Da Bilder als JPG schon komprimiert sind, kann man diese auch mit Zippen nicht noch viel kleiner machen.

Ich erhalte wöchentlich 4 Pocket-Queries, um die Limite meines Oregon (aktuell 2000 Cache) zu nutzen, d.h. Mein Postfach würde regelmässig mit mehr als 80 MB gefüllt. Mein Mailkonto hat damit kein Problem, aber die meisten Postfächer sind nicht so gross.

Zugegeben: Nicht jeder Cache hat ein Bild in der Beschreibung, dafür haben andere mehrere (wie der andere von Dir aufgeführte Cache), aber die Schätzung soll zeigen, wo das Problem liegen könnte.

Das nur eine Vermutung von mir, warum man das nicht einfach so einrichten kann.

 

Schön wäre es aber, wenn man wenigstens für einzelne Caches die Bilder automatisch laden und in der Beschreibung anzeigen lassen könnte.

 

Ich bin kurz davor, meine Gesamtschweiz-GSAK-DB einzumotten... Der Aufwand, die Daten aktuell zu halten, übersteigt inzwischen bei Weitem der Nutzen:

- Inkl. grenznahes Ausland sind jetzt 9927 Wegpunkte in der DB.

- Diese habe ich bis dato wöchendlich mit 14 PocketQuerries (ca. 25MB) aktualisiert.

- Die 26'633 dazu gehörenden SpoilerSync-Dateien füllen inzwischen knapp 1GB!

- Das Ganze dann noch als HTML-Export für den PDA, sind nochmals 9149 Dateien /285MB

Das Ganze läuft zwar schön automatisch, dauert aber mittlerweile fast 5 Stunden. Ein wahnsinnsaufwand, um 0-10 Caches pro Woche zu machen.

 

Vielleicht veranschaulichen diese Daten, warum GC keine Bilder in die PQ's packt ;-)