Beiträge von Ralphie

Garmin fenix 7X und epix Gen 2 im Test

Der Schwerpunkt dieses Tests und Vergleichs der Garmin Fenix 7X Solar und Garmin Epix Gen 2 liegt auf den Sensoren wie Höhenmesser, Positionsbestimmung und Herzfrequenz. Was unterscheidet die beiden GPS-Outdoor-Smartwatches? Und wie gut ist die Taschenlampe der Fenix 7X für den Outdoorbereich? Hier geht es zum Test der Outdoor-Smartwatches ...

    Erst mal danke für diese ausführlichen Hinweise.

    So über'n Daumen gepeilt, gehe ich davon aus, dass Applikationen, die man bei f-droid wohl, aber bei google nicht bekommt, Daten besser schützen („Verzicht auf Google-Dienste“ - mein Händi hat keine SIM-Karte und bekommt auch keine). Der beim mendhak voreingestellte Speicherort ist zwar unschön, lässt sich aber von außerhalb Androids erreichen, das reicht mir eigentlich. Du hältst den mendhak aber für weniger resourcenschonend als den BasicAir? das wäre ein starkes Argument für mich.

    1.) Datenschutz: man kann auch Apps im Google Play Store anbieten, die keine Google-Dienste nutzen (und diese daher auch nicht in den Programmcode einbetten).


    Aber klar, die App-Downloads (Installationen) werden in gewisser Weise protokolliert und bei App-Abstürzen kann der App-Entwickler im Normalfall über die Play Console in das Absturz-Log hineinschauen (was ich jetzt aber nicht als schlecht erachte, weil das bei der Bugsuche für Entwickler sehr hilfreich ist).


    Das ist aber so eine Meta-Diskussion (Google, Big Brother, etc.). Letztlich müssen wir User das nutzen, was uns am besten taugt. Ich bin halt sowohl als User als auch als Entwickler unterwegs und daher bei diesem Thema wohl etwas entspannter (obwohl ich Google wirklich sehr oft verfluche).


    Google nimmt den Datenschutz gegenüber Entwicklern aber sehr ernst. Wenn man Apps außerhalb vom PlayStore platziert, kann man im Grunde genommen mehr Hintertürchen einbauen als wenn man diese über den PlayStore anbieten will (und Google über die Einhaltung der (Daten)schutzregeln wacht).

    Wobei ich Apps, die auf FDroid angeboten werden, davon aber ausnehmen will (die sind schon sauber), bei anderen Quellen wäre ich aber eher vorsichtig.


    2.) Resourcenschonender: das habe ich so nicht geschrieben. Meine Mutter kommt halt mit dem BasicAirData Logger besser klar, weil sie nur die Aufzeichnung mit dem Start-Button starten muss und am Ende nur den Stopp-'Button' klicken muss. Mehr will sie gar nicht machen. Automatisieren will sie nichts, da sie nur ihre Wandertouren protokollieren will (diese macht sie ja nicht täglich ;) ).


    Ich hätte ihr auch einen anderen Logger eingerichtet*, mit dem mendhak Logger wurde sie halt nicht wirklich warm.

    Vom Resourcenverbrauch schenken sich die einfachen Logger, die auf eine Karteneinbettung verzichten, alle nicht viel. Laufen normalerweise auch dezent im Hintergrund, sofern man es schafft, die (Android)-Batterieoptimierungen entsprechend zu deaktivieren (was bei manchen Smartphones aber eine richtige Strafarbeit sein kann).


    Mir selbst fordert der Logger aber etwas zu viele Schreib- und Leserechte ein - zumindest wenn man auf das externe Laufwerk zugreifen will. Es gibt nur wenige (System) Apps, denen Google die erweiterten MANAGE_EXTERNAL_STORAGE Rechte zugestehen würde (https://developer.android.com/…ge/manage-all-files?hl=de), ein GPS Datenlogger würde diese m.E. nicht bekommen und für den PlayStore mit diesen Rechten daher keine Freigabe bekommen, zumal es auch nicht wirklich nötig ist.


    Aber um das klar hervorzuheben, ich bin mir sicher, dass der Logger diese Rechte NICHT missbrauchen wird, man kann das als Schönheitsfehler abtun.


    Nichtsdestotrotz hätte ich mir etwas schwer getan, weil es eben das Smartphone meiner Mutter ist und ich da nicht alle paar Tage einen Blick draufwerfen kann. Hat alles seine Vor- und Nachteile.


    Wichtig ist, dass Du mit den von Dir genutzten Apps klarkommst, man sollte sich da m.E. auch gar nicht soviel von Außen reinreden lassen.

    So, dann will ich mal mitteilen, was ich durch Probieren glaube herausgefunden zu haben. Das Programm erhält man kostenlos bei f-droid. Vermutlich spezifiziert der Ausdruck „mendhak“ das Programm. Vom Namen her ist es leicht verwechselbar mit mit einem im play-store (oder github) erhältlichen GPS-Logger, der vermutlich durch den Ausdruck „BasicAirData“ spezifiziert wird. Das folgende bezieht sich ausschließlich auf „mendhak“.

    Ich will hier keine Empfehlung geben, weil diese Logger alle recht gut sind und letztlich die eigenen Vorlieben den Ausschlag geben, aber wenn es um einfaches Handling geht, dann ist der BasicAirData GPS Logger sicherlich auch einen genaueren Blick wert.


    Meine Mutter (> 80 Jahre) nutzt diesen gerne beim Wandern, weil er recht schlicht daherkommt und einfach zu bedienen ist. Ist ein reiner GPS-Logger (ohne Kartenansicht, etc.), der allerdings mit externen GPS Viewer Apps gut kombiniert werden kann -> man kann externe Viewer einbinden, die per Knofpdruck - ohne Umweg eines Exports - direkt aufgerufen werden können. So kann man hinterher schon einmal direkt auf dem Smartphone einen ersten genaueren Blick auf die Aufzeichnung werfen.


    Den von Dir genannten GPS Logger hatten wir auch mal testweise in Benutzung. Wenn Du auf den externen Speicherort (SD Card) zugreifen willst, dann benötigt dieser GPS Logger meines Wissens sehr weitreichende Lese- und Schreibrechte, weil er zum Auswählen des gewünschten Folders einen eigenen Dialog verwendet (zumindest war das mit der von uns getesteten Version der Fall und soviele Rechte möchte ich zumindest auf dem Phone meiner Mutter einer GPS-Logger App nicht zugestehen, weil das nicht notwendig ist). Es kann gut sein, dass dieser Logger einen eigenen Auswahldialog nutzen muss, um FDroid konform zu sein (da gibt es m.W. nämlich einige Auflagen, weitgehendst Verzicht auf Google-Dienste, etc.).


    Das ist bei dem BasicAirData GPS Logger besser gelöst, weil dieser den von Google favorisierten Weg über einen Intent-Aktion ACTION_OPEN_DOCUMENT_TREE Folderauswahl-Dialog nutzt.


    Google hat seit Android 11 (leider) sehr viele Einschränkungen an den Schreib- und Leserechten vorgenommen, die Verzeichnisauswahl ist unter aktuellen Androidversionen sehr regelementiert (und wird zukünftig womöglich sogar noch weiter eingeschränkt werden, wenn man nicht die angedachten API Funktionen dafür nutzt): https://developer.android.com/…red/documents-files?hl=de.


    Aber wie gesagt, ich will Dir bei der Frage nicht reinreden: der mendhak GPS Logger hat z.B. einige sehr gute Automatisierungsoptionen, die der BasicAirData Logger nicht aufweist.


    Beides sehr gute Logger, wenn man es einfach haben will.

    Falls das jetzt dem TE zu weit geht, bitte melden.

    Ralphie : Tatsächlich lassen sich bei Twonav Geräten auch noch Filter auf die Höhenmessung legen. Wir haben die Wahl zwischen exponentiellen Filter (mit einstellbarem Exponential Alpha Wert) oder einem Kalman Filter (mit einstellbarem Meas Error und Q Varianz Wert). Das ist aber völlig undokumentiert und ich bin da zu unwissend, um das für mich gut einzustellen, daher lasse ich den Filter ausgeschaltet.

    Ich will das Thema jetzt auch nicht überstrapazieren, weil wir wirklich Gefahr laufen, das alles auf eine Metaebene zu verlagern.


    Anbei noch zwei Links (nur der allgemeinen Information wegen).


    Vielleicht kann sich noch jemand an Klaus Bechtold erinnern? (Er war der geniale Kopf hinter der GPSies Plattform, die es leider nicht mehr gibt, aber uns Freunden der GPS Tourenplanungen sicherlich Jahre lang sehr gute Dienste geleistet hat und die bestimmt noch viele User kennen). Klaus hatte sich dem Thema auch einige Mal angenommen, am Ende dann aber auch wieder einen etwas einfacheren - oder besser gesagt pragmatischeren - Ansatz verfolgt. Geht aber wahrscheinlich etwas in die gleiche Richtung, die Twonav eingeschlagen hat, wenn ich das richtig einschätze, daher poste ich die beiden Links.


    Die Links sind leider nur noch über https://web.archive.org/ einsehbar, da sein Blog nicht mehr existiert.


    Neue Methode zur Berechnung der Höhenmeter

    GPSies Blog
    konvertieren nach Google Earth (KML, KMZ), Google Maps directions (XML, JSON), PCX5 (tracks, waypoints), GPX (tracks, routes, waypoints), GPX Garmin…
    web.archive.org

    Ich hätte jetzt zuerst geschrieben, dass das gegenüber Garmin und Wahoo - um mal zwei weitere etablierte Firmen aus dem Sportumfeld zu nennen - wirklich sehr gut dokumentiert ist, habe aber gerade gesehen, dass die beiden genannten Firmen das Thema mittlerweile auch etwas ausführlicher behandeln:


    Garmin schreibt zum Thema: https://support.garmin.com/de-DE/?faq=FhOYuggxmV6Atph276U4h8


    Wahoo: https://support.wahoofitness.c…fferences-in-my-ride-data


    Wobei diese Technik aber sicherlich über die Jahre immer weiter optimiert wurde und sich nicht jede Geräteserie gegenüber anderen Modellen gleich verhalten wird.


    Man könnte das auch alles auf die Spitze treiben und jene durch eine Kalibrierung bedingte n Höhensprünge mittels eines gleitenden Mittelwerts weich anpassen, sodass man hinterher diese Neujustierungen nur schwer dem Höhenprofil bzw. den Datenreihen entnehmen könnte. Der Kumulierung der Auf- und Abstiegswerte würde das sogar entgegen kommen.


    Aber den Stress wird sich vermutlich kein Hersteller wirklich antun, sondern irgendwo wird man dann einen Cut machen und sagen, das ist halt der Consumerbereich und dafür taugt's dann erst mal.


    Daher nehme ich wirklich an, dass bei vielen dieser Produkte im Pflichtenheft festgehalten sein dürfte, was der primäre Einsatzweck ist und welche spezifischen Eigenschaften damit einhergehen.


    Bei eher universelleren Geräten wird man dann ggfs. mehr Optionen zur Verfügung stellen (diverse Autokalibrierungen, mitunter einen variablen Hysteresefaktor - da ist mir aber kein Gerät bekannt, bei dem man das Geräteseitig eimnstellen könnte, ich kenne das nur bei PC-Software und Apps - , etc.).


    Man muss halt für das verwendete Gerät ein Gefühl bekommen, dann kann man sich m.E. gut auf die Gegebenheiten einstellen. Bei Parallelaufzeichnungen, querbeet durch die Hersteller, wird man aber sicherlich weiterhin die ein oder andere Überraschung erleben.

    Das stimmt nicht so ganz, man kann es bei Twonav auswählen und zwischendurch wird tatsächlich immer wieder mal das Barometer automatisch geeicht.

    Ausführlich siehe hier:

    Für mich geht das alles etwas in Richtung Voodoo, weil man als User nicht weiß, nach welchen Regeln diese Autokalibrierung funktioniert. Auf den Herstellerseiten findet man dbzgl. auch nur wenig Informationen. Prinzipiell sicherlich eine gute Sache, aber nach Möglichkeit sollte diese Autokalibrierung so erfolgen, dass sie so wenig Einfluß wie unbedingt nötig auf die eigentlichen Datenreihen hat.

    In dem von Dir gesposteten Parallelthread sieht es ja so aus - sofern ich das richtig überflogen habe -, dass die Autokalibrierung im Höhenprofil richtige Sprünge erzeugen würde?! 8|

    Und somit schließt sich der Kreis dann wieder, weil man in dem Fall um eine zusätzliche Glättung der Daten nicht herumkommen wird.

    Ob das dann direkt im GPS Chipsatz passiert - wie das einige moderne Chipsätze wohl machen - oder erst hinterher beim Generieren der (Export)Daten, macht ja keinen Unterschied.


    Sind aber alles Faktoren, die bei der Berechnung der Auf- und Abstiegsmeter hineinfließen. Wenn man SRTM Daten verwendet und die voraussichtlichen Höhenmeter einer Route berechnen will, muss man die Höhenwerte auch zuerst glätten, sonst passt es einfach nicht (selbst bei den neueren relativ feinauflösenden Daten).


    Die aktuellen Sportcomputer speichern die Höhenwerte mittlerweile mehr oder weniger durch die Bank im Fließkommaformat (mit mehreren relevanten Nachkommstellen). Macht sich auf dem Papier zwar gut, aber letztlich wird hier auch eine Genauigkeit vorgespielt, die so akkurat gar nicht sein kann, bei Geräten, die sich ständig in der Bewegung befinden (sowohl horizontal als auch vertikal).


    Ich bleibe dabei, das ist sicherlich keine Raketentechnik, aber man wird immer nur näherungsweise dem Problem beikommen können und ich nehme an, die Hersteller wissen das auch und reagieren deswegen auch recht gelassen auf dieses Thema. Es wird nämlich auch in den Hersteller eigenen Foren immer wieder diskutiert (und jede neue Gerätegeneration sorgt der Erfahrung nach wieder für etwas Aufregung) :)

    Aber es scheint dennoch genug Stolpersteine zu geben, sonst würde dieses Thema ja nicht immer wieder in den Foren und Weiten des Internets aufschlagen ;)


    Ich bin übrigens auch eher ein Freund von anpassbaren Hysteresefaktoren, ob jetzt 2m, 3m oder 5m am Universellsten sind, das ist dann mehr so eine akademische Frage. Hängt halt viel von der Hardware ab (selbst die Position des Barometer Chips innerhalb des Gerätes kann Einfluß haben, den man unter Umständen irgendwie abfangen muss).


    Ich habe viele Daten im Nachinein darauf beleuchtet, bei einigen bewirkt eine Änderung des Hysteresefaktors eine recht kleine Abweichung, bei anderen liegen dann mitunter Welten dazwischen, wenn der Hysteresefaktor minimalst von zwei auf drei verändert wird (Samplerate der Aufzeichnung, aber auch das Verhalten der Höhenmessung spielen da mit rein).


    Das Fusionsding bei Garmin (und einigen anderen Herstellern) ist ja so eine closed-box Geschichte. Da scheinen viele Geräte ein Eigenleben zu führen,

    von Kalibrierung nur beim Start der Aufzeichnung, über Kalibierung zu bestimmten Anlässen/Ereignissen hin zu einer Kalibrierung nach einem festen Zeitfenster scheint alles dabei zu sein.


    Ich habe aber wirklich selten Daten gesehen, bei denen diese Fusionierung merklich Einfluß auf die berechnten Höhenmeter hatte. Die Aufstiegsmeter werden ja aus den jeweiligen Deltas zweier Meßpunkte berechnet.

    Da müsste diese Autokalibierung schon einen echten Sprung aufweisen, dass das bei der Berechnung der Aufstiegsmeter große Auswirkungen hätte.

    Ähnlich bei der reinen Barometermessung und wetterbedingten Barometerdrifts. Auch das hat kaum Einfluß, es sei denn, man läuft/fährt in einen brutalen Wettersturz rein, bei dem das Berometer in sehr kurzer Zeit wirklich sehr stark ansteigt oder fällt.


    Ob reine GPS-Höhen oder Barometeraufzeichnungen besser sind, ist halt auch so eine Frage. Bei reinen GPS-Messungen hat man halt immer ein Rauschen, welches bei Barometer basierten Aufzeichnungen in dieser Form normaler nicht existiert.

    Dafür sind bei den GPS-Höhen die absoluten Höhenwerte häufig genauer, weil der Barometerdrift wegfällt (einen Tod stirbt man immer )


    Da hat aber jeder sicherlich seine eigenen Erfahrungen gemacht, für mich (primär Bike-Computer Nutzung, aber auch etwas Wandern) taugt die Barometermessug nach wie vor am besten.


    Auf GPS-Seite hat sich in den letzten Jahren aber vieles getan: ich habe GPS-Aufzeichnungen gesehen, bei denen die Höhenwerte sehr glatt/konstant waren. Weiß aber nicht, ob das Gerät die Höhendaten bereits geglättet hat oder nicht, was (Glättung) ich annehmen würde. Und wenn die Daten geglättet werden, dann spielt ja schon wieder eine dritte Variable mit in die Berechnung hinein, denn die Datenglättung bewirkt ja auch wieder eine künstlich vorgenommene Korrektur.


    Daher kann ich Deinem letzten Satz nur beipflichten, man kann das nämlich alles auf die Spitze treiben, am Ende muss man es aber eh nehmen wie es kommt (und sämtliche Maßnahmen, mit denen man das im guten Glauben auf einen gemeinsamen Nenner bringen will, weisen dann doch wieder Stolpersteine auf).


    Am Ende zählt eh nur der Spaß und jeder Berg ist anders :saint:

    Kann ich bestätigen, hab mich auch mal reingelesen…..👍

    Freut mich zu hören. Der Beitrag ist halt schon etwas älter und in Sachen Höhenauswertung auch etwas gestraft.


    'Wir' haben das in den einschlägigen Fahrradforen immer wieder mal diskutiert. Ich habe das Thema dort auch mal aus Entwicklerseite erörtert, aber wie es so ist, einige Webseiten und Foren bzw. Forenbeiträge existieren leider nicht mehr bzw. sind unauffindbar.


    Noch was zu Hysterese: Ende der 90'er, Anfang 2000 wiesen die Barometer-Sensoren noch eine sehr grobe Auflösung auf (anfangs 3m, irgendwann dann 1m Auflösung). Daher war es relativ einfach, einen geeigneten Hysteresefaktor zu finden.


    Mittlerweile lösen die Barometerchips im cm Bereich auf (https://www.amsys.de/produkte/…zisions-barometer-sensor/) und sind auch nicht mehr so träge in der Messung. Das heißt, man muss im Grunde genommen viel filtern, weil jeder Luftzug oder auch Temperatursprung schon eine Änderung der Höhenmessung bedingt (das Rauschen also zunimmt).


    Das erklärt dann vielleicht auch, weshalb selbst große Hersteller wie Garmin und Konsorten sich bei neuen Geräten immer wieder an die Berechnung der Höhenmessung herantasten müssen, weil sich einfach die verwendeten Komponenten grundlegend verändert haben und ältere gegenüber neueren Geräten - trotz des Versuchs, das irgendwie anzugleichen -, häufig dann doch andere Ergebnisse liefern.

    Diese Höhenberechnungnen sind wirklich eine kleine Wissenschaft für sich, sicherlich keine Raketentechnik, aber auch nicht so trivial, wie es auf dem ersten Blick erscheint. Bei Biekcomputer, bei denen man von einer schnelleren Fortbewegung ausgeht, wird dann in der Regel ein etwas höherer Hystresefaktor verwendet. gegenüber der Outdoor Handheld Geräte.


    Daher wird das auch immer wieder diskutiert :saint:


    Webportale, die die Höhenmeter anhand von SRTM-Datenbanken berechnen haben es da wesentlich einfacher, weil die halt auf eine konstante Datengrundlage aufbauen können, sodass zumindest die Berechnungen innerhalb ihres Mediums konsistent sind.

    ...

    Fakt ist aber, dass mein Bike Navi, das Edge 830 für mein Empfinden sehr genau ist und wirklich erst positive Höhenmeter aufzeichnet, wenn es gefühlt auch aufwärts geht.


    Grüße Hardy

    Das liegt aber auch darin begründet, dass bei reinen Bike-Computern in der Regel andere Hysteresefaktoren Verwendung finden. Der Hysteresefaktor spielt bei der Berechnung der Höhenmeter eine sehr große Rolle, sowohl im Gerät selbst als auch bei den Auswertungsprogrammen oder Webplattformen, die anhand der Höhenwerte (Datenreihen) eigenständig die kumulierten Auf- und Abstiegsmeter berechnen.


    In meinem Blog bin ich vor vielen Jahren einmal auf die Thematik eingegangen (dort sind auch eine Links eingebunden, die das Thema erörtern. Sehr interessant z.B. die Ausführungen von Jobst Brandt zum Thema: https://yarchive.net/bike/altimeter.html ). Im Internet findet man auch viele Seiten, die sich mit dem Thema befassen. In der Regel wird man leider keine generelle Lösung des Problems finden, weil einfach zuviele Faktoren mit reinspielen.


    Hier der Beitrag aus meinem (schon etwas älter, aber an der Messung und Berechnung hat sich eigentlich nichts grundlegendes geändert und auch wenn die verwendeten Barometer-Messsonden immer genauer auflösen können, ist das bei der Berechnung der realen Aufstiegsmeter nicht immer von Vorteil):


    GPS Daten oder spezifische Sensor Daten (Part 1: die leidige Sache mit der Genauigkeit)

    Glaube nicht.

    Ich habe auf der Connect Webplattform bei einer Activity auf Satellitenansicht gewechselt (dort scheint Garmin Connect die Einstellung auch zu speichern), weil manchmal Änderungen innerhalb der Webplattform auch in der (Android) App übernommen werden.

    Aber in der APP scheint die normale Standard-Kartenansicht als default fest verdrahtet zu sein. Sowohl in der Preview als auch beim Aufruf der Kartenanzeige (Vollansicht) wird die Karte immer im Standardmodus geöffnet.


    PS: bin mit der Garmin Connect Beta Version unterwegs, wird aber wahrscheinlich keinen Unterschied machen.

    Dann ist es sicher möglich, die App auch über f-droid.org oder direkt auf github anzubieten. Bei github wird auch der Quellcode eingestellt und daneben kann die APK veröffentlicht werden. Wie das bei f-droid.org funktioniert, weiß ich nicht.

    Freeware bedeutet ja nicht zwangsläufig Open Source.


    Die App ist frei und wird frei bleiben - da ein reines Side Projekt (in dem ich aber auch eigenen Code aus einem größeren 'kommerziellen' Projekt verwende). Insofern ist github für mich derzeit kein Thema, das ich aufgreifen kann/will. Bei F-Droid verhält es sich leider ähnlich.


    Direktes Hochladen auf APKPure werde ich aber ins Auge fassen.

    Alles klar, vermutlich bin ich da auch echt nur ein Winzklientel und ich weiß ja, wie ich mir helfen kann. Die 2.0.16 hatte ich bei Google gesehen, bin aber über Alternativanbieter noch nicht rangekommen. Das lag aber sicher eher an mir.

    Wie gesagt, ich schau dir Tage mal, ob ich die jeweils aktuelle APK als Entwickler auf APKPure - ohne zuviele Klimmzüge tätigen zu müssen - auch direkt hochladen kann. Wenn ich zumindest etwas Einfluß habe, was bei den alternativen APK-Archiven zum Download angeboten wird, dann ist das ja auch in meinem Sinne.


    Gibt sicherlich einige User, die den PlayStore meiden. Ich bin auch nicht so der große Google Fan und es gab jetzt auch eine Anfrage eines chin. Users, der mir die Texte ins Chinesische übersetzen will. Vielleicht muss ich dann sowieso Hand anlegen, wobei die Reichweite meiner App aber eher bescheiden ist.


    Andererseits, nur wenn man auf etwas hingewiesen wird, kann man es ändern/verbessern, insofern bin ich Anregungen immer offen :thumbup:

    Danke für das Feedback und die Anregung.


    Ich bin eigentlich im Windows Umfeld als Entwickler tätig und Android ist wirklich nur ein Hobby, das nebenbei läuft (wie's gerade die Freizeit hergibt und was ich selbst gut gebrauchen kann).


    Der Vertrieb über den regulären Playstore hat für mich den Vorteil, dass ich mit relativ wenig Aufwand auf Nummer sicher gehen kann, was die Authentizität der vertriebenen APP-Pakete betrifft.


    Bei externen Plattformen ist das nicht mehr sichergestellt und mitunter auch recht kompliziert. Der Vertrieb über F-Droid, den ich auch mal angedacht hatte, würde z.B. größere Änderungen am Code bedingen (sofern ich das richtig verstanden habe), was mir dann wiederum zuviel Aufwand ist.


    Ich werde aber zwischen den Jahren mal schauen, was es für Alternativen gibt (bin mit Google nicht verheiratet und für fast alles offen, will aber etwas 'Sicherheit' haben). Vielleicht Direkt.-Upload auf APKPure, falls ich sicherstellen kann, dass dann nur das echte signierte offizielle Apk im Umlauf ist. Aber da muss ich mich kurz reinlesen.


    Aktuell ist übrigens Vers. 2.0.16 (Zooming ist vor kurzem hinzugekommen und ich musste leider zwei Kartenabieter entfernen, da diese nicht mehr existieren).

    Hallo Zusammen,


    Viele von Euch kennen sicherlich noch das geniale GPS Trackanalyse Windows Programm von Blackwilly.


    Da ich unterwegs öfters mal in GPS-Dateien reinschauen muss, die aus diversen Gründen bei mir auf dem Smartphone landen, hatte ich im Corona Seuchenjahr eine sehr einfache Android GPS-Viewer App entwickelt. Die App gibt's immer noch und weil ich in all den Jahren keine App ausfindig machen konnte, die 3D Höhenprofile auf dem Smartphone generieren kann, habe ich meine App irgendwann erweitert und mich dabei, was die 3D Grafik betrifft, sehr von GPS Track Analyse inspirieren lassen.

    Die App ist wirklich nur eine sehr einfach gehaltene GPS Viewer App, die aber nahezu (fast) alle relevanten GPS Formate aus dem Sport- und Hiking Bereich unerstützt (GPX, TCX, Garmin Fit File Format, etc.) und hat sich bei mir im außer Haus Betrieb als GPS Viewer (auch für diverse andere Apps) bestens bewährt.


    Vielleicht kann ja der ein oder andere User etwas damit anfangen.


    Link zur App (Google Play Store)

    WRPElevationChart


    Kurzvorstellung auf meiner Webseite:

    Android Apps


    PS: Die App ist 100% Freeware (ad-free!) und es sind auch keine (versteckten) Tracker enthalten, da die App ein reines Sideprojekt ist. Daher sollte diese Werbung hier im Forum hoffentlich in Ordnung gehen. Anderenfalls bitte ich den Moderator diesen Beitrag wieder zu entfernen.


    Tot heißt das es schon lange keine anpassenden Updates mehr gibt.

    Die Kartendarstellung funktioniert nicht mehr. Ich kann nur vermuten, weil es zeitlich passt, das der Haupthintergrund war (GPS-Track-Analyse.net nutzte damals Google Maps zu Kartendarstellung) das Google irgendwann für die Nutzung von Maps Geld haben wollte. Besonders blöd für Freeware. Viele Softwareanbieter, auch die sich ihre Software/APPs bezahlen lasse, haben dann auf Maps verzichtet und nutzen freies Kartenmaterial wie OSM.

    Vielleicht war das neben dem Umstellungsaufwand ausschlaggebend.

    Hoffe das kommt jetzt nicht als Klugschwätzerei rüber, aber Google ist hier ausnahmsweise mal nicht der Grund (jedenfalls nicht was GTA betrifft):


    GTA hat Bing (MS) als Framework (Javascript basierte Library - die wiederum auf die Bing Maps API aufsetzt - für Online-Kartennutzung auf HTML-Basis) für die Kartendarstellung genutzt. MS hat dann irgendwann das Lizenzmodell als auch die API umgestellt. Freie Nutzung der Karten bis zu einem gewissen monatlichen bzw. bei PC Programmen und Apps täglichen Kontingent, was bei Freewareprogrammen, die sich oftmals einer großen Nutzerschaft erfreuen, unter Umständen schnell erreicht worden wäre. Darüber hinaus wurde aber eben auch die Bing API geändert, sodass GTA am Code an einigen Stellen hätte angepasst werden müssen.


    Ich hatte Blackwilli die Nutzung/Umstellung auf die freie Leaflet Library als Alternative empfohlen und ihm auch ein entsprechendes HTML-Gerüst gemailt. Da GTA aber sehr auf die Bing API aufbaute und damit sehr eng verzahnt war, wäre diese Umstellung auf eine komplette Neuprogrammierung des Kartenhandlings hinausgelaufen. Es kamen also einige Komponenten zusammen:


    Nachzulesen auch auf der noch vorhandenen GTA Landing Page: http://www.gps-track-analyse.de/


    Bei Google (Google Maps API) lief es zwar ähnlich ab und es stimmt größtenteils - von der nicht vorhandenen Verknüpfung mit GTA abgesehen - , was Du oben geschrieben hast, aber technisch betrachtet dreht sich hierbei erst mal alles um die Nutzung der API und weniger um die Karten als solches. Man kann die Google Maps API auch in Kombination mit freien OSM Karten nutzen, unterliegt dabei aber auch dem Google Maps Lizenzmodell, weil man deren Google Maps Dienst als Unterbau nutzt.


    Mit Leaflet gibt es eine freie Library, die eine Alternative zur Bing- oder Google Maps API darstellt, aber eben in sehr vielen Details anders programmiert werden muss.


    Die neuen Lizenzmodelle haben zweifsohne vielen Programmen - übrigens auch kommerziellen Programmen, wie sicherlich einige von uns am eigenen Leib verspürt haben dürften, als die beiliegende Software unserer damals genutzten Logger keine Karten mehr angezeigt haben und dann häufig auch nicht mehr angepasst wurden - die Kartenplattform entzogen, aber man sollte fairerweise noch erwähnen, dass sowohl Google als auch MS immer wieder darauf hingewiesen hatten, dass die Nutzung dieser Dienste gewissen Auflagen unterläge.


    Der Saft wurde nicht über Nacht abgedreht, sondern Google hatte anfangs sehr viel Nachsicht gezeigt, auch kommerziellen Apps gegenüber. Fast sämtliche der Logger Software, die meistens von asiatischen Herstellern beigesteuert wurde, setzte auf die Google Maps API auf und weil man da keine Energie mehr reinstecken wollte, können viele dieser damals beigepackten Programme keine Karten mehr darstellen (diese Logger haben suporttechnisch aber auch alle ihr End-of-Life erreicht, wenngleich ich meinen alten WBT-201 z.B. immer noch gelegentlich nutze :) ).


    PS: Man kann die Bing- oder Google Maps Karten nach wie vor kostenfrei nutzen und private User, die diese freien Kontingente nicht erreichen, können durch Eingabe eines API-Keys die Karten freischalten, worauf Strados im vorhergehenden Beitrag anspielt.

    Das hätte man in GTA womöglich aufgreifen können, ein Feld für diesen usergebundenen API-Key, den sich der User mittels Registrierung bei MS oder Google selbst holen müsste, aber Blackwilli hätte trotzdem EINIGES am Code umstellen müssen, denn es gab wie gesagt einen größeren Umbau in der API selbst, sodass der Javascript-Code entsprechend hätte überarbeitet werden müssen).

    So wie du es beschrieben hast hatte ich das auch immer gemacht und es funktionierte. Wenn ich jetzt unter Win11 "hinzufügen" auswähle bekomme ich folgende Fehlermeldung:

    Fehler beim Öffnen der Datei XYZ.gpx

    Der Wert darf nicht NULL sein.

    Parametername: Das Argument Array ist "Nothing".

    Kann das morgen gerne mal auf einem echten Windows 11 nachstellen.


    Aber vorweg, ich habe GTA in der Vers. 6.0.0.4 (https://www.heise.de/download/…s-track-analyse.net-56439) auf meinen Rechnern laufen. Du auch?


    Und ja, es gibt - wie bereits angemerkt - Probleme mit GPX-Dateien. Die von Dir geschilderte Fehlermeldung hatte ich allerdings noch nicht.

    Vielleicht kannst Du mir die betreffende GPX-Datei zukommen lassen, dann versuche ich das Zusammenfügen damit.

    Das wäre sehr nett.

    Also wenn Du dieses Vorgehen meinst:


    1.) GPX-Datei öffnen

    2.) Zweite GPX Datei hinzufügen (DATEI -> HINZUFÜGEN)

    3.) Verbinden (TRACK -> VERBINDEN)


    So hat das unter Windows 11 problemlos funktioniert (allerdings ein Windows 11 in einer VirtualBox, was aber dzbgl. keinen Unterschied machen sollte).


    Wie gesagt, ich nutz(t)e GTA primär als 3D-Viewer - bin in die ganzen Funktionen nie so tief eingestiegen -, weiß daher nicht, ob Du unter Zusammenfassen auf das abzielst, was ich gerade gemacht habe :) Ansonsten noch mal melden und ich versuche das gerne noch mal nachzustellen.


    PS: Ich habe nur bemerkt, dass sich GTA mit diversen GPX-Derivaten mitunter schwertut. Das sind aber meistens GPX-Dateien, die nicht 100% der GPX-Spec. entsprechen.


    [Blockierte Grafik: https://www.hrmprofil.de/pics/GTA_02.png][Blockierte Grafik: https://www.hrmprofil.de/pics/GTA_03.png][Blockierte Grafik: https://www.hrmprofil.de/pics/GTA_04.png]

    Also ich finde das sehr interessant. Falls das hier nicht erwünscht ist...ich habs mir notiert.


    Ein Frage am Rande da du ja Analyse kennst. Ich schaffe es nicht mehr damit mehrere Tracks zu einem zusammenzufassen. Liegt das Win11 oder an mir?

    Müsste ich mir anschauen. Ich verwende GTA eigentlich nur als Viewer. Da ich es aber auf allen meinen Rechnern installiert habe, kann ich das heute Abend gerne mal probieren. Melde mich dann nochmal.

    Danke. Bei GPS-Track-Analyse.net wird sie direkt mit angezeigt.

    Trotzdem, dieses Tool ist ne gute Alternatve zu GPS-Track-Analyse.net.

    GPS-Track-Analyse hat immer noch einen festen Platz auf meinen Rechnern. Schade, dass Blackwilli die Entwicklung dann eingestellt hat. Ich hatte mit ihm damals Kontakt und ihm die Leaflet Library inkl. eines Sample-HTML Gerüsts als Ersatz für die Bing Karten Api vorgeschlagen, aber der Umbau am Code wäre dann wohl doch zu aufwändig gewesen.


    Und vorab will ich fairerweise anmerken, dass ich schon lange nicht mehr hier im Forum schreibend aktiv gewesen bin, gerade aber auf diesen Thread gestossen bin und an einem ähnlichen Projekt - allerdings keine Freeware! - arbeite, das auch schon etliche Jahre auf dem Buckel hat und immer noch gepflegt wird. Sollte dieser Beitrag daher als Schleichwerbung rüberkommen, dann bitte ich die Mods diesen zu entfernen. Böse Absichten stecken meinerseits nicht dahinter!, daher will ich glech Ross und Reiter benennen.


    Wie eingangs gesagt hat GPS-Track-Analyse immer noch einen festen Platz auf meinen Rechnern, zuletzt gab es aber an und an Probleme auf meinem Windows 11 System (sporadische Abstürze).

    Daher habe ich in meinem Programm jetzt eine 3D-Höhenprofilansicht aufgegriffen, die sich sehr an Blackwillis GPS-Track-Analyse anlehnt. Diese 3D-Ansicht stand schon immer auf meiner ToDo-Liste, allerdings konnte ich GPS-Track-Analyse in mein Programm als externen Viewer einbinden - nach erfolgter Rücksprache und Okay seitens Blackwilli - sodass ich nie einen Anlass sah, dieses Nebenprojekt anzupacken. Das Programm zielt eher auf die Sportdaten und Trackanalyse ab, die neue 3D-Ansicht ist nur ein Nebenaspekt.


    Falls es interessiert, ich habe die Entwicklung in meinem Bog festgehalten und in diversen Beitragen auf meiner Webseite und in meinem Blog mehrmals explizit auf Blackwillis genialen GPS-Track-Analyse verwiesen.


    https://wrpsoft.blogspot.com/2…-uber-den-prototypen.html

    https://wrpsoft.blogspot.com/2…zanleitung-des-neuen.html


    Und again, sollte das jetzt als Schleichwerbung rüberkommen, dann bitte den Beitrag löschen. Mir ist durchaus bewußt, dass solch ein Eigenwerbung etwas kritisch zu sehen ist, aber primär ist diese Auswerterei ein Hobby von mir und den ersten Linkhinweis erachte ich als recht informativ, weil er die Planungs- und Umsetzungsschritte dieses Sideprojects 3D-Chart skizziert.

    Sollte Garmin zwischendurch etwas an der Hardware geändert haben, wie schon bei anderen Geräten, gäbe es inzwischen mindestens zwei Typen, die auch nicht zu 100% kompatibel wären. Ich frage mich, wie man das mit einer Software in den Griff bekommen will, es sei denn, man legt ausnahmsweise mal die Karten auf den Tisch und nennt genau die Seriennummern der betroffenen Geräte. Dann könnte man mit einem "Spezialpatch" etwas ausrichten.


    Wenn Garmin an der Hardware Änderungen vorgenommen haben sollte, was in der Computerbranche und Mikroelektronik ja häufiger vorkommt (unterschiedliche Platinen Revisionen), dann waren sie wohl (hoffentlich) schlau genug, eine Revisionsnummer zu implementieren, die unabhängig von der Firmware abgefragt werden kann. Dann wäre es auch kein Problem, ein und die gleiche Firmware an die bestehenden Hardwarevarianten anzupassen. Dann genügte eine einfache Switch/Case-Abfrage. Meine Nachbar hat bei seinem Neugerät das gleiche Problem und wenn Garmin verlautbaren läßt, dass eine neue Firmware das Problem beheben wird, dann wird es womöglich darauf hinauslaufen, dass die Firmware intern bestimmte Revisionsnummern auswertet und entsprechende angepasste Funktionen aufruft.