Tja mei. Wenn halt immer alle darauf warten, dass irgendwer anderes die Arbeit macht, dann kommt halt nix dabei heraus, wenn der einzige der es macht mal keinen Nerv dafür hat.
Eigentlich ist alles gut dokumentiert. Es kann sich folglich jeder selber helfen. Und bei Bedarf die Doku anpassen. Wenn es niemand macht, dann scheint das Interesse nur sehr bedingt zu sein.
Also anstatt auf Godot zu warten, einfach mal selber aktiv werden. 
Nö ist es nicht. Die 10-15m kommen durch Laufzeitfehler in der Ionosphäre. Die kann man nur mit Mehrfrequenzempfängern kompensieren. Also theoretisch mit den 0815 Verbraucherempfängern, die das L1/E1 und L5/E5 Band auswerten. Bisher habe ich aber noch keinen glaubhaften Test gefunden, der bestätigt, dass der eine oder andere Empfänger das richtig macht und tatsächlich auf Metergenauigkeit kommt.
Zumal diese Störungen von der Sonnenaktivität abhängen und bei massiver Aktivität, so wie wir die zur Zeit und alle 11 Jahre haben, sogar RTK korrigierte Positionen nicht mehr der erwarteten Genauigkeit entsprechen.
Ich würde es einfach entspannt sehen. Erfahrungsgemäß liegen die Aufzeichnungen von verschiedenen Empfängern immer recht nahe zusammen. So schlimm ist es am Ende vom Tag nicht.
Der Schluss, den Du ziehst, ist richtig. Barometer kalibrieren. Die Kausalität die dazu führt ist es nicht.
Die DEM Daten sind nicht ungenau. Sie sind oft einfach nur zu grob aufgelöst. Das ist das eine Problem. DEM Daten die mit 25x25m oder 90x90m aufgelöst sind, können keine Strukturen auflösen, die kleiner als das Doppelte des Rasters ist. Bei sanften Hügeln, wie man sie in Mittelgebirgen findet, ist das ausreichend. Bei Bergen und engen Tälern nicht.
Aber auch super toll aufgelöste DEM Daten, wie die Lidar Daten (in der Regel 1x1m) bringen bei einem Track nicht wirklich viel, weil der Track selber nicht genau ist. Im richtigen Gelände führt die typische GPS Genauigkeit von 10-15m einfach zu falschen Werten. Was wir hier bräuchten wäre Metergenauigkeit. Und die gibt es auch bei den modernen Geräten nicht, wenn der Empfang schwierig ist.
Zusammengefasst: Bei DEM Daten ist die Auflösung oft ein Problem. Und wenn die Auflösung stimmt ist die Trackgenauigkeit das Problem.
Bei Tracks von den jeweiligen Anbietern muss man genau hinsehen. Wenn es eine echte Aufzeichnung ist und der Anbieter alles richtig gemacht hat, dann sind diese Tracks schon ok. Wenn wieder mal was fröhlich aus Stückwerk zusammengeklickt wurde ist's eher ein Serviervorschlag. Oft reicht beim Planen aber auch eine gesunde Schätzung aufgrund der Höhenlinien
Auch die Lidar Daten machen bei Brücken, Tunnel, Dämmen und Steilwänden Probleme. Was nützen supergenaue Daten wenn dein Track in der Position 10m neben der Brücke liegt?
Auch die Idee von Hubert funktioniert nur im gemäßigten Gelände. Sind bei der Methode halt andere Fantasiewerte.
Ein GPS mit kalibriertem Barometer produziert meiner Erfahrung nach noch die besten Werte. Zumindestens im Gebirge. Im Bayerischen Wald dürfen für die meisten Touren die bayerischen Lidar Daten gut genug sein.
Dazu kann man ohne die Daten zu kennen nichts sagen. Gerade in steilem Gelände ist der Vergleich immer schwierig. Wenn die Position schlecht war wird eine völlig falsche Höhe aus der DEM Datei ausgelesen.
In der Bau- und Agrarwirtschaft werden Positionen im Zentimeterbereich nur über RTK erreicht. Abgesehen von der Technologie fallen hier auch laufende Lizenzkosten an. In dieser Genauigkeit fängt einfach der kommerzielle Bereich an, mit dem der ganze Bumms teilweise finanziert wird.
Ohne jetzt weiter in das Thema eingestiegen zu sein, könnte ich mir vorstellen dass eine Triangulation über Lichtsignale die vielleicht machbarere Lösung ist. Das Fußballfeld hat ja freie Sicht. Aber auch hier dürften die üblichen Probleme, wie die Zeitsynchronisierung, eine echte Herausforderung darstellen.
Unter Android (hier Version 11) gibt es bei den Einstellungen "Netzwerk & Internet" -> "Erweitert" -> "Hotspot und Thethering" den Punkt "Bluetooth-Tethering" den muss man anschalten.
Daraufhin bietet das Telefon einen Bluetooth Hotspot an, mit dem sich das TomTom verbindet und dann über die mobile Datenverbindung Informationen mit TomToms Verkehrsservice austauschen kann.
Das Telefon kann sich parallel dazu mit dem Audiosystem des Autos verbinden. Zu Android Auto kann ich nichts sagen, weil mein Wagen das nicht hat. Ich würde es aber irgendwie erwarten.
Das funktioniert relativ zuverlässig. Auch mit verschiedenen Telefonen. Manchmal zickt das Umschalten und man muss über die Einstellungen Hand anlegen. Auch sehr selten, aber es kommt vor, wird trotz verbundenem Telefon eine gestörte Verbindung zum Server angezeigt. Das kann zwei Gründe haben.
Zum einen fällt manchmal der Server aus. Gut dagegen kann man nichts machen.
Zum anderen funktioniert die Datenverbindung im Telefon nicht richtig. Das mag an meinem Telefon (Nokia 7.2) liegen. Da zickt manchmal Bluetooth auch bei anderen Dingen. Oder weil das TomTom mit dem Telefon irgendwie einen schlechten Tag hat. Ein erneutes Verbinden löst das Problem oft. Manchmal muss man das TomTom neu booten und es geht. Oder es geht nicht weil - siehe oben - der Server nicht will.
Das kommt alles selten vor. Nervt dann aber. Ich habe beim Vorgänger den Komfort der verbauten Simm Karte sehr geschätzt. Schade dass das nicht mehr geht.
Nochmal: QMapShack berechnet die Geschwindigkeit aus dem Abstand der Trackpunkte und der Zeit die zwischen den Punkten verstrichen ist. Daraus ergibt sich eine Geschwindigkeit. Fällt diese unter einen bestimmten Wert, wird angenommen, dass keine Bewegung stattgefunden hat.
Hier ist der Code dazu,
// time moving
trkpt.elapsedSecondsMoving = lastTrkpt->elapsedSecondsMoving;
qreal dt = (trkpt.time.toMSecsSinceEpoch() - lastTrkpt->time.toMSecsSinceEpoch()) / 1000.0;
if (dt > 0 && ((trkpt.deltaDistance / dt) > 0.2)) {
trkpt.elapsedSecondsMoving += dt;
}Du musst dich mindestens 20cm/Sekunde bewegen.
Das ist natürlich nur eine Schätzung, weil QMapShack nur die Information aus der Aufzeichnung hat. Deine Uhr hat hingegen einige Sensoren, die eine deutlich bessere Abgrenzung zwischen Bewegung und Stand zulassen.
QMapShack berechnet die Geschwindigkeit aus dem Abstand der Punkte und der Zeit. Fällt diese unter einen Wert, wird angenommen dass man steht und sich die Position nur noch aufgrund des Rauschens ändert.
Der Schwellwert steht irgendwo im Code und ich kann gerade nicht nachsehen.
Ich empfehle auch das Wiki zu dem Thema Tracks:
https://github.com/Maproom/qmapshack/wiki/DocGisItemsTrk
Track bearbeiten und unter "Stil" die Breite einstellen.
Die Breite kann mit den beiden Toolbuttons rechts entweder für alle Tracks eingestellt werden (default) oder speziell für den aktuell ausgewählten. Die Tooltips erklären das.
Der Transparenzregeler ganz oben steht auf 0 und damit sind alle Elemente auf dem Arbeitsplatz nicht sichtbar.
Im Arbeitsplatzfenster den Haken beim Projekt setzen.
hu? Ich meine die Kommentare unter dem Testbericht. Die sind auch recht aufschlussreich. 
Hier mal ein relative neuer Testbericht:
Auch mal die Kommentare lesen.
Die Abgrenzung zu Garmin ist etwas seltsam, weil es vom selben Autor auch Tests der aktuellen Garmingeräte gibt. Speziell zu den 2 Band Empfängern. Da wird die Position und der Rest sehr gelobt. Ist natürlich auch immer die Frage, wie die Empfänger getragen wurden (Schulter, Jackentasche, Hosentasche, Gürtel). Das macht sehr viel aus.
Von meinem Aventura bin ich weniger begeistert. Hackelige Knöpfe, kein durchgehendes und stimmiges Tastenkonzept, mittelmäßiges Display und ein Akku der Kälte (-10°C) nicht ab kann. Aber das ist auch schon älter. Vielleicht ist die Hardware bei den aktuellen Geräten besser.
Die Software ist TwoNav. Einige sehr schöne Sachen dabei. Anderes ist nicht so gut. Wie bei jedem anderen Gerät auch. Die Darstellung der OSM Karten ist bescheiden. Aber wenn du eh gute Rasterkarten hast, dann willst Du OSM nicht
Im Wiki stehen Anleitungen für Windows, Linux und MacOS.
Wichtig sind eigentlich nur die Hilfprogramme von Routino. Dort entsteht ja der Fehler. Wenn man die in einer aktuellen Version hat und über die alten kopiert sollte alles gut sein.
Selber kompilieren.
Fast vergessen zu antworten. Nein leider nicht. Nur das was es hier gibt:
https://github.com/d029940/qma…eleases/tag/QMapShack-Mac
Wenn das eine berechnete Route ist, exportiert Basecamp alle Punkte die zur Darstellung benötigt werden. Und ja das sieht wie ein Track aus.
Das Ziel davon ist, dass die Route in einem Garmin GPS oder einer anderen Basecamp Installation exakt so wiedergegeben wird, wie sie bei dir lokal berechnet wurde. Das funktioniert aber nur in der Garmin Welt. Andere Software kann damit nur bedingt etwas anfangen.
Und natürlich kann auf einem anderen Gerät (sprich einer anderen Karte) eine erneute Berechnung zu einem anderen Ergebnis führen.
Es hat sich ein bisschen was getan:
https://github.com/Maproom/qmapshack/issues/601
Ganz runter scrollen.
Sprich: Routino 3.4 compilieren und installieren. Theoretisch müsste QMapShack auch noch mit der alten Lib arbeiten. Der Ausfall kommt ja nur bei den Tools zum Erstellen der Datenbank vor. Die brauchen die neue Version.