QMapShack

Also für Adresse und noch ein wenig mehr reicht es inzwischen bei Garmin

Jetzt habe ich noch mal im Code nachgesehen. Weil ich eigentlich immer im Kopf hatte, dass man Text bequem lesen kann. Zumindest bei einem Cache. Und siehe da, der wird in der wpt Datei ja extra behandelt. Könnte man jetzt versuchen zu missbrauchen

Naja sei es drum. Ich werde wahrscheinlich wirklich noch einen Punkt einführen mit dem man beliebige Dateien einem Objekt anhängen kann, und diese je nach Gerät auch verlinkt werden. Solange man im binären Format von QMapShack bleibt sind diese Anhänge dabei. Bei einem Export nach GPX gehen sie verloren.

Noch eine ganz andere Idee: Wäre es nicht besser das was bei GPX unter <cmt> und <desc> steht, beim Abspeichern auf ein TwoNav Gerät als Textdatei abzulegen und in der wpt Datei darauf zu verweisen? Also gar nicht unbedingt den internen Kommentar zu bedienen.

Zitat von papaluna

du meinst .qms!?
Aber ich will die Daten/Infos doch auf den Geräten haben d.h. sie sollten soweit möglich auch mit GPX oder TRK/WPT verlinkt/exportiert werden.

Richtig. qms ist das interne binäre Format, das frei von Verlusten ist. Die Datenbank benützt es. Und wenn man man zwischen verschiedenen PCs mit QMapShack Daten austauschen will, dann ist qms das Mittel der Wahl. Ich konnte damit dem Trailsucher seinen nachbearbeiteten Track zukommen lassen. Mit der vollen Historie. D.h. er kann jeden Schritt von mir rückgängig machen und nachvollziehen.

Das geht natürlich mit andere Software nicht. Hier ist GPX das Mittel der Wahl. Allerdings kann mit GPX nicht alles gemacht werden. Die Historie kann z.B. nur noch als Erweiterung abgespeichert werden. Ein Wiederherstellen der Daten würde in Form von GPX Erweiterungen nur Ressourcen verschwenden und komplett unnütze sein.

Und genauso ist es mit Anhängen. In qms kann man die als binären Block einfach integrieren. Bei Bildern wird das so gemacht. Bei GPX oder WPT/TRK kann man die Datei nur zusätzlich abspeichern und dann relativ verlinken. Das ist natürlich kein gutes Konzept um Daten zu verwalten oder mal mit jemanden auszutauschen.

Sprich so ein Format wie qms ist wichtig um Daten intern verwalten zu können. Um Daten zu veröffentlichen wandelt man qms in GPX um. Und um Daten mit Geräten auszutauschen wandelt man qms in das Format um, das vom Gerät verstanden wird. Da diese Umwandlungen immer mit Verlusten einhergehen ist das ein Einbahnstraße. Sprich ein bidirektionaler Austausch bei voller Datenintegrität ist nicht möglich.

Zitat von papaluna

Im Moment bekomme ich es nicht hin(geht wohl derzeit noch nicht soweit ich das der doc entnehmen kannl) die Daten als TRK/WPT exportiert zu bekommen nur als QMS oder GPX.

Richtig. Die Formate von Compe haben für mich nur auf dem Gerät einen Vorteil. Außerhalb dieser Blase sind sie zu schwach. Ein geschlossener Container, der ein Projekt darstellt, wie das mit GPX möglich ist, ist mit den Compeformaten nicht drin. Deswegen behelfe ich mir auf dem Gerät mit einem Ordner. Aber das ist kein Konzept für einen Datenexport zwischen PCs und Applikationen.

Das ist alles ein einziger Kompromiss. Aber ich denke bisher ist der recht gut gelungen. Und der Code steht ja offen. Damit kann man das Konzept im Detail verbessern. Deswegen ja auch meine Frage zu anfangs. Sicherlich muss dabei jeder Wunsch gegen alles andere abgeklopft werden. Aber so ein paar Impulse sind doch schon zusammengekommen.

Zitat von papaluna

Also ein Ordner wie z.B. \TwonavData\Data\CinqueTorre in welchem sich dann die entsprechenden TRK und WPT-Dateien incl. der verknüpften Objekte befinden.!?

Genau. Probiere es doch einfach mal aus. Nimm ein Projekt und verschiebe es mit drag-n-drop auf dein angeschlossenes Anima.

Zitat von papaluna

Ich habe gestern und heute probiert mit Qland einen Roadbooktrack zu erzeugen, aber weder das noch ein Export als TRK überhaupt ist mir gelungen.
Den Track kann ich nur als GPX exportieren. So ist er aber auf dem ANIMA nicht brauchbar(als Roadbooktrack).

QLGT funktioniert ähnlich wie QMS. Dort muss man aber links das Gerät auswählen. Also in deinem Fall TwoNav. Und dann mit F9/F10 die Daten austauschen. QLGT wird nach einem Ordner frage. Da kannst Du entweder den vorgeschlagenen Namen mit der Zeitmarke verwenden, oder etwas anderes angeben. In dem Ordner befinden sich dann alle Dateien.

Zitat von papaluna

Gut das funktioniert soweit. Die Verlinkung von Bildern ist mir aber nicht gelungen. Also der Pfad + Name ist im URL-Feld eingetragen, sie werden aber nicht beachtet beim übertragen der Daten.
Allerdings steht nach dem eintragen:
e:%5CGPS_Daten%5CTwoNavData%5C06_Pictures%5CSenneshuette.png
anstatt
e:\GPS_Daten\TwoNavData\06_Pictures\Senneshuette.png
im URL-Feld

Alles anzeigen

Da ich davon ausgehe, dass es die meisten Benutzer überfordert einen korrekten Link zu einem Bild zu erstellen, kann man Bilder direkt in den Wegpunkt einfügen. Schau mal im Dialog, da ist links unter dem Kommentarfeld ein Kopf mit einem Manschgerl und einer Sonne.

Aus QMS Sicht sind Links eher echte Links ins Internet. Sollten Links missbraucht werden um Dateien zu referenzieren, macht das das jeweilige Gerätemodul.

Zitat von papaluna

Spricht eigentlich etwas gegen ein drag&drop zur Verlinkung?

Könnte man bestimmt auch machen. Aber ich bin bei solchen Sachen eher der Dateidialogfan.

Zitat von papaluna

Roadbookpunkte(wenn es dann demnächst funktioniert):
Wenn es kein Einstellung für die Assimilierungsentfernung geben wird, wäre es denn alternativ denkbar eine Möglichkeit zu haben auch vorhandene Wegpunkte manuell als Roadbookpunkte zu definieren, ohne ihre Lage verschieben zu müßen?

Wenn das mal wirklich zum Problem werden sollte. Aktuell (Branch V1.x) lasse ich alles im Umkreis von 50m an den Track schnappen. Bei allem was weiter weg liegt, muss man sich fragen, warum. Liegt der Track falsch, oder der Wegpunkt? Ich hatte bei QLGT damit nie ein Problem.

Probleme gibt es noch wenn Hin- und Rückweg gleich sind. Eigentlich müssten die Wegpunkte jetzt auf 2 Trackpunkte abgebildet werden. Werden sie aber bisher nicht. Das will ich verbessern.

Zitat von papaluna

Ja, ich weiß, nur habe ich da irgendwie das dejavu-Erlebnis das immer wieder nach TwonavData/Data gefragt wird. Dieser Pfad auch mit weiteren Unterverzeichnissen existiert bzw. wurde angelegt, aber qland erkennt ihn nicht als solchen an.
Iegt es an dem / anstatt dem unter Windows üblichen \ ?

Muss ich mir mal in Ruhe ansehen.

Also wenn da ein Wirtshaus steht dann führt doch der Track genau bis zum Tresen, oder etwa nicht?

Ich merke es mir mal. Bisher ist die Wegpunkt/Track Relation nicht fest, d.h. die wird bei jeder Änderung neu berechnet. Da liegt natürlich eine statische Zuweisung reichlich quer. Man könnte natürlich sagen der Wegpunkt muss immer an einen Track schnappen. Da aber für alle Tracks in einem Projekt alle Wegpunkte potentiell zur Verfügung stehen, ist das auch schlecht, weil dann das Wirtshaus auch bei den Tracks, die nun wirklich nichts damit zu tun haben, einen Trackpunkt sucht.

Aus meiner bisherigen Erfahrung heraus hatte ich allerdings nie diese Probleme. Die Punkte lagen in der Regel immer nahe genug. Bzw ich habe den Abstecher, z.B. zu einem Cache immer mit eingeplant. Und im aufgezeichneten Track ist es eh kein Problem, weil entweder man war dort oder nicht.

Zitat von papaluna

Ja, ich weiß, nur habe ich da irgendwie das dejavu-Erlebnis das immer wieder nach TwonavData/Data gefragt wird. Dieser Pfad auch mit weiteren Unterverzeichnissen existiert bzw. wurde angelegt, aber qland erkennt ihn nicht als solchen an.
Iegt es an dem / anstatt dem unter Windows üblichen \ ?

Ich habe das jetzt mal mit meinem TwoNav für Arme ausprobiert. Das ist ein USB Stick mit dem Verzeichnis TwoNavData/Data. Der funktioniert. Ich werde nach dem Pfad gefragt. Da gebe ich das Laufwerk vom USB Stick an. Und los geht es. Daten eingelesen. Neue Daten geschrieben. Und das Ganze auch wieder mit QMS eingelesen. Es funktioniert (Windows 7 64 Bit)

Zitat von papaluna

Wieso ? Wenn ich z.b 2 Tracks habe, welche ansonsten unterschiedliche Bereiche abdecken aber beide in der Nähe dieses Wirtshauses vorbeikommen, will ich die Info(Roadbookpunkt) doch in beiden Tracks haben.
Im CompeKontext hätte ich dann einen realen Wegpunkt der dazu benutzt würde, jeweils einen Trackpunkt in den beiden Tracks zu einem Roadbookpunkt zumachen.

Aktuell muss ein Wegpunkt immer mindestens 50m an einem Trackpunkt sein. Dann referenziert der Trackpunkt diesen Wegpunkt. Das gilt für alle Tracks und alle Wegpunkte in einem Projekt. Also eine komplette Kreuzkorelation innerhalb eines Projektes, mit der Bedingung < 50m. Wenn ich jetzt bei einem Wegpunkt sage, egal welcher Abstand, finde den nächsten Trackpunkt in jedem Track, dann ist das nicht immer das was man will. wenn z.B. in einem Projekt Tracks mehrere Kilometer auseinander liegen, dann macht das wenig Sinn.

Eine Alternative wäre, den Wegpunkt explizit einem Trackpunkt zuzuordnen. QMS speichert solche Relationen aber nicht, weil es eben versucht das maximale Ergebnis on-the-fly zu finden. Aus meiner Erfahrung heraus macht dieser Automatismus es eigentlich immer richtig. Aber sicherlich gibt es ein paar Fälle bei denen was anderes gewünscht wäre.

Zitat von papaluna

Wie wird dies denn derzeit behandelt?
Ich habe es bisher nicht überprüfen können, da alle importierten Tracks Track0 heißen und entsprechend exportiert werden. Das hat zur Folge das sie sich gegenseitig überschreiben und am Ende nur einer übrig bliebt. Zum umbennen habe ich bisher nichts im Wiki gefunden.

Jetzt verstehe ich nicht was Du machen willst.

Zitat von papaluna

In dem Fall bin ich der DAU. Ich wähle im sich öffnenden Explorerfenster nicht den Laufwerksbuchstaben z.b. der ANIMA-microSDcard sondern halt x:\Twonavdata\data selbst aus und werde fortan immer wieder darauf hingewiesen das doch gefälligst Twonavdata/Data da sein soll.
Ok. Nach der Auswahl eines Datenträgers der Twonavdata/Data enthält geht es dann und bei den darauf folgenden Hochladevorgängen wird nur nach dem Ausgabepfad innerhalb von Twonavdata/Data gefragt.

Das Konzept ist Müll. Deswegen wollte ich es ändern. Eben genau in das, was QMapShack heute macht. Dabei ist mir aufgefallen, dass die gesamte Datenstruktur von QLGT dem im Weg steht. Das war vor ungefähr einem Jahr. Und genau diese Sache war auch der Auslöser, nochmal von Vorne anzufangen.

Den Tracknamen ändert man in QLGT ähnlich wie in QMS im Track Edit Dialog. Dort ist eine Zeile mit dem Namen. Wenn man den ändert wird die Zeile rot. Drückt man return wird die Zeile grün und die Änderung wurde übernommen.

Zitat von papaluna

Roadbookpunkte: Name Vs.Beschreibung
Mir ist gerade noch aufgefallen das die Beschreibung des Wegpunktes als Name des Roadbookpunktes übernommen wird.
Wenn ich jedoch in CGPSLand drag&drop eine Wegpunktdatei auf den Track fallen lassen wird der Name und nicht die Beschreibung übernommen.
Über die Frage welche Variante besser ist, läßt sich sicherlich streiten.

Ich glaube die damalige Idee war so etwas wie Routing über das Roadbook zu realisieren. In der Beschreibung sollte die Fahranweisung stehen, die mit dem Punkt in TwoNav angezeigt wird. Das Konzept spukt zwar noch immer in meinem Kopf herum, aber ohne einen eigenen Offline Router macht das wenig Sinn. Insofern bin ich da leidenschaftslos. Wenn der Name die bessere Wahl ist, dann nehme ich in QMS den Namen.

Zitat von papaluna

Roadbookpunkte: Umlaute
nach dem Export aus Qlandkarte werden in CGSPL Umlaute im Namen/Beschreibung des Roadbookpunktes im Track nicht korrekt dargestellt.
Bei den entsprechenden zugehörigen Wegpunkten in der exportierten WPT-Datei allerdings schon.

Das ist seltsam. Beide Dateien sind UTF-8 kodiert. So wird es mir im Editor angezeigt. Kannst Du den Unterschied zu einer Datei von Compe herausfinden?

Zitat von papaluna

Also ich lade einen Track.
Im Reiter Tracks klicke ich den Track an = er ist ausgewählt.
RM-Taste>Kontextmenu>bearbeiten => im Kartenfesnter wird Mini-Profil sichtbar.
In der Trackliste mit den Daten zum Track(Name, Länge, Hm auf ab ...) ist weder Name noch sonst etwas auswählbar oder bearbeitbar
Links nur eine schmale Leiste mit der nicht änderbaren Trackfarbe und einem ewig grünen Haken.

Schau mal am unteren Kartenrand. Da sollte sich ein sog. Splitter Handle befinden. Die Maus ändert sich über diesem Handle. Dann die linke Maustaste drücken und nach oben ziehen. Du hast wahrscheinlich irgendwann mal aus Versehen den Bereich, in dem dieser Dialog eingeblendet wird soweit verkleinert. dass er ausgeblendet wurde.

Zitat von papaluna

Ja. Beide sind in UNIX / UTF-8 w/o BOM.

Also, wenn ich beim Track die Kodierung auf UTF-8 ändere geht es.

Hm, bis auf die Zeilenumbrüche ist die Datei ja schon UTF-8, oder?

Zitat von papaluna

Nachtrag:
Header des exportierten Tracks:

dort taucht eine K Zeile auf:

Afaik ist dies das Feld für die "Competition class". Gehört vermutlich zur AIR-Version und ist mir bisher nicht untergekommen, weder in Land noch Twonav.

Ja, das ist der Schlüssel, um das jeweilige Objekt eindeutig zu identifizieren. Ich war mal so frei und habe K genommen. Ob es einen besseren Buchstaben gibt?

Zitat von papaluna

Danke, das war es. Bewußt habe ich es nicht ausgeblendet.
Für solche Fälle wär ein Symbol in der Statusleiste evtl. hilfreich.

Das kommt immer ein wenig auf das Aussehen des OS an. Eigentlich sollte dieser Handle graphisch so gestaltet sein, dass man ihn sieht und damit auch weiß, dass sich gerade etwas versteckt. Bei Windows wird der nur sehr erfolgreich versteckt. Bei meinem Linux Theme sieht man sofort dass dort was ist. Siehe Anhang.

Zitat von papaluna

Jedenfalls sollte es keiner sein der gebraucht werden könnte)auch wenn es eher unwahrscheinlich ist.
http://www.twonav-gps.de/down/compegps_formats_uk_v103.pdf

Ok werde ich ändern.