Beiträge von kiozen
Garmin fenix 7X und epix Gen 2 im Test
-
-
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.
-
Ok, Ok.
Leider beschränkt einen dies aber z.B. bei Twonav auf nur eine Anzeigezeile(innerhalb der Eigenschaften eines Wegpunktes, auf der Karte sieht man mehr). Bei den Garmingeräten ist die Anzeigemöglichkeit doch auch arg beschränkt, soweit ich mich erinnere. Aber da gibt es ja nicht mal die Möglichkeit bei Bedarf solche Daten abzuhängen.n.Naja, bei Garmin kann man schon ein paar Zeilen anhängen. Ich weiß jetzt nicht das Limit, aber es ist mehr als wie bei den alten Geräten mit nur 32 Zeichen. So lange man keine epischen Gedichte schreibt...
Aber ich hätte jetzt gedacht, dass man bei TwoNav soviel Text angeben kann wie man mag. Ich kann es jetzt nicht ausprobieren, weil mein Gerät gerade verliehen ist.
Das betrifft doch aber nur die wenigen Nutzer die sich die parallele Anwendung verschiedener Applikationen und Geräte leisten(können oder wollen/müssen).
Die Anderen dürften es aber vorziehen nur 1 Gerät und 1 Applikation zu verwenden, soweit sich das machen läßt und wollen dabei das Maximum des möglichen herauszuholen.Es gibt sicherlich solche und solche. Mir persönlich graut immer vor dem vendor-lock-in. Deswegen halte ich mich eher an das Maximum an Portabilität. Wenn man lieber das Maximum an Funktion ausschöpft, dann führt wohl kein Weg an der Herstellersoftware vorbei.
Ich hätte es ja auch lieber, GPX würde sich mal endlich sinnvoll weiterentwickeln und die Hersteller halten sich daran. Aber der Zug ist wohl abgefahren
Bleibt nur der Kompromiss. -
Such mal nach EUDEM. Das sind die Daten, die ich im Screenshot benutzt habe. So doll sind die zwar auch nicht, aber dafür für ganz Europa. Ich habe die von einem japanischen Server. Die hier könnten auch ok sein:
-
-
HI Oliver, hab heute endlich meine erste MTB Tour unternehmen können und wollte dann den aufgezeichneten Track in QMS auswerten.
Aber irgendwie scheitere ich daran.
Hab den Track „Datei - Gis Daten laden“ in QMS eingefügt und dann auf bearbeiten gegangen. Jetzt erst das Schloss geöffnet um ein Bearbeiten überhaupt möglich zu machen.
Leider war schon zu sehen das da am Höhenprofil was nicht stimmt.Also ich sehe, dass am Anfang der Track bei 114m anfängt, um dann auf 250m anzusteigen. Sprich die ersten paar Punkte sind Käse und ich würde sie entfernen. Wie Du auf -18430 kommst verstehe ich jetzt nicht.
-
Ich denke das dies durchaus sinnvoll ist, da es machmal einfacher und schneller geht eben mal eine Text-Datei mit den gewünschten Infos zu erstellen.Naja, sinnvoll. Das ist so ein Thema bei Datenformaten. Sinnvoll ist ein Format, bei dem ein Objekt komplett als eine Datei gespeichert werden kann. Insofern taugen die ganzen Formate nicht, um irgendeine weitere Datei anzuhängen.
Und so gesehen fügt man reinen Text in das Kommentar bzw. Beschreibungsfeld ein. Dann wird dieser Text sowohl in GPX als auch in TRK/WPT mit der Datei abgespeichert. Das wäre aus meiner Sicht sinnvoll.
Wenn es portabel sein soll, sowohl zwischen den Geräten als auch zwischen Applikationen, dann kann man ohne Verlust eh nur das verwenden was in GPX definiert wurde. Und genau diesen kleinsten gemeinsamen Nenner versucht meine Software immer zu realisieren. Es bringt ja nichts tolle Sachen anzuhängen, wenn die nur auf einem speziellen Gerät zu sehen sind. Und nur mit einer Applikation und dort auch nur wenn man ja nichts verschiebt.
Die Krücke mit den Bildern habe ich eigentlich nur wegen den Spoilerbildern für Caches drinnen. Das ist irgendwie so ein must-be-on-the-box. Birgt aber auch genug Probleme.
Schau ich mir jetzt mal an.
Falls es noch keine Einstellung für den Entfernungs-Treshold zum Track gibt, wäre dies sicher sinnvoll.Nö, gibt es nicht. Habe ich aber auch nie vermisst.
Ich bin immer ein Fan von wenig Optionen, dafür vernünftigen Grundeinstellungen.
BTW.
Anzeige von Garminkarten:
das geht ja sehr gut. Allerdings war es mit Qland bequemer da ich dort nicht erst gmapsupp-Dateien erzeugen mußte(welche der Twonav-Nutzer ja eigentlich nicht braucht.)Sehe es positiv. Du kannst den ganzen Dateiwirrwarr jetzt auf eine Datei reduzieren und den Rest entsorgen. Eigentlich war diese Dateisammlung mit tdb, und was weiß ich, doch nur umständlich und Quelle endloser Benutzerprobleme. Jetzt gilt "eine Karte eine Datei" und QMS findet alles selbständig. Ich denke die meisten Benutzer sind froh.
-
Weglassen der GPX:
im Prinzip sehe ich das ja auch so, allerdings gibt es vermutlich Nutzer die zwar die Vorteile eines Roadbooktracks nutzen wollen, ihre Aufzeichnung aber lieber als GPX haben wollen. Zumindest hatte ich gelegentlich den Eindruck.Nur das halt eine GPX Datei kein Roadbook machen kann. Oder bin ich da nicht auf dem neuesten Stand?
Verknüpfte Dateien:
den Ordner habe ich auf die Schnelle nicht entdeckt.
Wie dem auch sei.
Ich verwende z.B. neben Bildern genauso Txt-Dateien die werden derzeit nicht berücksichtigtEinen eigenen Ordner macht QMS nicht auf. Die Bilder werden nur im Unterverzeichnis des Projektes abgespeichert. Und etwas anderes als Bilder geht im Moment auch nicht. Das könnte ich aber mal auf die Todo Liste setzen.
Roadbooks:
muss ich erst mal probieren wie das in Qland geht.
In CGPSL kann ich z.B. mit drag&drop einer WPT-Datei auf einen Track in Verbindung mit der "distance to assimilate waypoint" autom. Wegpunkte integrieren lassen.
Als zusätzlichen Funktionen könnte ich mir z.B. das automatische assimilieren während des Zeichnungsvorganges vorstellen oder auch einen Filter für die zu assimilierenden Wegpunkttypen, sofern z.B. unterschiedliche in einer Datei bevorratet werden.QLGT ordnet alle Wegpunkte die in der Nähe eines Tracks sind dem Track als Etappenpunkt zu. Diese Wegpunkte werden dann in der trk Datei mit abgespeichert. Und auch nochmal als wpt, da TwoNav die Wegpunkte die mit dem Track verknüpft sind verschiebt. Das ist ein wenig doof bei einem Cache. Deswegen doppelt.
-
Mir ist gerade noch aufgefallen das ich zwar den Entsperr-Dialog für die per default schreibgeschützen TRK nach Klick auf das Schlosssymbol bekomme, wenn ich dort aber JA=entsperren drücke, bleibt der trk-Track weiterhin gesperrt.
Ich habe jetzt mal den Dialog weggelassen. Weil der ist an der Stelle wirklich überflüssig.
-
Bezüglich TwoNav ist es tatsächlich ein wenig schwierig, weil ja recht viel Freiheit besteht. Und QMapShack den Anspruch hat alles in Projekten zu organisieren. Und CompeLand bestimmt auch seine Sonderlocken hat
Was macht QMapShack?
1) Es schaut in TwoNavData/Data/ nach gpx Dateien und lädt diese als Projekt.
2) Es schaut in TwoNavData/Data/ nach weiteren Verzeichnissen und lädt den Inhalt in Form eines Projektes
2.1) Dazu sucht es zuerst alle trk Dateien.
2.2) Danach alle wpt Dateien.Zusätzlich legt QMapShack in einem Verzeichnis eine key Datei ab, in der der Projektschlüssel steht. Und Bilder, die mit Wegpunkten verknüpft sind. gpx Dateien werden aus zwei Gründen ignoriert:
1) Eine gpx Datei wird immer als Projekt gesehen. Ein Projekt im Prokekt... hm, das lassen wir mal lieber bleiben
2) Möchte man bei TwoNav den vollen Funktionsumfang bei Tracks haben, sprich ein Roadbook[1], dann muss man leider sowieso mit einer trk Datei anfange.Soweit was QMapShack macht. In wie weit das mit CompeLand bzw der jeweiligen individuellen Denke zusammen passt, wäre jetzt interessant. Vielleicht gibt es ja noch mehr gemeinsame Punkte, die sich sehr leicht in die Struktur von QMapShack einbauen lassen.
Mir ist gerade noch aufgefallen das ich zwar den Entsperr-Dialog für die per default schreibgeschützen TRK nach Klick auf das Schlosssymbol bekomme, wenn ich dort aber JA=entsperren drücke, bleibt der trk-Track weiterhin gesperrt.
Das ist Absicht. Alle Elemente in QMapShack sind durch einen eindeutigen Schlüssel identifiziert. So ein Projekt gibt es ja auf dem Arbeitsplatz und auf den Geräten. Mehrzahl! Würde man es jetzt erlauben auf den Geräten die Elemente zu verändern, dann wird es richtig aufwändig, das alles synchron zu halten. Man bräuchte quasi ein Repository wie es in der Softwareentwicklung verwendet wird. Zudem überfordern solche Repositories die meisten Benutzer in der Bedienung. Deswegen gibt es nur eine Richtung Arbeitsplatz -> Gerät. Wenn man was ändern will, ändert man das auf dem Arbeitsplatz, und synchronisiert dann alle angeschlossenen Geräte mit "Aktualisiere das Projekt auf allen Geräten".
Nicht so brennend wichtig, aber dennoch wäre es benutzerfreundlicher wenn es eine andere Möglichleit zum refresh des Datenfenster gäbe wie ein Neustart (oder entfernen+ wiedereinhängen des Datenträgers)Das macht aber auch nur Sinn wenn man zugleich noch mit einer anderen Software was ändert. Was immer ein wenig kritisch ist. Bei TwoNav ist es nicht so schlimm wie bei Garmin, weil im Moment noch alles in einem Verzeichnis steht. Das ist bei Garmin leider nicht so. Generell gilt aber, was mit QMapShack auf das Gerät geschoben wurde, löscht man auch besser mit QMapShack. Weil dann sicher gestellt ist, das alles wieder gelöscht wird, und nicht irgendwo etwas übrig bleibt.
[1] Roadbook wird noch nicht in QMapShack unterstützt. Kommt aber wahrscheinlich in ähnlicher Form wie bei QLandkarte.
-
-
Wenn man mit so einem Beutelchen glücklich wird. Magellan hatte sich das so vorgestellt. Ich fand es mega unpraktisch.
Von allen Halterungen ist der Karabiner mit der Plastikschiene mir der Liebste. Simple, robust und zuverlässig. Das Gerät schlackert wenig. Lässt sich aber genug bewegen, um während dem Laufen auf das Display zu sehen.
Garmins Kletthalterung für das eTrex ist auch halbwegs praktisch. Allerdings verdreht sich bei meiner Handhabung immer die Fangleine. Bzw die Fangleine verfängt sich beim Absteigen gerne im Griff vom Stock. Dann fliegt das Gerät. Durch die Leine wird es zwar gehalten und es passiert in der Regel nichts. Aber lästig ist das schon.
-
So mal aus der Praxis gesprochen: Bei meinen Handschuhen ist mir die Qualität und Tauglichkeit für Bergtouren wichtiger, als die Bedienbarkeit eines Touchscreens. Und mein GPS hängt griffbereit an meiner Schulter. Dazu muss ich es nicht abnehmen. Das Display ist aus nahezu jedem Winkel gut ablesbar und ich kann mit einfachen Tastendruck präzise zoomen, bzw die Seiten wechseln. Also nix mit Handschuhen lange in der Jackentasche kramen. Zum Schluss schneit es da noch rein oder irgendwas Wichtiges fällt raus.
Es ist ja nicht so, dass ich nicht genügend Geräte mit Touchscreen besitze. Im Gegenteil. Ich habe 3 Geräte mit und nur eines ohne. Und deswegen weiß ich einfach aus praktischer Erfahrung, dass es Situationen gibt in denen ein Touchscreen nicht so doll ist. Ob diese Situationen für einen selber überhaupt zutreffen und damit relevant sein können, das muss jeder selber wissen.
-
Das ist ein generelles Problem von kapazitiven Touchscreens. Und nicht von einem bestimmten Gerät. Wenn einem das nicht passt, dann nimmt man ein Gerät mit Tasten. Ich werde auch nach mehr als 9 Jahren mit Touchscreengeräten nicht warm. Im Sommer, bei schönem Wetter geht es ja noch. Wobei ich dann auch nicht gerne mit verschwitzten und dreckigen Fingern auf dem Bildschirm rumsaue. Und bei Wind, Schnee und Kälte lass ich meine Hände lieber in den Handschuhen. Aber das muss jeder selber wissen, was ihm gefällt.
-
Da passiert nichts. In die Dateien wird beim Aktivieren für dein Gerät einmal ein Zertifikat eingefügt, dass aus Informationen über dein Gerät und der Datei geschaffen wird. Damit ist die Datei nur noch auf deinem Gerät und keinem anderen zu benutzen.
-
-
Hallo Gert
In QMS öffnet man keine Karten als Datei. Man legt diese in einem Verzeichnis ab und dann werden sie automatisch gelistet. Siehe auch:
https://bitbucket.org/maproom/…ck/wiki/DocGettingStarted
und
https://bitbucket.org/maproom/qmapshack/wiki/DocBasicsMapDem
Nun werden allerdings die *xml Dateien als Endung, bzw Format nicht unterstützt. Wenn aber GDAL diese Dateien unterstützt (das weiß ich jetzt nicht für Windows), dann kann man auch die *xml Datei in eine *vrt Datei verpacken. Und dann mag auch QMS.
-
Die anfänglichen schweren Probleme im Empfang mit den Oregons sind weg. Jetzt kann man nur noch über die Feinheiten diskutieren. Und da fehlt wohl überall die Möglichkeit zu einem quantitativen Vergleich.
Wenn man mehrere verschiedene Geräte mit auf Tour nimmt, dann kann man einen gewissen qualitativen Vergleich machen. Je mehr solcher Touren man zum Vergleich hat, desto besser fällt der aus. Ich sammle deswegen immer alle Tracks ein.
Von den neuen Oregons habe ich nur wenige Tracks. z.b. vom letzten Sommer in den Südalpen. Im Vergleich mit einem 62s wich das Oregon bei schlechten Empfangsbedingungen früher und weiter von der Position ab als das 62er. Wobei die Abweichung bei beiden Geräten jenseits von Gut und Böse war. Ob es dann 100m oder 300m sind, ist egal. Das frühere Abweichen , bzw das spätere Zurückspringen zur realen Position ist schon eher zu bewerten.
Bei anderen Tracks aus dem Bayerischen Wald, wo die Empfangsbedingungen nicht gar so extrem sind, liegt das Oregon, solange es guten Empfang hat, sehr präzise auf dem Weg und wackelt sehr wenig im Vergleich. Wird der Empfang schlechter nimmt die Abweichung und das Wackeln zu. Wieder im Vergleich zum 62er, welches länger ruhig bleibt.
Vorsichtig zusammengefasst: Unter normalen Bedingungen ist der Empfang und die daraus berechnete Position der neuen Oregons sehr gut. Der Empfänger wird aber bei schlechten Bedingungen, verglichen zu einem 62s mit einem älteren Chipsätz, früher nervös und fängt auch früher mit einem starken Versatz an. Wobei bei solchen Bedingungen alle Geräte irgendwann aufgeben. Diese Aussagen stützen sich auf nur wenige Touren. Um sich richtig sicher zu sein, bräuchte es mehr.
-
-
Habe ich mich auch schon gefragt ob das geht. Eine Datei habe ich aktuell nicht zur Hand. Aber hier wird die Sache beschrieben:
http://www.gdal.org/frmt_wms.html
Man muss dann noch eine VRT Datei dazu erstellen.
