Beiträge von kiozen
Garmin fenix 7X und epix Gen 2 im Test
-
-
Papaluna: Dann werde ich erst mal daraus eine runderer Sache machen.
@joshl: Gute Frage... ich habe gerade die V 1.0.1 auf Windows 7 64 Bit installiert. Ich bekomme alle Kontextmenüs über die rechte Maustaste angezeigt. Hast Du eine spezielle Maus, mit der Qt5 vielleicht nicht klarkommt?
-
Zitat
Würde es evtl. Sinn machen eine Signatur ins Kommentarfeld des Tracks zu schreiben?
Da besteht zwar auch das Risiko das ein Nutzer es versehentlich(oder bewußt) löscht, CGPSL/Twonav selbst speichert dieses Feld aber mit ab.
Das führt nur zu endlosen Anfragen, warum, weshalb, wieso. Das lasse ich lieber bleiben.
Zitat
QMS Version 1.0.1 :
Soll das jetzt heißen das Roadbookpunkte im Track erzeugt werden ?Nein, 1.0.1 ist nur ein Bugfix release. Neue Features wie das Roadbook kommen erst mit 1.1.x. Das wird so 1-2 Wochen noch dauern. Ich kann aber Helmut bitten, dass er ein Binary für Dich zum Testen macht.
Das mit der Y Achse ist bekannt. Aber irgendwann ist halt kein Platz mehr für alles. Jetzt könnte man die Beschriftung einfach weglassen. Das ist aber auch nicht schön.
-
Da müssen noch nicht mal Jahre dazwischen liegen
Aber, ja, so wird es sein. Solange es bei den Herstellern nicht zur guten Praxis wird, ein Feld für so einen textuellen Schlüssel bereitzustellen, wird es beim Datenaustausch zwischen den einzelnen Programmen immer zum Chaos kommen.Aber das ist praktisch nicht so schlimm, weil der Track, nachdem Du ihn durch Compe's Software genudelt hast, eh nicht mehr das ist, was QMS darunter versteht. Alleine durch den Export aus QMS heraus wurde die Historie und alle ausgeblendeten Wegpunkte entfernt. Der Track ist somit nur noch ein Schatten seiner selbst und hat mit dem, der in der Datenbank liegt, wenig zu tun.
Um solche Inkompatibilitäten wird man wohl auch nie herumkommen, solange es keinen Konsens gibt, was so ein Datenformat alles abspeichern soll. GPX greift bei weitem nicht weit genug. Und die Extension Tags sind keine Lösung sondern eher das Problem. Naja und Compes Format ist komplett proprietär. Trägt also zu einem Konsens gar nicht bei.
Es ist eigentlich schade, dass Topographix nicht zum richtigen Zeitpunkt etwas mehr aus seinem Format gemacht hat. Dann hätten die Hersteller wahrscheinlich, ohne es richtig zu merken, einen Konsens gefunden.
-
-
-
-
-
-
-
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.
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.pdfOk werde ich ändern.
-
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.
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?
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?
-
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.
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.
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?
-
Lithium Batterie ist nicht gleich Lithium Batterie. Da gibt es Unterschiede in der Kapazität und natürlich im Preis. Das wird aber in der Regel angegeben. Lithium Batterien haben ihre Vorteile. Hauptsächlich im Winter. Auf der anderen Seite sind sie eine ziemliche Umwelt- und Ressourcensünde. Sollte man vielleicht bedenken.
-
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.
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.
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.
-
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)
-
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.
-
Alles anzeigen
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-FeldDa 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.
Spricht eigentlich etwas gegen ein drag&drop zur Verlinkung?Könnte man bestimmt auch machen. Aber ich bin bei solchen Sachen eher der Dateidialogfan.
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.
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 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.
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.
-
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.
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.
Ist gefixed.
