Beiträge von beedaddy

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.

Danke, dann lasse ich das Vorhaben wohl besser sein.

Nein, es geht mir schon um eine Rasterkarte. Ideal wäre eine Wanderkarte 1:25.000. Oder eben die Kartengrundlage DTK25.

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…

Zitat von kiozen

Kannst Du mal den for-loop austauschen und testen ob es daran liegt? Wenn ja bitte ein Ticket aufmachen.

Alles klar, mach ich…

Zitat von kiozen

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:

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

Sort OSM Data
=============

Sorting NodesCannot open file '/home/martin/Dokumente/QMapShack/Routino/nodesx.0x5556e21ad2a0.tmp' for reading [No such file or directory].

!!! 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:

/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:

Sort OSM Data
=============

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:

/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 bin vor einiger Zeit vom Oregon auf das GPSMAP 66 umgestiegen. Grund war auch die Regenuntauglichkeit des Oregon.

Zitat von Tobias

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?

Vielen Dank für das neue Forum! Es ist ein bisschen ungewohnt, dass die neuen Beiträge in Threads oben stehen, und nicht unten. Das ist sicherlich Geschmackssache. Diese Sortierung lässt sich nicht zufällig auf Nutzerebene einstellen?

Zitat von trailsurfer

Wenn Du den Cursor auf der Karte siehst, dann hast Du zuvor mit den Wipptasten den Cursor auf der Karte bewegt. Das bleibt dann so "eingefroren" stehen. Die Anzeige der Position wandert bei Fortsetzung der Tour noch aus der Karte raus.
Einmal "Quit" drücken und alles ist gut.

Wipptasten, das sind die Pfeiltasten

Ich bin mir sicher, dass kein Cursor zu sehen war. Tatsächlich habe ich vorher in der Karte gescrollt. Nach rechts. Und dabei ist mir aufgefallen, dass nach vielleicht einer Bildschirmbreite der "neue" Bereich nicht mehr gezeichnet wurde, also weiß blieb. Hab mir nicht viel dabei gedacht, ging ins Hauptmenü und wieder zurück und alles sah gut aus. Anschließend dann die Fahrt mit dem oben beschriebenen Problem. Vielleicht bleibt es ja eine einmalige Sache, wollte aber mal nachfragen. Wenn das mal irgendwo in der Pampa passiert und man es nicht gleich bemerkt, könnte es ärgerlich werden.

Kürzlich habe ich mir ein GPSMAP 66s zugelegt und muss sagen, dass mir die Tastenbedienung sehr zusagt. Ich komme vom Oregon, wo der Touchscreen doch immer etwas hakelig war. Das aber nur nebenbei. Nach etwas Einarbeitung und Einrichtung hatte ich das Gerät heute erstmals im Einsatz, um ein, zwei Geocaches zu loggen. Ich hatte es am Fahrrad montiert und erstmal war alles ok. Nach dem ersten Cache, also auf dem Weg zum zweiten, ist mir jedoch aufgefallen, dass zwar die Distanz und der kleine Kompass oben normal angezeigt wurden. Die Karte jedoch war eingefroren, d. h. Cursor und Kartenbild haben sich trotz Fahrt nicht mehr verändert. Ich ging dann kurz ins Hauptmenü und beim Zurückwechseln auf die Karte war diese dann wieder "aktuell". Beim Weiterfahren hingegen trat das Problem wieder auf. Später, beim Ausschalten ist mir aufgefallen, dass es erst sehr zeitverzögert Heruntergefahren ist. Irgendwas scheint da also gehangen zu haben.

Nun würde mich interessieren, ob andere etwas Ähnliches beobachtet haben. Auf gpsrchive.com habe ich mal geschaut, konnte aber nichts Entsprechendes finden. Bei der Karte handelt es sich übrigens um die Topo Deutschland v9 Pro. Die Firmware hatte ich gleich zu Beginn aktualisiert (v 3.10).

Ich spiele gerade etwas mit der Topo Deutschland v9 Pro Karte (auf dem Oregon 700) herum. Dabei ist mir noch nicht ganz klar was genau die Einstellung "Automatisch" bei "Plastische Karte" bewirkt. Ich vermute, dass hier je nach Zoom-Level die Schummerung ein- bzw. ausgeblendet werden soll. Tatsächlich ist sie aber bei jedem Zoom-Level ausgeblendet. Ich kann sie nur sehen, wenn ich "Zeige wenn verfügbar" auswähle. Habe ich da was falsch verstanden oder hängt das noch von einer anderen Einstellung, die ich vielleicht übersehen habe, ab? Was also soll "Automatisch" genau bewirken?

Vielen Dank und Grüße
Martin

Über die Garmin Connect Webseite kannst du z. B. eine Strecke anzeigen und dann oben rechts über das Zahnrad-Symbol exportieren (fit (original)/tcx/gpx). Und wenn es so wie bei der FR45 ist, kannst du auch einfach über den Dateimanager die .fit Dateien unter GARMIN\Activity kopieren.