Beiträge von kiozen

Gut möglich dass die Datei fehlerhaft ist, bzw Felder enthält, die das Gerät nicht verdauen kann.

Oh, Du hast recht. Da hatte ich Pech beim Lesen und war noch beim Erstellen von Tabellen ein paar Posts darüber.

Ich pass das Wiki an.

Wäre schön wenn es dazu ein Patch gibt.

* Ticket erstellen: https://github.com/Maproom/qmapshack/issues

* Bitte Templates benutzen https://github.com/Maproom/qmapshack/wiki/DocFaqProjectSite

* Diese Anleitung lesen https://github.com/Maproom/qma…/wiki/DeveloperCommitCode

* in `src/qmapshack/gis/db/IDBMysql.cpp` ist der Code um die Datenbank zu erstellen bzw zu migrieren.

Danke!

SqLite hat mit dem PQ keine Probleme?

Ich hab das mit MySql schon lange nicht mehr ausprobiert. Ich könnte mir jetzt zwei Gründe vorstellen.

1. MariaDB Version zu alt. Da gab es eine Grenze. Ich weiß nur nicht mehr bei welcher Version

2. In dem Cache sind tatsächlich seltsame Steuerzeichen. Vielleicht auch irgendein UTF-8 Problem bei der Datenbank.

Edit:

Ok, sehe gerade Du warst schneller. Schau mal ob dein Setup UTF-8 unterstützt.

Ziemliches Drecksteil. Das macht Zeitfehler mit einer schönen Regelmäßigkeit. Und die Höhe ist auch gut daneben.

Zitat von T0bi

(-) Die SIM Variante gibt es nur bei der Premium Version, also zahlt man ca. 300 Euro.

Weiß nicht ob das so negativ ist. Es kostet zwar etwas mehr am Anfang, dafür hat man aber ein paar Vorteile:

• Kein eigenes Smartphone muss bereitgestellt werden. Damit keine Verknüpfung der Bewegungsdaten mit einem Android oder Apple Konto.
• Kein eigenes Datenvolumen muss bereitgestellt werden. Das kann außerhalb der EU recht schnell teuer werden. Die Schweiz ist z.B. nicht Teil der EU.
• Kein umständliches Pairing mit dem Smartphone am Anfang jeder Fahrt.

Wer es sorgenlos und frickelfrei haben will, zieht eine eingebaute SIM Karte vor.

Soweit so richtig.

zu "ersetzt vorhandenes Element": Hier geht es darum, welche Version eines Elementes benutzt werden soll. Die auf dem Arbeitsplatz oder die in der Datenbank. Es kann vorkommen, dass man ein Element bearbeitet hat und jetzt in einen anderen Ordner speichern möchte. Jetzt hat man 3 Möglichkeiten:

1. Man verwirft die Änderung und nimmt die Version, die schon in der Datenbank ist
2. Man überschreibt die Version in der Datenbank mit der geänderten Version auf dem Arbeitsplatz
3. Man legt einen Klon an. Also ein komplett neues Element.

QMapShack kann nicht wissen was Du willst. Deswegen die Abfrage.

Wenn Du mit einer Datenbank arbeitest, kann das Entfernen eines Elementes aus dem Arbeitsplatz theoretisch zwei Bedeutungen haben. Entweder Du willst es wirklich ganz weg haben (löschen) oder einfach nur nicht im Arbeitsplatz geladen haben. Da focus-follows-mind noch nicht in Qt implementiert ist gibt es praktisch nur eine Möglichkeit: Das Element wird aus dem Arbeitsplatz entfernt. Nicht aber aus der Datenbank gelöscht. Das muss in der Datenbankansicht gemacht werden.

Es gibt in der Datenbank keine Möglichkeit Elemente zu verschieben. Das muss über den Arbeitsplatz gehen. Ich sehe da auch nicht wirklich Bedarf. Das übliche Vorgehen ist, den Ordner mit allen Elementen zu laden. Dann werden die neuen Ordner erstellt und die Elemente in den jeweiligen Ordner kopiert. Ist man mit dem Ergebnis zufrieden, speichert man alles und löscht den ursprünglichen Ordner. So kann man bis zum Schluss immer wieder einfach in den Ausgangszustand zurückkehren.

Zitat von Hobby

haben diese Systeme auch Informationen über Streckensperrungen durch Baustellen ? wenn ja, bis zu welcher Straßenkategorie geht das runter ?

Beim TomTom sind immer alle offiziellen Baustellen bekannt. Einzig in Wohngebieten kann mal eine Sperrung fehlen. Ich denke das hängt zusammen, wie solche Sperrungen von den Behörden verwaltet werden. Letztlich greifen die Navihersteller auch nur auf Datenbanken von Ämtern und Verwaltungen zu.

Bisher bin ich noch nie an einer unvorhergesehenen Baustelle hängen geblieben.

Zitat von hubi85120

Wichtig für mich - es ist nur eine Empfangsschnittstelle - es ist daher ausgeschlossen, dass Daten von mir ohne mein Zutun zurück gesendet werden. Wenn ich lese, dass HansHans dafür eine SIM Karte nutzt, stellen sich mir die Nackenhaare auf.

Dafür funktioniert es auch besser.

Die Information über die Verkehrslage ist bei Systemen mit Rückkanal nicht "immer recht frisch" sondern schlicht und ergreifend aktuell. Solche Geräte wissen wo der Stau anfängt und ob die alternativen Routen sich überhaupt noch lohnen. Das funktioniert nur, wenn eine große Menge an Benutzer ihre Position und ihre Geschwindigkeit übertragen.

TomTom macht daraus keinen Hehl, sondern informiert schon immer beim Aktivieren der Funktion darüber was übertragen wird, wie lange es gespeichert bleibt und wer darauf Zugriff hat. Und das auch schon vor der DSVGO. Wem das nicht passt kann die Funktion deaktivieren, bekommt dann aber natürlich auch keine aktuellen Daten. Was nur fair ist.

Bei der Entscheidung muss man sich folglich fragen:

• Will ich nur wissen, dass ich in einem Stau stehen werde?
• Will ich aktuell eine lohnende Alternative angeboten bekommen inklusive einer Aussage was das in Minuten bringt? Und diese Aussage soll sich auch in der Regel bewahrheiten.

Wer letzteres will, sollte sich mit einem Gerät mit Rückkanal (GSM/SIM Karte) befassen.

Ich fahre jetzt seit mehreren Jahren mit einem TomTom durch Europa. Das Konzept überzeugt. Durch die eingebaute SIM Karte (inkl weltweiter Flat Rate) habe ich auch keine bösen Überraschungen, wenn es mal durch die Schweiz geht. Rumgehampel mit dem Smartphone gibt es auch nicht. Es funktioniert einfach und zuverlässig.

Zitat von Detlev mit Q

Leider wohl nicht als Akku.

Ne, natürlich nicht. LiPos haben nicht die richtige Zellspannung und geben bei 0°C auf. Wohingegen Lithium Batterien noch bis -10°C zuverlässig genügend Energie abgeben. Deswegen sind sie auch das Mittel der Wahl bei Wintertouren. Und den Rest des Jahres reichen gute Eneloop Akkus. Auch bekannt als Pre-Charged.

Dadurch, dass Lithium Batterien leichter als Akkus sind und eine sehr gute Kapazität haben, eignen sie sich aber auch für Mehrtagestouren. Je nach Etappenlänge und Temperatur kommt man knapp 2 Tagestouren pro Batteriesatz weit. Unterm Strich ist das weniger Gewicht als 2 Akkusätze und ein Ladegerät.

Aber bitte nicht vergessen: Der jeweilige Akku/Batterietyp muss im Gerät richtig eingestellt sein. Sonst spinnt die Ladestandanzeige.

Dann Versuche es mal mit Lithiumbatterien. Die sind sehr leicht und halten länger als jeder Akku. Für eine Woche im Jahr durchaus eine akzeptable Option. Im Winter sowieso. Für Tagestouren im Rest des Jahres sind Eneloop Akkus das Mittel der Wahl.

Gibt ja nur wenige Möglichkeiten:

• Falschen Batterietyp eingestellt.
• Ladehalterung sitzt nicht richtig, aka drückt den Taster im Batteriefach nicht.
• Akkus kaputt.

Wenn die ersten beiden nicht zutreffen, dann ist es der letzte Punkt.

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:

https://github.com/Maproom/qma…on-for-highlighted-tracks

Zitat von Saturo

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.

1. OSM Karten sind keine absolute Referenz. Die wurden in der Regel auch nur mit einem "consumer grade" GPS aufgenommen und können deshalb fehlerhaft sein
2. Gerade in bebautem Gebiet entstehen Reflexionen an den Hauswänden. Das kann je nach Tageszeit zu sehr starken Abweichungen führen
3. Trägt man das Gerät am Körper, z.B. Jackentasche, dann wird nahezu die Hälfte des sichtbaren Himmels abgedeckt. Das führt zu einer spürbaren Verschlechterung der Position.

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:

• Nur den Tripcompute(die Zähler)
• Nur den Track
• Beides zusammen

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.

Zitat von trailsurfer

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>

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.