Beiträge von beedaddy

Garmin GPSMAP 65s, TwoNav Cross, Trail2, Aventura2 im Test

Wir schlagen sich die neuen Outdoor-Navis mit Mulit-Empfang (GPS, Glonass, Galileo) in unserem Vergleichstest? Unser Test legt den Schwerpunkt auf die Hardware (Höhenmesser, Standortbestimmung, Akkulaufzeit, Displayhelligkeit uvm.) zeigt aber auch einen Übersicht über die Karten-, Routen- und Navigationsoptionen. Zum Vergleichstest...

    Was mich bei der Explore-Synchronisation nervt, ist, dass es mir die Waypoints zu einem Geocaching Pocket Query (also Parkplätze, Multi-Stationen usw.) alle in die Cloud synchronisiert.


    Ich habe eine Sammlung eingerichtet, die so heißt wie das Gerät ("GPSMAP 66s"). Zusätzlich gibt es noch Sammlungen, die ich bei Bedarf synchronisieren will, also z. B. "Geplante Wanderungen" oder so. Sobald ich nun ein PQ bzw. die zugehörige -wps.gpx Datei auf das Gerät spiele, werden wie gesagt diese Waypoints (und das sind bei einem PQ … viele) synchronisiert.


    Mir ist schon klar, dass sich das ja eigentlich wie erwartet verhält. Aber dass diese hunderte von Waypoints die Sammlung zumüllen finde ich schon etwas suboptimal.


    Kann ich das irgendwie verhindern, ohne die komplette Synchronisation abzuschalten? Vielleicht habe ich ja eine Option übersehen oder mache etwas falsch?

    Ich habe mit der 4.80 ein Problem mit dem MTP Modus. Anstatt dass das 66s gemountet wird, schaltet sich einfach ab, nachdem es ein paar Sekunden lang das USB-Symbol angezeigt hat. Bislang, auf jeden Fall vor 4.70, hatte ich da keine Probleme. Ich arbeite mit Linux, aber die virtuelle Windowsmaschine ändert leider auch nichts. Der Spanner Modus hingegen funktioniert. Hat das Phänomen sonst noch jemand?

    ok, da fehlt wohl wirklich ein Update. Du kannst als Workaround einfach mal die Datenbank zu und auf klappen. Das geht schneller als ein Neustart.

    Ich habs mal ausprobiert, es scheint wirklich nur ein fehlendes dbfolder->update(); in CGisListDB::slotImport() zu sein. In dem Fall trau ich mir gerade noch zu, ein Issue und PR zu erstellen. Soll ich?

    Ich habe die 4.70 seit einigen Tagen installiert. Allerdings hängt sich das Gerät komplett auf (bootet nicht mehr), sobald bei Live Geocaching ein Pocket Query synchronisiert ist. Es hilft dann nur noch der Forced USB Mode und Löschen des SQL-Verzeichnisses.

    Wie ist das eigentlich… Ich zucke immer zusammen, wenn bei Geräten der Akku fest verbaut ist. Nicht weil ich Angst hätte, die Energie würde für eine Wanderung nicht reichen. Aber wenn der Akku durch Alterung schlapp macht, kann man das Gerät doch in die Tonne werfen. Oder sind die Akkus so langlebig, dass das kein Problem ist? Oder kann man diese im Falle eines Falles (einigermaßen günstig) austauschen lassen?

    Nextcloud (oder welcher Dienst auch immer) versioniert die Dateien ja auch, also hat man auch eine Art Backup. Passiert ist bei mir bisher nie was. Im Zweifel könntest du dann auch WLAN erst mal abschalten, so dass erst synchronisiert wird, wenn du wieder online bist.

    Bzgl. MySQL kann ich leider nicht helfen. Ich verwende auch auf verschiedenen Rechnern QMapShack (jedoch alle mit Linux) und habe die SQLite-Datenbank einfach in den Nextcloud-Ordner verschoben. Da muss man dann halt aufpassen, dass auch immer ordentlich synchronisiert wird und dass man nicht gleichzeitig die Datenbank mehrfach öffnet. Ist mir aber auch noch nie passiert und so arbeite ich nun schon eine ganze Weile. Nur so als Idee. Als mögliche Alternative.

    Ich würde gerne – rein interessehalber – mal mit Rasterkarten (QMapShack / Garmin GPSMAP 66s) arbeiten. Wenn ich das richtig verstanden habe, könnte ich theoretisch eine Wanderkarte einscannen (lassen) und dann z. B. mit QMapTool georeferenzieren. Aber gibt es auch andere Möglichkeiten bzw. Quellen von digitalen topografischen Karten (für BaWü)? Das LGL-BW verkauft glaube ich DTK25 Karten, die sind aber wohl weniger für den privaten Anwender gedacht (und sehr teuer). Gibt es vielleicht noch was anderes (Stichwort "Open Data")?

    Mit der loop-Änderung siehts gut aus.


    Es war ein bisschen ein Act, QMapShack unter Qt 5.15 compiliert zu bekommen. Mit ein paar #include <QPainterPath> hier und da hat's dann funktioniert.


    Soll ich einen PR erstellen, mit den neuen #includes? Nicht dass das was bei Qt < 5.15 kaputt macht…

    Ist deine Qt Version zufällig 5.12? Die scheint recht buggy zu sein.

    Bei Arch Linux bin ich auf Gedeih und Verderb aktuell: Qt 5.15.0


    Mir kam auch schon der Gedanke, ob das vielleicht an Wayland liegen könnte, wobei die Qt-Programme eigentlich den X11-Layer verwenden. Das schau ich mir nochmal an, auch wenns unwahrscheinlich klingt… EDIT: War ein doofer Gedanke und kann ausgeschlossen werden.


    (Evtl. wäre auch eine Fehlermeldung sinnvoll, wenn QMapShack denkt, dass die Liste leer ist?)

    Das hier gibt QMapShack aus:

    Code
    1. /usr/bin/planetsplitter --dir=/home/martin/Dokumente/QMapShack/Routino --prefix=DE --tagging=/usr/share/routino/tagging.xml --process-only
    2. Sort OSM Data
    3. =============
    4. Sorting NodesCannot open file '/home/martin/Dokumente/QMapShack/Routino/nodesx.0x5556e21ad2a0.tmp' for reading [No such file or directory].
    5. !!! fehlgeschlagen !!!

    Und hier noch ein Screenshot:

    Hmm, also wenn ich zuerst auf der Kommandozeile folgendes ausführe (und anschließend die Schritte laut Doku in QMapShack), dann geht es:

    Code
    1. /usr/bin/planetsplitter --dir=/home/martin/Dokumente/QMapShack/Routino --prefix=DE --tagging=/usr/share/routino/tagging.xml --parse-only germany-latest.osm.pbf

    Als würde dieser erste Schritt von QMapShack nicht ausgeführt werden. Was ich aber nicht verstehe, denn früher hatte das ja geklappt. :/


    Ich suche also noch nach der Ursache, was ich anders/falsch mache. Aber immerhin hat es nun letztendlich funktioniert.

    Erst mal hoffe ich, dass es ok ist, wenn ich hier rein poste, denn genau genommen betrifft es nicht QMapShack, sondern Routino/planetsplitter (also auch auf Kommandozeile)…


    Nach längerer Zeit wollte ich mal wieder die Routingdaten aktualisieren. Also habe ich mir die germany-latest.osm.pbf Datei heruntergeladen (MD5-Hash ist korrekt) und habe versucht, die Routino Datenbank zu erstellen.


    Ich hatte das ja schon das ein oder andere mal ohne Probleme gemacht, aber diesmal erhalte ich – umgehend – die Fehlermeldung:

    Code
    1. Sort OSM Data
    2. =============
    3. Sorting NodesCannot open file '/home/martin/Dokumente/QMapShack/Routino/nodesx.0x5627afa662a0.tmp' for reading [No such file or directory].

    Das Kommando, das ausgeführt wurde, ist:

    Code
    1. /usr/bin/planetsplitter --dir=/home/martin/Dokumente/QMapShack/Routino --prefix=DE --tagging=/usr/share/routino/tagging.xml --process-only


    Ich zweifle gerade an mir selbst, wüsste aber nicht, was ich falsch gemacht haben könnte. Hat vielleicht sonst noch jemand Probleme damit? Ich arbeite hier mit Arch Linux und habe QMapShack 1.15.0 sowie Routino 3.3.1 installiert.


    Danke und Gruß

    Martin

    ich werde da nächste Woche insgesamt mal etwas Struktur reinbringen...

    ABER: die Struktur ist 1:1 so wie im alten Forum, da hat sich absolut nichts geändert.

    Apropos Struktur... Im Garmin-Bereich gibt es ja zwei Foren: "eTrex Serie 10, 20, 30" und "eTrex und Geko Serie". Da war mir noch nie so recht der Unterschied klar. Beispielsweise finden sich in beiden Beiträge zum eTrex Touch 35.

    Ich habe mir die fit-Dateien mal genauer angesehen (und nach csv konvertiert). Ein Unterschied, der mir aufgefallen ist: Die FR45 gibt die Höhe sowohl mit altitude als auch enhanced_altitude an. Das GPSMAP 66 hingegen gibt die Höhe nur als enhanced_altitude an.


    (Wenn das wieder möglich ist, erstelle ich wohl mal einen Bug Report für QMapShack. Momentan lässt mich BitBucket leider nicht auf die Issues-Seite.)

    Bisher hab ich immer grundsätzlich GPX Dateien in QMapShack importiert. Nun wollte ich aber interessehalber mal sehen, ob auch fit Dateien funktionieren. Also habe ich eine Aktivität vom GPSMAP 66s importiert. Dabei ist mir aufgefallen, dass die Höhe konstant 12607m beträgt. Wenn ich die fit Datei jedoch zunächst mit gpsbabel in gpx konvertiere und dann erst in QMapShack lade, wird ein augenscheinlich normaler Höhenverlauf angezeigt. Die Höhendaten sind also in der fit Datei schon auch da. (Siehe Screenshots unten)


    Dann habe ich noch spaßeshalber eine fit Datei von der Garmin Forerunner 45 in QMapShack geladen. Für mich überraschend: Hier wird die Höhe anscheinend korrekt eingelesen/angezeigt.


    Vielleicht schreiben das GPSMAP 66 und die Forerunner unterschiedliche fit-Versionen?

    Kann das Höhen-Problem jemand vielleicht bestätigen? Tritt das nur mit dem neuen GPSMAP 66 auf?