Beiträge von kiozen

Das wird in der Konfiguration von QMS abgespeichert.

Der max. Wert bei der Einstellung pro Track scheint nicht abgespeichert zu werden. Müsste man mal fixen.

That's how it already is working.

A corrupted track is either a Frankenstein track or a track with a non-linear timestamp.

In general a track can have 2, 3 or 4 dimensions per track point. Either one is fine for QMS. Depending on the available dimensions secondary data is derived. The algorithm starts to derive data depending on the dimensions available at the first point. If it hits a track point missing a dimension it stops and the track is considered as corrupt.

In other words: If a track sticks to a number of dimensions (either 2, 3 or 4) and if there is a timestamp, that's not jumping back and forth in time, everything is fine for QMS.

Most tracks available on the Internet are Frankenstein tracks. A messy mesh-up of recorded data and various other questionable sources. The first thing I do with those tracks is to strip any timestamp and elevation data. If I have good quality elevation data for the area I add it to the track. Then I store it for further use.

To get large collections of tracks into shape I would write a small Python script to strip all the useless junk from the tracks to get plain tracks with 2 dimensions. Keep your data clean and tidy instead of messing with a sloppy and clunky data Behemoth.

I am quite temped to remove that feature. This was introduced when a user complained about no feedback when loading corrupted tracks from his shitty device. QMS does not calculate secondary data for corrupted tracks. As there was no feedback from QMS the user wondered why for some tracks data was derived and for some not.

Anyway it's a pain to click that dialog over and over again. And in almost all cases the tracks are corrupted beyond repair. Shitty tracks are shitty tracks. And the feature is a good example how the petites of a single user resulting in strongly demanding "fixes" can spoil software if you listen to the demand.

On the other hand side: Stop using shitty tracks or devices that produce them. In that case you never see that dialog.

Naja bisher könnte man das ja auch unter Software Allgemein diskutieren. Wenn man das Forum verfolgt war der Diskussionsbedarf für Apps bisher gering. Wenn man die Unterforen im Bereich Software verfolgt ist das Aufkommen dort marginal.

Bin kein Freund davon den Mangel weiter zu unterteilen.

Was nicht bedeutet dass man Apps nicht diskutieren sollte. Aber vielleicht erst mal in Software Allgemein anfangen.

Oh, das ist schon sehr lange her. Ganz dunkel erinnere ich mich, dass man noch irgendwelche udev rules einstellen musste. Ich glaube das war die Seite mit der Doku:

Fixing USB permissions for Garmins in GPSBabel.

Das HCX kann aber meines Wissens auch als Massenspeicher (wie USB Stick) eingebunden werden. Dann kann man wenigstens die aufgezeichneten Tracks auslesen. Der Rest geht nur über Garmins proprietäres USB Protokoll.

Opa erzählt vom Krieg: Grausige Zeiten damals.....

Du musst leider die Art der Skalierung für jeden Track einstellen. Also entweder benutzerdefiniert für den Track, automatisch oder die globalen Limits.

Oder Du überlegst dir, wie man das schön in das bestehende Konzept einbindet und erstellst ein Patch.

Zitat von Jan835

Ich kann nachvollziehen, dass jeder Punkt auch die Höheninformation braucht. Als Segler nicht besonders relevant, aber im Gebirge natürlich schon.

Eigentlich sollte eine GPS Aufzeichnung immer alle 4 Dimensionen (lat, lon, ele, time) haben. Das sind schließlich die Daten, die man mit dem Gerät misst. Auch wenn die Höhe auf dem Wasser nur einen sehr geringen Informationsgehalt hat.

Kannst Du den Fix testen?

[QMS-692] Trackpoints erroneously flaged invalid for short tracks (<50m) by kiozen · Pull Request #693 · Maproom/qmapshack

What is the linked issue for this pull request: QMS-#692 What you have done: To get a better mean of the values metadata for a point is calculated by selecting…

github.com

Das ist an für sich ein Bug, der aber nur bei Tracks getriggert wird, die kürzer als 50m sind. Deswegen hat den noch keiner gefunden.

Die Funktion die Du suchst ist in "void CGisItemTrk::deriveSecondaryData()". Das Problem ist wahrscheinlich in Zeile 1007..1009.

Gute Frage warum der Punkt unbedingt eine Höhe haben muss. Wahrscheinlich wurde damals entschieden, dass es keinen Sinn macht sekundäre Daten zu berechnen, wenn die Punkte nicht in allen 4 Dimensionen definiert sind.

Deine Tracks haben die Geschwindigkeit als Erweiterung gespeichert. Erweiterungen werden in der Tabelle nicht angezeigt. Bei den Diagrammen kann man sie aber auswählen. Und in der jeweiligen Information zum aktuellen Punkt werden sie auch angezeigt.

Das Bild in GE zu referenzieren ist halt das Problem. Soweit ich mich erinnere, muss man das solange drehen, dehnen, schieben, bis es "passt". Nur ist das leider keine gute Methode, wenn es genau sein soll. Vor allem nicht, wenn die Grundbuchpläne schon genau eingemessen sind.

Aber ich bin mir fast sicher man findet ein Tool, das aus einer georeferenzierten Karte ein KMZ baut, wenn man danach sucht.

Schon lange nichts mehr mit GE gemacht. Aber soweit ich mich erinnere kann man Karten im KMZ Format einbinden.

Fragt sich nur wie man eine Karte in das KMZ Format bringt. GDAL hat ein KML/KMZ Modul. Ob das wirklich auch Karten konvertiert, müsste man ausprobieren. Wahrscheinlich gibt es auch noch andere Tools. Ich hatte mal für QLandkarte GT was geschrieben, aber das ist schon uralt.

Alternativ kann man natürlich auch Software verwenden, die die Satellitenkarten von Google anzeigen kann und dann die Karten (in welchem Format sind die denn?) halb transparent drüber legen. QMapShack kann das. Aber auch die anderen Programme wie GlobalMapper, QGis etc.

Das wären zu dem Thema meine Gedanken ins Blaue gedacht.

Könnte es sein dass das Zumo, genauso wie viele andere Garmin Geräte, die Tracks nach der Entfernung zum aktuellen Standort sortiert?

Das ist ganz einfach. Wenn Metadaten vorhanden, dann werden diese von der Garmin Software angezeigt. Sobald man den Track irgendwie bearbeitet, werden die Daten gelöscht.

Nachdem sich ja standhaft geweigert wird mal mit einem echten Track um die Kurve zu kommen... Schon überprüft ob die komischen Werte aus den Metadaten vom Trip Computer kommen? Die werden bei Garmin mit abgespeichert und Basecamp verwendet die, anstatt den Track auszuwerten.

Ich glaube auch es bringt wenig weiter zu spekulieren. Wenn jemand mal Tracks einstellt, dann kann ich sie mir gerne ansehen, ob etwas komisch ist und was man aus den Tracks berechnen kann. Ohne was Konkretes können wir nur weiter Allgemeinplätze zur Höhenberechnung im Kreis diskutieren..

Ist das ein Reißverschluss aus Metall? Das wäre nicht so optimal.

Außerdem machte es einen Unterschied bei der Quad-Helix-Antenne ob das Gerät steht oder liegt. Die hat eine Richtwirkung.

Auch das Tragen in Körpernähe ist immer schwierig. Ein idealer Punkt ist aufrecht an der Schulter. Dort ist die Abschattung durch deinen Körper gering. Schon der Platz an der Hüfte ist schlechter als das Gerät zu halten.

Die GPS Frequenzen wurden bewusst gewählt, weil diese Frequenzen mit wenig Dämpfung durch Wasserdampf kommen. Allerdings sind geschlossene, leitende Flächen ein echtes Problem. Also Blätter, dein Körper oder Metallteile .

Weiß nicht... früher hieß es: Geh raus an die frische Luft zum spielen. In diesem Sinne: Störche ansehen bringt mehr

Zitat von hubi85120

na ja, vielleicht hat sich der Kalender seither um ein paar Tage verschoben

Oder es war schon der Termin? Aber vielleicht ist was dran? Die eiserne Regel, dass mit dem Beginn der Schulferien in Bayern das Wetter schlecht wird, wurde dieses Jahr schon gebrochen. Man weiß es halt nicht. Und solange sich solche Weisheiten aus subjektiver Wahrnehmung speisen, wird das auch nie wirklich was werden

Es gibt ja auch Leute die sich professionell damit beschäftigen:

Deutschland Wetter Winter 2024/2025: Wetterprognose und Wettervorhersage

Zusammengefasst: Nix g'wiss woas ma ned, weil's hoild des Weeda is . Aber wahrscheinlich zu warm.