Ohne stetig "neuer Standards" auf den Markt zu werfen, könnte man den Leuten doch kaum alle fix lang was Neues andrehen...
Ich kann USB 4.0 auf den Markt werfen, das alles viel besser macht, ohne den Stecker zu verändern. Kabel und Stecker sind nur der physikalische Layer. Und der ist bei einem Kupferkabel recht überschaubar. Die Datenrate steckt im Chipsatz. Das verwendete Protokoll in der Software.
Einen Grund für einen frühzeitigen Gerätewechsel sehe ich für mich darin aber nicht.
Das war aber gerade nicht die Frage 
. Sondern ob die EU Richtlinie Technologieoffenheit verhindert.
Ja... und braucht es dazu alle paar Jahre einen neuen Stecker?
Und wegen Technologieoffenheit: Die EU hält niemanden davon ab, ein Datenkabel mit Stromversorgung auf der Basis von einer Glasfaser zu entwickeln, spezifizieren und zu vermarkten. Wenn es dafür gute Gründe gibt. Obst auf dem Deckel und Vendor Lock-in sind halt schlechte Gründe.
Was für Wunder der Technologie erwartest Du? Das ist ein serieller Bus dessen Datenrate durch das Kabel bestimmt wird. Der Stecker ist hier eher nebensächlich. Im Stecker selber gibt es genügend Anschlüsse für einen full-duplex Bus jeglicher Art inklusive Stromversorgung.
Steckerseitig ist die Größe ein Thema und die Robustheit. Deswegen der Schritt von Mini USB zu Micro USB. Und weil Micro USB ein fragiler Mist ist, bei dem viele Leute Probleme haben ihn überhaupt richtig herum einzustecken, hat man USB C genommen. Etwas größer, stabiler und passt ins Loch irgendwie.
Also ich will nicht sagen, dass es nie mehr etwas Besseres geben wird. Aber für eine einfache serielle Datenverbindung mit Stromversorgung (mehr ist USB nicht) benötigt man nicht alle paar Jahre ein neues Steckerformat. Im Stecker steckt mehr Marketing als echte Technologie.
Ich würde doch auch sagen, dass die unterschiedliche Leistungsabgabe eher ein Erste-Welt-Problem ist. Die unendliche Flut von Elektroschrott ist leider ein Dritte-Welt-Problem und je weniger wir produzieren desto besser.
Ich melde mich in einem öffentlichen Forum an und fordere persönlichen Support per privater Email.
[ ] Du hast den Sinn und Zweck von Foren verstanden
Krass.
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.
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?
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.
