GPX mit Addi-Waypoints nach GSAK exportieren

[MiK]

holen wir also unsere flagge ein und hissen eine andere.

Wenn wir sowieso die Groundspeak-Tags benutzen, ist das sowieso egal.

da ich gerade an der gui bastel

Hast Due auch eine Möglichkeit dies auch immer auf QVGA-PDA zu testen?

 

[Wutschkow]

Keinen Stress. Ich benutzte dass ja nun auch nicht ständig und die eine Zeile in der GPX ist schnell manuell ausgetauscht.

 

[greiol]

da ich gerade an der gui bastel

Hast Due auch eine Möglichkeit dies auch immer auf QVGA-PDA zu testen?

nein und auf grund der art der geplanten änderungen erkenne ich auch derzeit nicht die notwendigkeit dafür.

 

[Wutschkow]

Wenn es mal drauf ankommt, kann ich gerne den QVGA-Tester spielen. Muss ich früher oder später dann sowieso machen. Ich hab ja nix anderes.

 

[MiK]

da ich gerade an der gui bastel

Hast Due auch eine Möglichkeit dies auch immer auf QVGA-PDA zu testen?

nein und auf grund der art der geplanten änderungen erkenne ich auch derzeit nicht die notwendigkeit dafür.

Naja, oft bringen kleine unscheinbare Änderungen das DetailsPanel schon aus dem QVGA-Rahmen (siehe D/T Editierbarkeit). Leider haben wir da nicht mehr viel Spielraum.

Ich selbst habe das nur kurz an dem Tag getestet, an dem mein PDA wieder da war. Mittlerweile ist er schon wieder auf dem Weg zu Asus :-(

 

[greiol]

ich erklär einfach kurz was kommt (auch wenn das dann vielleicht in einen neuen fred gehört):
- es kommen keine neuen elemente
- werden keine elemente umpositioniert
- ob wir große symbole verwenden, rechenen wir aus in MainTab, DetailsPanel, NotesScreen, StatusBar und navi/MovingMap. nach welchem schema das bei den attributen passiert ist mir noch unklar, aber das finde ich schon noch raus. das soll demnächst einmal ausgerechnet werden in den preferences und der user soll es überschreiben können. mit dem ergebnis muss er dann selber leben. wobei ich noch überlege von der moving map die finger zu lassen
- im detailspanel werden die teilergebnisse derzeit nach verschiedenen methoden (direkt und indirekt) gesichert. da hätte ich gerne eine
- im detailspanel wird beim umbenennen des wegpunktes ein neues cache.xml angelegt, statt das alte umzubenennen. damit gehen alle notizen, bilder etc zum wegpunkt verloren

 

[MiK]

- ob wir große symbole verwenden, rechenen wir aus in MainTab, DetailsPanel, NotesScreen, StatusBar und navi/MovingMap. nach welchem schema das bei den attributen passiert ist mir noch unklar, aber das finde ich schon noch raus.

Bei den Attributen werden immer die Bilder genommen, die im Verzeichnis "attributes" liegen. Da am Anfang die größeren bei QVGA nicht auf den Schirm passte, habe ich zusätzlich die kleinen erstellt. Mittlerweile passen aber auch auf QVGA die großen Versionen. Deswegen könnte man eigentlich die kleinen "attributes" komplett aus dem SVN werfen und das "attributes-big" in "attributes" umbenennen. Bei der Gelegenheit kann man es auch gleich korrekterweise nach res-noewe verschieben.

 

[greiol]

Bei der Gelegenheit kann man es auch gleich korrekterweise nach res-noewe verschieben.

ich überleg mir was geeignetes. erst mal wird das speichern der details geflickt. das verschieben der bilder kann ich noch erledigen wenn ich den merge hinter mir habe.

 

[greiol]

je länger ich das details panel anschaue desto verwirrter bin ich. im moment schreibt ein teil des codes seine daten direkt zurück ins cache objekt, ein teil tut das erst am schluss. manchmal wird bei einer änderung indirekt auch ein schreiben aufs filesystem ausgelöst (weil die aufgerufenen routinen das machen) und andere sachen werden erst ganz am schluss weggeschrieben.

save-on-change und save-on-leave(-if-changed) haben beide vor und nachteile. save-on-change ist die absturzsichere variante mit mehr filesystem zugriffen wenn mehrerer änderungen stattfinden. save-on-leave schreibt nur einmal, aber natürlich mit dem risiko, dass die änderunegn bei einem absturz weg sind. mir gefällt change-on-leave irgendwie besser. auf jeden fall würde ich es aber gerne einheitlich machen.

 

[greiol]

Wenn man in der GPX-Datei aus

<desc>This is a list of waypoints for geocaches generated by CacheWolf</desc>

einfach

<desc>This is an individual cache generated from Geocaching.com</desc>

macht (egal ob nun ein Cache oder mehrere drinstehen), dann klappt es auch mit den Child-Waypoints. Offenbar brät GSAK da eine Extrawurst für GPX-Dateien von GC.

ich hab es tatsächlich getan und mit mal ein gsak installiert es sieht wirklich so aus dass nur genau dieser eine eintrag gsak dazu überredet die addis zusammen mit den caches in einer datei zu akzeptieren. in allen anderen fällen werden sie als "other" eingefügt. ich kann das natürlich per default oben rein schreiben, aber was machen wir mit der nächsten applikation die da gerne etwas anderes hätte?

 

[MiK]

Naja, alle Programme, bei denen es um Geocaching geht, werden GPX-Dateien lesen können, die so aussehen, wie die von GC. Trotzdem finde ich es unschön, dass GSAK da so pingelig ist. GPX direkt von OC kann man somit dann auch nicht einlesen.

 

[greiol]

Naja, alle Programme, bei denen es um Geocaching geht, werden GPX-Dateien lesen können, die so aussehen, wie die von GC.

gc.com kennt drei verschiedene <desc></desc> varianten. mit den beiden anderen weigert sich gsak die addis zu erkennen. ich werde es jetzt erst mal so eintragen und hoffen dass keine weitere software kommt und rumzickt.

 

[Wutschkow]

ich hab es tatsächlich getan und mit mal ein gsak installiert es sieht wirklich so aus dass nur genau dieser eine eintrag gsak dazu überredet die addis zusammen mit den caches in einer datei zu akzeptieren. in allen anderen fällen werden sie als "other" eingefügt. ich kann das natürlich per default oben rein schreiben, aber was machen wir mit der nächsten applikation die da gerne etwas anderes hätte?

Naja, das ist ja so gesehen keine GSAK-Spezialität, sondern eine GC-Spezialität, die GSAK ausnutzt. Eine Anwendung, die da gerne was anderes hätte, wäre dann eine Anwendung, die GC-GPX nicht korrekt verarbeitet? Mag aber durchaus sein.

Aber wenn das sonst eh keiner braucht, keinen Stress. Ich packe mir einen Skriptbefehl ins Kontextmenü für GPXe, der die Zeile austauscht. Ist keine große Sache.
Oder könnte ich mir ein eigenes Template stricken, das die richtige Zeile einbaut? Damit habe ich mich noch nie beschäftigt. Deshalb weiß ich nicht, ob sich diese Angabe per Template bestimmen lässt.

Mich stört mehr, dass GSAK immer noch nicht alle GPX-Exporte von CW schlucken will. Aber Du hast da nochmal was dran geändert, oder? Ich probiere es erst nochmal mit der aktuellen Version, bevor ich wieder mosere!

 

[Wutschkow]

GPX direkt von OC kann man somit dann auch nicht einlesen.

Doch klar. Da tritt das Problem gar nicht auf, weil es bei OC eh keine Addis gibt, oder?

 

[greiol]

Oder könnte ich mir ein eigenes Template stricken, das die richtige Zeile einbaut?

das gpx "gebastel" lässt sich leider nicht wirklich mit einem template erledigen, da stecken zu viele bedingungen drin um zu entscheiden wann eigentlich was angezeigt wird.

Mich stört mehr, dass GSAK immer noch nicht alle GPX-Exporte von CW schlucken will. Aber Du hast da nochmal was dran geändert, oder? Ich probiere es erst nochmal mit der aktuellen Version, bevor ich wieder mosere!

nach der änderung des desc strings hatte ich keine probleme mehr, die version gibt es aber noch nicht im download. allerdings habe ich auch in meiner cw cachedb keine komischen URLs und keine "müllzeichen". für die für URLs gibts den fix ein paar freds entfernt. bei den müllzeichen schiebe ich als export die verantwortung weit von mir und hin zum import