Du könntest auch als Alternative QMapShack verwenden und dort die Karten von Google verwenden.
Zusammen mit Höhendaten lassen sich damit schöne Tourendokumentationen anfertigen:
Du könntest auch als Alternative QMapShack verwenden und dort die Karten von Google verwenden.
Zusammen mit Höhendaten lassen sich damit schöne Tourendokumentationen anfertigen:
Ich verwalte alle Wegpunkte mit Qmapshack. Sorry wenn dass nicht ersichtlich war.
Doch war es.
Daten, die aus der Datenbank in den Arbeitsplatz geladen werden, können nur aus dem Arbeitsplatz entfernt werden. In der Datenbank bleiben sie erhalten. Wenn Du Daten aus einem Ordner in der Datenbank entfernen möchtest, musst Du diese in der Datenbankansicht markieren und dann entfernen (rechte Maus-> Menü). Dabei wird nur der Link zu dem Ordner aufgelöst. Du kannst auch den ganzen Ordner entfernen.
Das Vorgehen ist also:
* Ordner mit den zig Wegpunkten in den Arbeitsplatz laden.
* Länderordner anlegen und die entsprechenden Wegpunkte dorthin kopieren.
* Speichern nicht vergessen! Dabei die Version aus der Datenbank nehmen. Die stimmt ja schon und es ist ein Schreibvorgang weniger.
* Jetzt den großen Ordner mit allen Punkten, wenn gewünscht, löschen.
Das kann man so oft machen wie man will. Jeder Wegpunkt wird nur einmal gespeichert. Es sei denn Du wählst beim Speichern den Klon. Dann entsteht eine echte Kopie. Sollte bei allem Spielen ein Wegpunkt in keinem Ordner mehr referenziert werden, landet er in "Verloren & Gefunden" Erst wenn er dort gelöscht wird ist er auch wirklich unwiderruflich weg.
Die Aufzeichnung nach Distanz- oder Zeitintervall ist immer suboptimal (abgeschnittene Kurven etc.). Garmin hat einen so schönen und brauchbaren automatischen Modus. Den darf man auch gerne mit hoher Aufzeichnungsdichte verwenden.
Es gibt mehrere Resets:
In der Regel will man letzteres, wenn man nicht gerade eine Mehrtagestour Im Tripcomputer erfassen möchte.
Du hast halt vorher immer den Tripcomputer zurückgesetzt und es bei der Aufzeichnung vergessen. Kommt schon mal vor.
In welchen Fällen schreibt der Empfänger die statistischen Daten (TrackStatsExtension) in das gpx-file ?
Immer dann, wenn der Track explizit gespeichert wird. Nur dann könnte der Benutzer auf die irre Idee kommen, dass Tripcomputer und Trackauswertung womöglich gleich sein sollten.
Die Geräte sind sicherlich zuverlässig, wenn es um die Grundfunktion Position anzeigen und aufzeichnen geht. Alles darüber hinaus ist undurchdacht und schlampig programmiert. Und das schon seit Gerätegenerationen. Das Chaos bei der Trackauswertung vs Tripcomputer ist sicherlich nicht "mission critical", hinterlässt aber regelmäßig einen schlechten Eindruck und führt zu unnötiger Verwirrung.
Das kommt weil Garmin beschissene Workarounds einbaut, um Unzulänglichkeiten in seiner beschissenen Software auszugleichen. Garmin hat es nie geschafft den selben Algorithmus auf den Geräten sowie in Basecamp zu verwenden, um Trackaufzeichnungen auszuwerten. Wäre ja auch zu einfach im Tripcomputer, in der Zusammenfassung und in Basecamp immer mit dem selben Stück Code über alle Punkte zu gehen und das Ergebnis darzustellen.
Wie macht man eine ohnehin schon schlechte Sache noch schlechter? Richtig man trickst dumm herum, weil das eigentliche Problem anzugehen ja zu einfach wäre. Garmin speichert deswegen die Daten des Tripcomputers mit in der GPX Datei ab:
<gpxtrkx:TrackStatsExtension xmlns:gpxtrkx="http://www.garmin.com/xmlschemas/TrackStatsExtension/v1">
<gpxtrkx:Distance>26887</gpxtrkx:Distance>
<gpxtrkx:TotalElapsedTime>19186</gpxtrkx:TotalElapsedTime>
<gpxtrkx:MovingTime>10484</gpxtrkx:MovingTime>
<gpxtrkx:StoppedTime>2369</gpxtrkx:StoppedTime>
<gpxtrkx:MovingSpeed>3</gpxtrkx:MovingSpeed>
<gpxtrkx:MaxSpeed>22</gpxtrkx:MaxSpeed>
<gpxtrkx:MaxElevation>435</gpxtrkx:MaxElevation>
<gpxtrkx:MinElevation>-126</gpxtrkx:MinElevation>
<gpxtrkx:Ascent>8561</gpxtrkx:Ascent>
<gpxtrkx:Descent>8551</gpxtrkx:Descent>
<gpxtrkx:AvgAscentRate>0</gpxtrkx:AvgAscentRate>
<gpxtrkx:MaxAscentRate>3</gpxtrkx:MaxAscentRate>
<gpxtrkx:AvgDescentRate>0</gpxtrkx:AvgDescentRate>
<gpxtrkx:MaxDescentRate>-2</gpxtrkx:MaxDescentRate>
</gpxtrkx:TrackStatsExtension>
Alles anzeigen
Wenn diese Felder in der GPX Datei vorhanden sind wird der Schmarren, der da drinnen steht, angezeigt und nicht die Auswertung der Trackpunkte. Also ganz großes Kino by Garmin.
Im Anhang eine Auswertung der Trackpunkte.
Auch hier reicht die von volnar gegebene Information schlicht nicht aus, um irgendwas Vernünftiges zu antworten. Reine Zeitverschwendung.
Euch ist schon klar, dass SQLite zunächst mal nur eine Datenbank ist. Und ohne zu wissen was in der Datenbank steht und wie diese strukturiert ist, kann man solch eine Datei nicht lesen.
Der Einzeiler von volnar reicht zu keiner sinnvollen Antwort.
Oder selber kompilieren. Detaillierte Anleitung steht im Wiki.
Gibt kein Datum. Dann wenn genug zusammen ist, wichtige Pull Request abgeschlossen sind und kritische Bugs behoben sind.
Kann ich nirgendwo den Pfad zur DB editieren/ändern? Zwei Instanzen gleichzeitig wird es bei mir nicht geben, nur hintereinander. Bleibt mir nur mklink oder hast Du noch eine Idee?
Der Pfad für die Workspace Datenbank kann nicht konfiguriert werden. Der ist ganz bewusst lokal gesetzt.
Für eine Datenbank um alle deine Daten zu verwalte, kannst Du einen beliebigen Pfad angeben. Mehr zur Datenbank:
https://github.com/Maproom/qmapshack/wiki/DocGisDatabase
Zum Archivordner: Da sehe ich eine Chance, dass man den nicht anzeigt, wenn der Ordner eingeklappt wird. Da kannst Du gerne einen Feature Request bei Github auf machen. https://github.com/Maproom/qmapshack/issues
Zur Workspace Datenbank: Das ist nicht so einfach, weil diese Datenbank nie zum Teilen gedacht war. Wenn zwei Instanzen auf dieser Datei zugleich arbeiten, kann ich nicht sagen was passieren wird. Und eigentlich ist es auch so nicht gedacht. Was geht ist das zeitgleiche Arbeiten auf einer Datenbank. Dazu gibt es den Menüeintrag "Mit der Datenbank synchronisieren".
Ungültiger Punkt: Das ist tatsächlich ein wenig doof, weil der Track auf dem Gerät nicht geschrieben wird und somit QMapShack sich die Entscheidung nicht merken kann. Man sollte den Check wohl für Tracks auf einem Gerät besser bleiben lassen. Das kannst Du gerne auch als Feature Request bei Github eintragen.
Ihr macht was falsch.
Der Arbeitsplatz ist wörtlich zu nehmen. Es gibt Leute, die haben auf ihrem Arbeitsplatz genau das, was sie zum Arbeiten benötigen. Am Ende vom Tag wird der Arbeitsplatz aufgeräumt.
Es gibt natürlich auch Leute, auf deren Arbeitsplatz liegt alles was dort in den letzten N Jahren aus Versehen gelandet ist. Wer Ordnung hält, ist zu faul zum suchen.
Man kann seine Daten in Dateien organisieren. Man kann seine Daten in einer Datenbank organisieren. In beiden Fällen kann man mit F8, nachdem man fertig ist, den Arbeitsplatz aufräumen. QMapShack ist so nett und fragt, ob es die Daten speichern soll.
So ein Saustall, wie auf dem Screenshot, ist nicht nötig. Und der kleine Haken, um mal ein Projekt auszublenden, ist dafür gedacht, kurzzeitig die Daten wegzunehmen, um zu sehen was darunter liegt. Das ist kein Mechanismus für's Messi-Management.
Dafür gibt es, man glaubt es kaum, einen eigenen Trackfilter in QMapShack
Sagen wir es mal so: Bei steigendem Alter lässt das Auge im Nahbereich nach. Dann ist ein größeres Display schon ok. Weniger für die Karte, mehr für die Datenfelder.
Flimmern tut bei mir nichts. Ablesbarkeit bei Sonne ist so lala. Kontrast bei den Vektorkarten mies. Liegt aber primär an der Kartendarstellung. Das Farbschema mag zwar schick am Arbeitsplatz sein. Im Wald sind Wege nur sehr schwer farblich zu erkennen.
Bei mir ist der Kompass nach wie vor bockig und nur sehr schwer zu kalibrieren.
Letztlich kommt das Aventura nur noch auf leichten Wanderungen mit. Zu schlecht bei Sonne ablesbar. Akku zu anfällig bei Kälte. Keine reine Bedienung über die Knöpfe. Das Gerät ist einfach irgendwie nichts Ganzes geworden. Bei den anspruchsvollen Touren, wo ein robustes GPS durchaus auch zur Sicherheit beiträgt, ist es nach wie vor mein Garmin 64s.