WRPElevationChart ist eine sehr leichtgewichtige GPS Viewer App für Android Smartphones.
Frage: Es gibt bereits sehr viele GPS Viewer Apps. Warum soll ich gerade diese nutzen?
Dem εxodus Webservice (Datenschutz-Audit-Plattform für Android-Anwendungen) könnt ihr zumindest entnehmen, dass in WRPElevationChart keine (bekannten) Tracker gefunden wurden: https://reports.exodus-privacy.eu.org/en/reports/497813/
"Die Integration von Online-Karten (wie den Kacheln der OpenStreetMap-Server) ist datenschutzrechtlich der kritischste Punkt überhaupt für eine sonst reine Offline-App.
Die App ist bewusst sehr einfach gehalten und nicht mit (zu vielen) Funktionen überladen, was einer einfachen Bedienbarkeit sehr entgegenkommen dürfte. Aber natürlich gibt es auch bei dieser App immer mal wieder die ein oder andere User-(An)frage.
Diese FAQ soll daher - zusätzlich zum offiziellen deutschprachigen Manual - eine kleine Hilfestellung, vor allem bzgl. immer wieder auftretender Fragen, sein. Eine weitere Hilfestellung wäre dann auch noch dieser englischsprachige Blogbeitrag: What can you do with WRPElevationChart (a lightweight GPS viewer app for Android)
Vorweg: Einige Fragen und Fehlerquellen lassen sich nicht vermeiden, weil jeder Programmierer von seinem spezifischen Blickwinkel beeinflusst wird und manche Fragestellungen einfach nicht auf seinem inneren Monitor hat. Andere Fragen sind vom Fragesteller wohl bewusst provokativ gehalten, (fast) jeder Entwickler wird das kennen. Ich habe jetzt einmal alles aufgeschlüsselt, was im Laufe der Zeit so an Fragen angefallen ist (auch die 'Unangenehmen' , wobei einige auch schon mal in Richtung aktives 'Trollen' gehen dürften. Letzteres könnte man ignorieren, ist aber auch ein Zeitfaktor, weil ich diese Mails/Anfragen ja erst einmal lesen muss, um den womöglichen 'Troll'-Charakter zu erkennen):
- erstens, um dem Vorwurf entegegenzutreten, ich würde (unangenehmen) Fragen aus dem Weg gehen
- zweitens, um einmal zu skizzieren, mit welchen Sachverhalten man sich manchmal auseinandersetzen muss
- und drittens, um vielleicht zukünftig zu verhindern, dass weiterhin Anfragen bzgl. einer 'Kooperation' an mich herangetragen werden, die letztlich nur dazu dienen sollen, eine kostenlose App - gegen Bezahlung - zu vermarkten.
[Achtung]: Mitunter sind in diesem Beitrag auch einige YouTube Videos verlinkt. Ruft man diese Videos auf, so landet man direkt auf der YouTube Plattform und kann von YouTube getrackt werden!
FAQ (Frequently Asked Questions)
In eigener Sache: WRPElevationChart ist derzeit sehr stark auf Nutzung auf einem Smartphone-Display ausgerichtet. Zwar lässt sich die App natürlich auch auf Tablets nutzen, die normalerweise eher horizontal ausgerichtet betrieben werden, aber beim Design des GUI habe ich mich doch sehr auf eine vertikale Ausrichtung fixiert (das 3D-Chart wird in der horizontalen Ausrichtung z.B. bewusst ohne Karte angezeigt). Ob ich das zukünftig noch ändern/optimieren werde, weiß ich nicht. Primär nutze ich die App auf dem Smartphone als kleines Immer-Dabei-GPS-Tool meiner Wahl, um einen erweiterten Blick auf GPS-Daten werfen zu können. Gerade in Kombination mit anderen GPS-Apps ist das für mich sehr sinnvoll.
Allgemeine Fragen:
Frage: Warum hat die App so einen merkwürdigen Namen?
Antwort: Weil mir anfangs kein besserer Projektname eingefallen ist und eine nachträgliche Änderung des App-Namens im Google Play Store relativ kompliziert ist. Auch macht es keinen Sinn, die App GPS Viewer XY zu nennen, weil es davon bereits genügend im Play Store gibt.
Am Rande erwähnt: alle meine eigenen im Play Store gelisteten Apps fangen derzeit mit der Wortkennung WRP an.
Am Rande erwähnt: alle meine eigenen im Play Store gelisteten Apps fangen derzeit mit der Wortkennung WRP an.
Antwort: Vielleicht, weil etwas Abwechslung im Leben manchmal gut tut :-) Ja, es gibt sehr viele dieser Apps im Google Play Store und alle sind auf ihre Weise auch sehr gut.
Diese App wurde primär an meinen eigenen Workflow angepasst, ursprünglich stand die Browserfunktion im Mittelpunkt der Entwicklung, da ich eine Möglichkeit suchte, unkompliziert in die vielen GPS-Dateien auf meinem Smartphone hineinzuschauen. Das macht diese App sehr gut, da der GPS-Daten Browser ein Hin- und Herblättern durch die vorhandenen GPS-Dateien in einem frei zuordenbaren Verzeichnis ermöglicht. Darüber hinaus erlaubt mir diese App auch eine mobile GPS Track Analyse. Normalerweise mache ich das Zuhause auf dem PC, aber das Smartphone ist halt fast immer greifbar und daher zum schnellen Analysieren bestens geeignet.
Letzteres ist auch der Grund, weshalb ich zuletzt einige doch sehr spezielle Datenreihen aufgegriffen habe, die man m.W. mit den meisten Android Apps derzeit nicht einsehen kann ('GPS Accuracy', 'Battery Level', etc.). Das ist alles nicht zwingend notwendig, manchmal ist es aber ganz praktisch, wenn man auch unterwegs in diese Datenreihen hineininsehen kann und dafür keinen PC benötigt.
Frage: Ich hätte die App gerne in meiner Landessprache übersetzt.
Antwort: WRPElevationChart ist derzeit in deutsch, englisch und dank eines polnischen Users auch in polnisch lokalisiert. Weitere Sprachen kann und würde ich gerne aufgreifen, allerdings müssten User die Übersetzungen kostenfrei beisteuern. Gerne könnt ihr mich anmailen, falls ihr das in Angriff nehmen wollt. Da ich mit der App aber kein Geld verdiene und es ein reines Hobbyprojekt ist, kann ich für die Übersetzungsarbeiten leider keinen Obolus entrichten. Auf Anfragen professioneller Übersetzungsbüros - die es bereits gab - werde ich daher weiterhin nicht antworten.
Wer mir bei der Übersetzung helfen will/kann, die Datei mit den englischen Strings kann hier eingesehen und heruntergeladen werden: https://www.hrmprofil.de/Down/strings_eng.xml
Frage: Die App wird als Freeware deklariert. Warum ist dann der Source Code nicht einsehbar?
Antwort: Weil Freeware nicht zwangsläufig Open Source bedeutet. Diese App nutzt einige Funktionen aus einem eigenen kommerziellen Projekt und ich kann/will den Source Code deswegen nicht offenlegen. Freeware bedeutet ja nicht zwangsläufig Open Source.
Siehe auch den Wikipedia Artikel bzgl. Freie Software vs. Freeware: https://de.wikipedia.org/wiki/Freie_Software
Frage: Dann kommt die Nutzung dieser App für mich nicht in Frage, da ich nur Apps verwende, bei denen ich mich selbst davon überzeugen kann, dass sie sauber sind. Das geht nur bei Open Source Software!
Antwort: Die App ist frei - kostenfrei als auch werbefrei - und wird frei bleiben - da ein reines Nebenprojekt - bei dem ich aber, wie bereits gesagt, auch eigenen Code aus einem größeren 'kommerziellen' Projekt verwende. Insofern ist die Offenlegung des Sourcecodes auf github für mich derzeit kein Thema, das ich aufgreifen kann/will. Bei F-Droid, das mir von einem User, der diese Frage an mich herangetragen hat, empfohlen wurde, verhält es sich ähnlich (bzw. wird dort sogar noch strenger gehandhabt).
Mehr will/kann ich dem User derzeit nicht entgegenkommen. Wenn diese App dem ein oder anderen User hilfreich ist, so freut mich das natürlich, falls nicht, so ist das aber auch okay. Ich danke für Euer Verständnis.
Frage: Warum investierst Du soviel Zeit in dieses - wirtschaftlich betrachtet (sinnlose) - Projekt? Wo ist der Haken?
Antwort: Weil's mir Spaß macht und ich die App selbst sehr gut nutzen kann. Ob es sinnvoll ist, in die Dokumentation und in diese FAQ sonderlich viel Energie zu verschwenden, ist sicherlich eine berechtigte Frage. Dazu kann ich nur entgegnen, wenn man etwas tut, dann sollte man es schon richtig machen. Android Programmierung ist generell relativ zeitaufwendig, gerade dann, wenn man Apps im Google Play Store veröffentlicht. Dann fällt es aber auch nicht mehr groß ins Gewicht, wenn man für diese administrativen Dinge noch etwas zusätzliche Zeit aufbringen muss. Es muss halt im gesunden Rahmen bleiben.
Frage: Ich möchte die App gerne mit anderen Apps verknüpfen und in meinen allgemeinen Workflow einbinden. Wird die App wirklich dauerhaft 'free' bleiben?
Antwort: Ich verstehe zwar den tieferen Sinn hinter der Frage nicht so richtig, aber ja, es ist nicht geplant, die App in der jetzigen Form kommerziell zu vermarkten! Das heißt nicht, dass - basierend auf dem jetzigen Programmcode - nicht doch einmal eine Bezahl-App aus diesem kleinen GPS Viewer Projekt resultieren könnte, aber WRPElevationChart wird auch in Zukunft eine (werbe)freie App bleiben! Anders formuliert: WRPElevationChart wird eine freie App bleiben, möglicherweise wird es aber in ferner Zukunft einmal eine andere (eigenständige) App geben, die nicht (werbe)frei sein wird und Code aus diesem Projekt verwenden wird.
Das habe ich mittlerweile aber an diversen Stellen und Orten wirklich oft genug ausgeführt.
Es spricht aber trotzdem nichts dagegen, die App userseitig etwas zu unterstützen. Wie ihr das machen könnt, könnt ihr ein paar Zeilen weiter unten lesen. Oder anders gesagt, dafür, dass die App mittlerweile im höheren dreistelligen Bereich installiert wurde, ist das allgemeine Feedback und der allgemeine Usersupport doch recht bescheiden. An meinen Plänen ändert das aber nichts!
Frage: Mir gefällt die App sehr gut, auch weil sie keinerlei störende Werbung enthält und sehr kompakt ist. Gibt es eine Möglichkeit, das Projekt in irgendeiner Form zu unterstützen?
Antwort: Das freut mich zu hören. Ja, es gibt natürlich schon einige Möglichkeiten, dem Projekt etwas Unterstützung zukommen zu lassen. Hier ein paar Anregungen:
- eine Übersetzung beisteuern (falls ihr eine Sprache sprecht, die die App bisher nicht unterstützt). Den Zeitaufwand dafür würde ich für einen Muttersprachler, der in der Lage ist, die englischen Strings, ohne Hilfe von Außen, zu übersetzen, auf ca. maximal 1-2 h einschätzen!
Hier kann die Datei mit den englischen Strings eingesehen und heruntergeladen werden: https://www.hrmprofil.de/Down/strings_eng.xml - die App mittels Mundpropganda etwas bekannter zu machen
Ich verfolge mit dieser App kein konkretes Ziel, aber natürlich macht das öffentliche Bereitstellen einer App mehr Spaß, wenn das userseitig irgendwie erwidert wird. - die App im Google Play Store positiv bewerten (eine echte Rezension wäre natürlich noch besser)
Aber Achtung, Bewertungen unterstützen uns App-Entwickler nur, wenn sie wirklich positiv ausfallen (am besten volle Punktzahl). Sollte Euch die App weniger überzeugen, aber auch nicht so schlecht sein, dass ihr andere davor warnen müsst, dann wäre es besser, gar keine Bewertung abzusetzen, da durchschnittliche Bewertungen vor allem bei kleineren Nischen-App-Projekten massivst Einfluß auf die Trefferquopte bei der Suche haben. Muss jeder mit sich selbst ausmachen. - Ggfs. könnt ihr auch mal einen Werbebanner auf meiner Projekt-Webseite anklicken oder bei Amazon einen Einkauf tätigen.
Heißes Thema, I know. Ich werde die App auch weiterhin werbefrei halten, es gab aber schon kritische Stimmen, die meinten, dass die App zu sehr mit meiner 'kommerziellen' Webseite verzahnt wäre und daher gar nicht werbefrei sei. Wie auch immer, ich bin jetzt mal so frei, auf meine Projektseite* hinzuweisen: Unterstützung des TrainingLab Projekts
* Das TrainingLab Projekt würde ich als ein ambitioniertes Hobbyprojekt beschreiben, inwieweit man das als kommerziell abtun kann, da kann man sicherlich unterschiedlicher Meinung sein. Ich will's aber auch nicht unter den Teppich kehren.
Datenschutz:
Frage: Stichwort 'Haken', woher weiß ich denn, dass die App wirklich sauber ist und auf meinem Smartphone keine bösen Sachen macht?
Antwort: Diese Frage geht schon wieder in eine bestimmte - vorwurfsvolle - Richtung und wurde von mir bereits in der Antwort zum Thema Open Source thematisiert. Wenn ich mich wirklich für das Bereitstellen dieser App rechtfertigen soll, dann ist das für Dich einfach nicht die richtige App!
Dennoch möchte ich das Folgende noch anmerken. Auf meiner Habenseite steht vor allem meine Projektseite (https://www.hrmprofil.de/), die bereits seit Ende der 90'ziger Jahre (!) unter dieser Adresse im Netz präsent ist. Ich bin daher nicht anonym, sondern stehe mit meinem guten Ruf und meinem Namen hinter den von mir veröffentlichten Programmen und Apps. Auch habe ich viele Jahre mit einigen namenhaften Firmen aus der Sportbranche zusammengearbeitet. Falls das als Legitimation für die Veröffentlichung einer kleinen Android App nicht ausreicht, dann kann ich es leider nicht ändern (so leid mir das auch tut)!
Frage: Wieso fordert diese App soviele unnötige Rechte ein?
Antwort: Wie bereits im Google Play Store - und an vielen weiteren Stellen - vermerkt, fordert diese App jene Rechte ein:
- Schreib - und Leserechte [WRITE_EXTERNAL_STORAGE, READ_EXTERNAL_STORAGE]
a) zum optionalen Speichern der Höhenprofildaten,
b) zum Anfertigen einer optionalen Screenshot-Grafik benötigt, falls man die Teilen Funktion nutzen möchte, die nichts anderes macht, als eine Screenshot-Grafik Datei an eine andere App zu übergeben
c) für das Cachen der Karten-Tiles (OSMDroid Library)
d) für eine soweit möglich reibungslose Funktion des Browsermodus (im Browsermodus muss die App auf ganze Verzeichnisse zugreifen können - unter anderem auch auf den externen Speicher - sonst ergibt dieser Browsermodus nämlich keinen Sinn)
e) für das unkomplizierte Einbinden optionaler Mapsforge Karten und Themes (*.map und *.xml Dateien).
- Standortdaten [ACCESS_COARSE_LOCATION, ACCESS_FINE_LOCATION]
Werden NUR benötigt, falls man die 'JumpTo'-Home Funktion in der Kartenansicht nutzen will, die nichts anderes macht, als die Karte auf die zuletzt bekannte Lokation zu zentrieren! Diese App beinhaltet (derzeit) KEINE GPS-Logging (Tracking) Funktionaliät!
- Netzwerkrechte [INTERNET, ACCESS_NETWORK_STATE]
Werden zum Herunterladen der Karten Tiles benötigt.
Je nach verwendeter Android Version kann man der App diese Rechte auch entziehen und je nach Anwendungsfall wird die App auch ohne diese Rechte - zumindest eingeschränkt - funktionieren. Netzwerkzugriffe sind aber zwingend, da die Karten(Tiles) über das Internet heruntergeladen* werden müssen!
* Die Kartentiles werden zwar intern gecached, sodass die App nach dem Herunterladen der Kartentiles eine Zeit lang offline genutzt werden kann. Nach einiger Zeit werden diese Cachedaten von der App aber wieder gelöscht, da die meisten Anbieter keine dauerhafte Speicherung der Tiles zulassen, sondern nur ein temporäres Cachen der Tiles gewünscht wird!
* Die Kartentiles werden zwar intern gecached, sodass die App nach dem Herunterladen der Kartentiles eine Zeit lang offline genutzt werden kann. Nach einiger Zeit werden diese Cachedaten von der App aber wieder gelöscht, da die meisten Anbieter keine dauerhafte Speicherung der Tiles zulassen, sondern nur ein temporäres Cachen der Tiles gewünscht wird!
Frage: Mir ist aufgefallen, dass seit Version 2.0.75 im Google Play Store aufgeführt wird, dass diese App bestimmte Datentypen (Geräte- oder andere IDs) an Dritte weitergeben kann. Ich finde das sehr bedenklich, zumal Du angegeben hast, dass die App keinerlei Tracking-Funktionalität aufweisen würde. Ist das nicht ein massiver Widerspruch?
Antwort: WRPElevationChart tauscht keinerlei Daten aktiv mit anderen Diensten, Apps oder was auch immer aus. Allerdings nutzt diese App Online (OSM)-Karten und beim Herunterladen der entsprechenden Kartentiles kann der genutzte Kartenserver die IP-Adresse einsehen. In der verknüpften Datenschutzerklärung (https://www.hrmprofil.de/apps/datenschutz_WRPSPToolbox.html) wird das ausführlich behandelt.
Laut AI (Google Gemini und Microsoft Copilot) soll/muss das neuerdings explizit im Google Play Store entsprechend deklariert werden, sonst könnte es zukünftig Probleme mit der App-Freigabe geben.
Hier meine Unterhaltung mit Google Gemini:
Sobald die App Kacheln von einem Server nachlädt, baut das Gerät des Nutzers eine direkte Verbindung zu den OSM-Servern (oder Kachel-Providern) auf. Dabei wird zwingend die IP-Adresse des Nutzers sowie der User-Agent (und damit oft das Smartphone-Modell) an die Server der OpenStreetMap Foundation (OSMF) übermittelt. Da IP-Adressen in der EU als personenbezogene Daten gelten, hast du völlig recht: Das muss explizit aufgeschlüsselt werden.
Google unterscheidet sehr strikt zwischen Daten, die deine App selbst sammelt, und Daten, die durch Drittanbieter übertragen werden.
- Deine Pflicht: Im Data Safety Formular (Datensicherheit) der Google Play Console musst du angeben, ob Daten gesammelt oder geteilt werden.
- Googles Definition: Wenn deine App native Web-Abfragen an die OSM-Server schickt, um Kacheln zu laden, gilt die IP-Adresse im Google-Sinn oft als "gesammelt/übertragen".
- Die Gefahr: Wenn ein automatisierter Google-Prüfbot beim Scannen deiner App sieht, dass die App im Hintergrund HTTP/HTTPS-Verbindungen zu externen Tile-Servern aufbaut, das Data Safety Formular aber auf "Die App sammelt oder teilt keine Nutzerdaten" steht, kann das zu einer Ablehnung des Updates (Reject) wegen widersprüchlicher Angaben führen.
- Lösung: In der Play Console unter Datensicherheit den Punkt "IP-Adresse" (unter Gerätekennungen/Sonstige Daten) als erhoben/übertragen deklarieren und angeben, dass dies ausschließlich für die App-Funktionalität (das Laden der Karten) notwendig ist."
Und hier meine kurze Unterhaltung mit Microsoft Copilot betreffend des Themas:
"Ja, du musst den OSM‑Tile‑Abruf im Data‑Safety‑Formular indirekt deklarieren – über die IP‑Adresse als „übertragene Daten“.
Nicht weil du etwas falsch machst, sondern weil Google jede externe HTTP‑Verbindung als Datentransfer wertet."
Fazit: ich weiß natürlich, dass sehr viele GPS-Karten Apps diese Datenweitergabe nicht deklarieren (ich habe das bisher auch nicht gemacht) und womöglich wird Google dbzgl. auch nicht eingreifen. Da ich diese freie und datenschutzkonforme App aber nur hobbymäßig entwickle und mein Zeitfenster dafür doch begrenzt ist, habe ich mich entschieden, diesen Punkt in der Google Play Entwickler Konsole zu deklarieren. Primär deswegen, damit ich später nicht mit irgendwelchen Google (Prüf)Bots die Freigabe meiner App neu verhandeln muss. Das kann nämlich sehr schnell in zusätzlicher Arbeit ausarten, wenn man Google im Nachhinein neu überzeugen muss, dass die App sauber ist.
Abschließend kann ich nur sagen, dass ich selbst überhaupt kein Interesse habe, mit dieser App bewußt oder unbewußt Daten einzusammeln oder anderen Anbietern versteckt irgendwelche Daten zukommen zu lassen. Das betrifft übrigens auch unser größeres TrainingLab Projekt, das quasi mit ein Grund ist, dass es WRPElevationChart überhaupt gibt, weil ich einiges an bestehendem Code - oder besser gesagt Algorithmen - in diese App tranferieren konnte: Bewegungsdaten, was hat es damit auf sich?
Distribution:
Antwort: Weil der Google Play Store nun einmal die offizielle Bezugsquelle für Android Apps ist. Ich habe gesehen, dass die App auch auf diversen alternativen APK-Archiven angeboten wird. Ich selbst kann das aber nicht managen und möchte auch nichts aktiv auf diese APK-Archive hochladen, weil ich dann gar keine Kontrolle mehr habe. Ich kann daher nur meine offiziellen Apps, die über den Google Play Store bezogen wurde, aktiv supporten.
Frage: Ich kann und will den Google Play Store nicht nutzen.
Antwort: Siehe oben. Wir drehen uns in dieser Frage leider im Kreis.
Frage: Wir bieten ihnen (günstig) an, ihre App bekannter zu machen.
Antwort: Diese App ist Freeware (man kann auch sagen, es ist ein reines Hobbyprojekt). Ich glaube nicht, dass es unter diesen Umständen für mich sinnvoll wäre, Geld zu investieren, um dieses Hobbyprojekt bekannter zu machen.
Mehr möchte ich dazu gar nicht schreiben, außer, dass es in letzter Zeit einige sehr krude Anfragen gab (mit dem vermeintlichen Ziel, dieses Projekt bekannter zu machen).
Natürlich hätte ich nichts gegen positive Mundpropaganda einzuwenden und ich wäre auch nicht abgeneigt, wenn der ein oder andere User oder Blogger auf dieses kleine Projekt in seinem Blog hinweisen würde. Allerdings will ich mit dieser App nicht die Welt verbessern, insofern kann/muss ich damit leben, dass dieses Projekt auf Dauer vielleicht etwas underrated* bleiben wird.
Daran ändert übrigens auch der Sachverhalt nichts, dass meine kostenlosen und werbefreien Apps zusätzlich auf meiner privaten TrainingLab Projektseite aufgelistet sind und damit - laut Aussage Dritter - einen kommerziellen Charakter aufweisen (Aha!).
* laut Aussage einer Agentur, die mir ihre Dienste - gegen eine Vergütung versteht sich - angeboten hat.
Und ja, mir ist bewusst, dass die Downloadzahlen dieser App im Google Play Store relativ überschaubar sind, auch was die Anzahl der Rezensionen betrifft. Würde ich das zum Gradmesser machen, dann würde ich dieser App aber sicherlich in gänzlich anderer Form unterhalten und vermarkten - oder es wahrscheinlich ganz sein lassen.
Mit anderen Worten, ich nutze die App selbst, richte sie primär an meinen eigenen Workflow aus und wenn andere daran Gefallen finden und vielleicht auch mal eine positive Bewertung zum Besten geben, dann freut mich das -> das ist/war aber sicherlich nicht die Antriebsfeder für dieses Projekt und ich habe bestimmt nicht vor, diese App mittels bezahlter Werbung künstlich zu pushen!
Frage: Wir sind eine Agentur, die sich auf die Distribution von Apps spezialisiert hat und möchten ihre App gerne in unser Portfolio aufnehmen.
Antwort: Siehe oben. Wenn ihr einer kostenlosen App kostenfrei etwas unter die Arme greifen wollt, dann können wir uns gerne in Verbindung setzen. Wenn ich allerdings für diese Dienstleistung zahlen, die Verwertungsrechte dieser App im Gegenzug abtreten oder quasi als Gegenleistung (versteckte) Werbetracker implementieren soll, dann besteht meinerseits kein Interesse an einer Kontaktaufnahme!
Einer explizten Auftragsprogrammierung gegenüber bin ich immer offen, nur trägt im Normalfall der Auftrageber die Entwicklungskosten und nicht der Auftragnehmer!
Importe:
Frage: Meine Daten können nicht korrekt importiert werden (hier wurde sich zwar auf GPX Dateien bezogen, aber prinzipiell kann das alle Importformate betreffen).
Antwort: Das kann leider viele Ursachen und Gründe haben. Letztlich kann ich dazu nur etwas sagen, wenn ihr mir die betreffenden GPS-Daten zukommen lasst und ich mir das Zusammenspiel mit diesen Daten im Debugger ansehe. Im Allgemeinen sind die Import-Parser sehr robust und leistungsstark, aber es kann immer mal Importdateien geben, die aus welchen Gründen auch immer - nicht korrekt geparst werden können. Hier muss dann der Debugger ran!
Frage: Meine Indoor Aufzeichnung (Fit Activity File) kann nicht importiert werden. Die App wird als Fit File Viewer beworben.
Antwort: WRPElevationChart ist primär eine GPS Viewer App. Zwar kann die App Fit Files importieren, allerdings nur, wenn diese GPS-Koordinaten enthalten. Das ist bei reinen Indoor-Aktivitäten häufig nicht der Fall. Das gilt auch für ältere Sportuhren, die Aktivitäten ohne GPS-Koordinaten protokollieren! Mit anderen Worten, WRPElevationChart ist keine Fit File Viewer App im engeren Sinne, sondern eine GPS Viewer App, die auch GPS basierte Fit Files importieren kann: GPS Koordinaten sind daher essentiell!
Ich spiele mit dem Gedanken, vielleicht irgendwann eine reine Sportanalyse-App zu entwickeln, die sich etwas an das TrainingLab Projekt anlehnen wird. Das sind derzeit aber noch ungelegte Eier und das wird auf eine vollkommen neue, deutlich anders gestaltete App hinauslaufen, da die jetzige Darstellungsart bei vielen unterschiedlichen Datenreihen nicht zielführend wäre. Dann werde ich nämlich um eine segmentierte Anzeige der Datenreihen nicht umhin kommen und das können die hauseigenen Analyse-Apps der Hersteller (Garmin Connect App, Wahoo Element App, etc.) ja selbst sehr gut.
WRPElevationChart wird weiterhin eine reine, einfach gehaltene GPS Viewer App bleiben (mit allen sich daraus ergebenden Vor- und Nachteilen).
Frage: Ich habe einige GPX-/TCX-Dateien, die mehrere Tracks enthalten. Leider kann ihre App immer nur einen Track importieren.
Antwort: Das ist derzeit leider per Design so programmiert. Derzeit wird immer nur ein Track bzw. eine Route importiert. Sofern mehrere Tracks/Routen in einer Importdatei eingebettet sind, wird daher nur der/die jeweile erste Track/Route importiert.
Ob ich die App dahingehend erweitern werde, dass sie auch Multi-Track-Importdateien korrekt handhaben kann, vermag ich derzeit noch nicht zu sagen.
Exporte:
Frage: Wenn ich meine zuvor importierten Daten exportiere, werden einige Datenreihen nicht berücksichtigt bzw. nicht exportiert. Was mache ich falsch?
Antwort: WRPElevationChart ist eine GPS Viewer App, aber keine GPS-Datenkonverter App (auch wenn man die App dazu nutzen kann, Daten von einem ins andere Format zu konvertieren). Intern werden derzeit nur bestimme Datenreihen verwendet, andere werden nicht genutzt und daher beim Export auch nicht berücksichtigt:
Bei FitFile Exporten werden jene Datenreihen in die Recorder Messages geschrieben:
RecordMesg recordMesg = new RecordMesg();
recordMesg.setTimestamp(new DateTime(timestamp));
recordMesg.setPositionLat(latitude);
recordMesg.setPositionLong(longitude);
recordMesg.setDistance(distance * 1000);
recordMesg.setSpeed(speed);
recordMesg.setAltitude(altitude);
encode.write(recordMesg);
Wobei ich noch anmerken will/muss, dass der Fit File Export in dieser App derzeit eigentlich nur zur internen Datenübergabe an andere Apps angedacht ist. Das Fit File Format unterstützt dermassen viele spezifische Datenreihen, deren Übernahme/Bereithaltung in einer einfachen GPS-Viewer App keinen Sinn machen.
Bei GPX- und TCX-Exporten verhält es sich ähnlich, allerdings sind diese beiden Formate bzgl. der dort unterstützen Datenreihen reglementiert, sodass dieses Problem bei diesen Formaten normalerweise nicht aufschlagen dürfte.
Kurze Rede, langer Sinn: Du machst also nichts falsch!
Frage: Was ist der Unterschied zwischen dem Garmin Course (FIT) Export und dem Garmin Course erzeugen Export?
Anwort: Die erstgenannte Exportfunktion (Garmin Course) ist nur verfügbar, wenn sogenannte Course-Files - also Importdateien, die Turn-by-Turn Anweisungen enthalten - importiert wurden. Diese werden dann bei einem Export quasi eins zu eins im Fit File (Course) Format weitergereicht.
Mit der zweiten Variante (Garmin Course erzeugen) können Turn-By-Turn Anweisungen automatisch generiert werden, die dann als Fit Course-File exportiert werden. Dies kann bei älteren Bike-Computern sinnvoll sein, die noch keine echte Navigation unterstützen, sondern nur vorgefertigte Routen mit eingebetteten Turn-by-Turn Anweisungen abspielen können.
Da die Course-Anweisungen rein rechnerisch anhand der Winkelgeraden zwischen zwei Punkten berechnet werden und aktuelle Bike-Computer mittlerweile fast durch die Bank eine echte Navigation ermöglichen, ist der Praxisbezug dieser Funktion heutzutage sehr begrenzt! Siehe auch: https://wrpsoft.blogspot.com/2023/03/brouter-basierte-gpx-routen-mit-turn-by.html
Frage: Die App unterstützt mittlerweile Runden-Marker. Bei GPX-Exporten werden diese manchmal falsch gespeichert bzw. könnnen bei einem Wiederimport nicht mehr korrekt auf der X-Achse dargestellt werden. Alle in der GPX-Datei gepeicherten Marker (Wegpunkte) liegen auf der 0-km Position. Wie kann ich das verhindern?
Antwort: Soweit ich das nachvollziehen kann, betrifft das nur GPS-Daten ohne Zeitstempel. Die von WRPElevationChart verwendeten Rundenmarker basieren eigentlich auf Zwischenzeiten (Laps), die prinzipbedingt neben dem Distanzwert auch einen Zeitstempel aufweisen.
Das GPX-Format unterstützt bei Wegpunkten (wpts) - neben den GPS-Koordinaten und einigen anderen Daten - nur das Speichern eines Zeitstempels (aber keine mit dem Wegpunkt assozierten Distanzwerte). Das hat zur Folge, dass bei Reimporten aufgrund des fehlenden WPT-Distanzwertes, bei GPS-Daten ohne Zeitstempel, kein Bezug mehr hergestellt werden kann und die Wegpunkte daher nicht mehr korrekt positioniert werden können. Anders ausgedrückt: Zwischenzeiten Marker können ohne dazugehörende Zeitstempel nicht in einfache GPX-Wegpunkte transferiert werden.
Das GPX-Format unterstützt bei Wegpunkten (wpts) - neben den GPS-Koordinaten und einigen anderen Daten - nur das Speichern eines Zeitstempels (aber keine mit dem Wegpunkt assozierten Distanzwerte). Das hat zur Folge, dass bei Reimporten aufgrund des fehlenden WPT-Distanzwertes, bei GPS-Daten ohne Zeitstempel, kein Bezug mehr hergestellt werden kann und die Wegpunkte daher nicht mehr korrekt positioniert werden können. Anders ausgedrückt: Zwischenzeiten Marker können ohne dazugehörende Zeitstempel nicht in einfache GPX-Wegpunkte transferiert werden.
Beispiel (Wegpunkt GPX Datei):
<wpt lat="50.330386666" lon="8.533381666"><ele>178.466033</ele><speed>0.23004627227783203</speed><time>2023-06-07T16:53:00.870Z</time><name>WPT00005</name><cmt>WPT00005</cmt><desc>WPT00005</desc><sat>5</sat></wpt>
Das Problem lässt sich also technisch bedingt nicht vermeiden (auch wenn man behelfsmäßig den Wegpunkt anhand der GPS-Koordinaten positionieren könnte -> das funktioniert dann aber bei Rundkursen nicht mehr 100% zuverlässig).
Abhilfe: den Track entweder im WRPElevationChart eigenem XML-Format speichern oder - ab Vers. 2.0.70 - im TCX-Format exportieren. Beim TCX-Format kann man neben dem Zeitstempel auch einen Distanzwert in der Lap-Struktur einbetten (und dann passt es wieder, weil ein echter Bezugspunkt existiert).Frage: Noch mal zum Thema FIT-Export. Könntest Du nicht einen echten FIT File Activity Export implementieren? Das würde die App merklich aufwerten, da die App dann eine echte Sportdateiformat-Konverter App wäre.
Anwort: Das Fit File Format ist ein Container-Format, das mittlerweile so viele Parameter (Datenreihen) unterstützt, die für eine einfache GPS-Trackviewer letztlich keinen Sinn ergeben (Running- oder Cycling-Dynamics Daten, spezielle Developer-Messages, etc.). WRPElevationChart müsste also viele dieser Datenreihen intern verwalten (Speichern und Mitschleppen), obwohl sie für die visuelle Darstellung nicht verwendet werden. Das würde die App und die Speicheranforderungen nur unnötig aufblähen. Daher sehe ich im Moment keinen Sinn darin, in dieser App einen echten Fit File Activity Export aufzugreifen.
Die GPX und TCX-Formate sind bzgl. der Datenreihen gegenüber dem Fit File Format stark limitiert, daher haben sich diese beiden Exportformate angeboten.
Kurze Rede, langer Sinn: in dieser App ist das nicht geplant. Es wäre aber ein Thema für die im Raum stehende Fit File Analyse App (für die es allerdings derzeit kein Peildatum gibt). Es gibt genügend (Online)-Tools, die dafür besser geeignet sind bzw. extra dafür programmiert wurden, GPS-Daten zu korrigieren und/oder zu konvertieren.
Kartenansicht:
Antwort: Auch das kann viele Gründe haben. Unter Umständen kann es helfen, in den Karteneinstellungen manuell einen Pfad zuzuweisen. Weiteres bitte der offiziellen Anleitung entnehmen: Bekannte Probleme (known issues)
Frage: Auf meinem Smartphone wird nur die Mapnik Karte angezeigt, die OpenTopo und CyclOSM Karten bleiben leer. Demnach schließe ich ein Problem mit der Zuordnung des Verzeichnisses, das die Tiles enthält, aus.
Antwort: Das kann auf Smartphones auftreten, auf denen ein zu altes Android werkelt. Ich konnte das Phänomen auf Geräten mit Android <= 7 reproduzieren. Besagte Karten nutzen das TSL 1.3 Protokoll, das von Android 7.x meines Wissen nicht offiziell unterstützt wird. Kurz: auf diesen Geräten funktionieren diese beiden Karten nicht und es kann gut sein, dass zukünftig auch die Mapnik Karte auf diesen Geräten nicht mehr funktionieren wird. Mir sind da leider die Hände gebunden.
Frage: Ich benötige weitere Kartenansichten. Andere Apps können z.B. auch Google Maps, Bing und viele anderen Karten darstellen. Warum kann das diese App nicht?
Antwort: Die Einbettung von Google Maps und Bing Karten ist leider nicht möglich, da ab einer bestimmten Nutzungsrate, Kosten anfallen. Die App ist wie gesagt kostenfrei, daher kann ich keine Karten einbetten, deren Nutzung irgendwann Kosten verursachen würden.
Der Einbettung anderer freier Kartendienste bin ich nicht abgeneigt, allerdings müssen diese wirklich frei zugänglich sein.
Die Implementierung einer frei konfigurierbaren Tile Server Einbindung steht derzeit nicht auf meiner ToDo-Liste. Unter anderem, weil es damit möglich wäre, auch kommerzielle Kartenservices einzubetten und das Herunterladen dann dem WRPElevationChart Projekt zugeordnet würde, weil die App eine entsprechende UserAgent Kennung beim Herunterladen der Tiles im Header des HTTP Requests mitsendet.
Womöglich werde ich zukünftig die Einbindung lokaler Mapsforge Karten ermöglichen, sodass es möglich sein wird, ohne Internetzugriff (Offline)Karten einzusehen. Im Moment sprechen allerdings noch einige Gründe dagegen.
Antwort: Mapsforge Karten können über die OSMDroid-Einstellungen eingebunden werden. Dort gibt es einen Kategorieblock Namens Mapsforge.
- Die zuvor heruntergeladenen und auf dem Smartphone abgelegten Mapsforge (*.map) Karten am besten in einem eigenen und für alle Apps zugänglichen Verzeichnis abspeichern. Auf diese Weise können mehrere Apps auf die Karten zugreifen, ohne diese lokal spiegeln zu müssen. Mapsforge Karten können leider sehr groß sein und dementsprechend viel Platz auf dem internen/externen Speicher des Smartphones belegen!
Dieses Verzeichnis auswählen, WRPElevationChart scannt den Inhalt nach *.map Dateien ab und sofern auf das Verzeichnis zugegriffen werden kann, wird in der Kartenansicht ein Kartentyp Mapsforge angezeigt. - Es können sogenannte Kartenthemen ausgewählt bzw. zugewiesen werden.
Bitte beachten, dass bei externen Themen derzeit nicht alle Attribute (Grafiken/Icons) unterstützt werden. Sofern die Themen-Dateien im gepackten Zip-Format (*.zip) verlinkt werden, sollten alle zusätzlichen Grafiken/Icons in die Karten eingebettet werden. Das kann aber zur einer Überfüllung führen - zuviele Icons auf zu engem Platz - weshalb es sinnvoll sein kann, lediglich die Themen *.xml Dateien zuzuweisen. Dann werden nämlich nur die Default-Icons verwendet, die in der App hart verlinkt sind.
Kartenthemen können vor allem in Kombination mit der neuen Hillshading-Funktion ihre Trümpfe ausspielen, wie man dieser Animation entnehmen kann.
- Die Funktion Theme PNG Cache löschen kann sinnvoll sein, falls die Themen-Icons nicht mehr korrekt dargestellt werden. Der PNG Cache wird aber immer wieder neu befüllt, hier werden aus Performancegründen die *.svg Vektorgrafiken, auf die die Mapsforge Themen verweisen, in PNG-Form abgelegt.
Handling:
Antwort: Dazu habe ich mich im offiziellen Benutzerhandbuch eigentlich schon recht ausführlich geäußert: Zooming
Der Kunstkniff über die beiden Statistikfelder, die als eine Art virtuelle Buttons fungieren, hat den Vorteil, dass ihr relativ einfach den Zoomprozess anstoßen könnt (sogar in der 3D Ansicht, da man auch in der Kartenansicht, Punkte mittels Anklicken des Tracks markieren kann).
Ich habe wirklich einige Zoom-Varianten angetestet - und einiges an Zeit investiert - , auch das klassische Android Zoomen via Swipe-Geste. Letzteres war nicht so performant, da die Grafik dann on-the-fly immer wieder neu aufgebaut werden müsste, um einen flüssigen Effekt zu erzeugen. Auch war ein genaues Zoomen (Bereich) damit schwer umsetzbar und zuletzt wäre dann das Zoomen in der 3D Grafik entfallen, da man in der 3D Darstellung mit den Fingern keinen Bereich eingrenzen kann.
Kurzer Rede, langer Sinn: am Ende war das für mich der beste Kompromiss. Markieren der Zoom-Punkte mit dem Marker und Ausführen des Zoom-Prozess mit einer langen Touchgeste auf eines der beiden Statistikfelder. Unzoom mittels langer Touchgeste auf den Kartenauswahl-Button in der Kartenansicht. Sicherlich ein Bruch mit den Android-Konventionen, aber relativ eingängig, wenn man die Funktion erst einmal erschlossen hat.
Frage: In meiner Wahoo App kann mittels zweier Begrenzungsmarker sehr einfach gezoomt werden. Wäre das nicht in Deiner App auch sinnvoll?
Antwort: Dieses Zooming mittels zweier Zoom-Marker (links und rechts) wird auch gerne in Desktop-Software verwendet. Ich selbst bin kein Freund davon und auf dem kleinen Smartphone-Display geht dann mitunter wieder etwas Platz verloren, wenn man das wie in der Wahoo-App mittels einer abgesetzten Seekbar-Komponente verwirklicht. Und ich weiß nicht, ob man durch den Einsatz dieser gesonderten Auswahl-Bar wirklich so viel an Funktionalität dazu gewinnt. Bei meiner Variante sind es zwar zwei Tastendruck-Aktionen mehr, aber viel Zeit verliert man dadurch nicht. Ich behalte das mal im Hinterkopf, aber im Moment sehe ich keinen echten Benefit.
Frage: Warum gibt zwei Share Funktionsblöcke in der App?
Antwort: Gute Frage, genaugenommen gibt es sogar drei dieser Funktionen :-)
Einmal die Teilen als Screenshot Funktion (Aufruf über das linksseitige Hamburger-Menü), mit der man ganz einfach einen Screenshot des aktuellen Bildschirms erzeugen kann, um diesen z.B. per Whatsapp zu teilen.
Zweitens das Teilen über das entsprechende Share-Icon oben rechts in der Iconleiste. Damit kann man eine sehr einfache GPX-Datei erzeugen, die man direkt mit einer anderen App teilen kann.
Und drittens den dateibasierten Export (Auruf über das rechtsseitige Optionsmenü), der auch zum Teilen genutzt werden kann.
Je nach Aufgabenstellung ergeben diese drei unterschiedlichen Share-Funktionen einen Sinn. Das direkte Teilen mit anderen Apps ist normalerweise die Funktion, die man am Häufigsten nutzen wird, daher ist dieses Share-Icon auch oben rechts fest in der Icon-Bar verankert und immer zugänglich.
Frage: Ich würde gerne wissen, wie ich die Abspielgeschwindigkeit der Animation verlangsamen kann, wenn ich mir eine gefahrene Route ansehe. Die Animation ist viel zu schnell.
Antwort: Du kannst die Geschwindigkeit der Animation mit der SeekBar (Schieberegler) links neben der Wiedergabetaste anpassen. Wenn Du den Schieberegler nach rechts bewegst, verringert sich die Geschwindigkeit. Die aktuelle Schiebereglerposition wird gespeichert, wenn Du die Animation durch erneutes Drücken der Wiedergabetaste stoppst (nur dann!).
Da GPS-Daten in der Regel sehr inkonsistent sind, kann die App die Animationsgeschwindigkeit leider nicht automatisch anpassen, sondern das Abspieltempo muss - je nach Art der GPS Daten - mittels der SeekBar Komponente manuell justiert werden.
Frage: Was hat es mit dem Menüpunkt 'Tools' (ehemals Geschwindigkeitskonvertierer) auf sich?
Antwort: Das ist eine sehr spezielle Tool-Funktion, die in bestimmten Situationen sinnvoll sein kann. Nämlich dann, wenn die Speed Werte falsch importiert wurden.
Das betrifft in der Regel nur TCX und GPX Importe und hat den Hintergrund, dass laut Spezifikation dieser beiden Formate, die Geschwindigkeitswerte (speed) in Form von m/s (metres per second) abgespeichert werden müssen, einige Geräte als auch Anwendungen die Werte aber in kph (km/h) in die GPX oder TCX Dateien schreiben.
Da der in WRPElevationChart werkelnde Parser nicht erkennen kann, in welcher Form diese Parameter in den Importdateien geschrieben wurden, kommt man manchmal nicht umhin, die Werte mittels einer der beiden Konvertierungsfunktionen manuell zu konvertieren (um sinnige Geschwindigkeitswerte aufgeschlüsselt zu bekommen).
Bei Fit File Importen, die Speed normalerweise immer in Form von m/s speichern, ist diese manuelle Konvertierung daher nicht nötig.
Dieser Menüpunkt ist nur enabled, wenn der Importdatei Geschwindigkeitswerte entnommen werden konnten -> sofern die App die Speed-Werte anhand der GPS-Koordinaten und Zeitstempel selbst berechnet hat, ist eine Konvertierung nicht nötig und dieser Menüpunkt daher deaktiviert (also ausgegraut).
Dieses neue Tool ist für mich eine sehr große Hilfe, da ich des öfteren mit GPS-Daten zu tun habe, bei denen die Höhendaten entweder komplett fehlen oder so fehlerhaft sind, dass die Höhenprofile nicht mehr aussagefähig sind.
SRTM-Daten sind zwar auch etwas fehlerbehaftet - oder besser gesagt gegenüber barometerbasierten Höhendaten etwas verrauscht - aber vor allem mit SRTM1-Daten ist es möglich, ein relativ aussagefähiges Höhenprofil behelfsmäßig zu erstellen.
Anders gesagt: bei barometerbasierten Höhendaten sollte diese Toolfunktion eher nicht angewandt werden, bei fehlenden oder korrupten Höhendaten kann diese Toolfunktion ihre Stärke aber voll ausspielen (siehe Animation).
Antwort: Das ist ein heikles Thema, das immer wieder diskutiert wird. Leider sehe ich keine Möglichkeit, an dieser Stelle etwas zu verbessern oder userfreundlicher zu machen. WRPElevationChart ist mittlerweile ein universeller GPS-Daten Viewer. Protokollierte GPS basierte Daten weisen leider eine Art Eigenleben auf, sodass es qualitativ sehr große Unterschiede bei diesen Daten gibt. Und das hat leider sehr großen Einfluß auf die protokollierten - oder berechneten - Geschwindigkeitswerte und vor allem auf die berechneten Auf- und Abstiegswerte.
Sprich, je nach Qualität der Importdaten muss manchmal mehr und manchmal weniger geglättet werden. Dadurch werden natürlich auch die berechneten Statistikwerte beinflusst, da man mit der Glättung ja fehlerhafte Ausreißerwerte egalisieren will, die dann in der Statistik nicht mehr aufschlagen.
Kurz zusammengefasst: gänzlich ohne manuelles Eingreifen wird es nicht funktionieren (leider) und auch weiterhin wird es bei diesen Daten immer Abweichungen zwischen diversen Apps, PC-Programmen und Webportalen geben!
Tipp am Rande: mittels Doppeltipp-Geste auf die jeweiligen Titelleisten (Hysteresefaktor, Glättungsfaktor und Schwellenwert für Netto-Geschw.) können die Defaultvorgaben (1, 20, 2) schnell zurückgesetzt werden (ab Vers.2.0.40).
Charts (2D und 3D Höhenprofile):
Antwort: Das ist über eine Geste möglich. Am besten einmal den Menüpunkt Unterstützte Gesten im Navigationsmenü auf der linken Seite aufrufen. Mittels einfacher Gesten können die beiden Chart-Varianten (2D und 3D) relativ einfach justiert werden.
Um den Achsenmodus umzuschalten, genügt eine lange Touchgeste (langes Antippen) auf der Höhenprofilgrafik. Der Zeitachsenmodus kann nur aktiviert werden, wenn die Importdaten Zeitstempel beinhalten, was bei protokollierten GPS Daten immer der Fall ist. Manuell erstellte Routen beinhalten hingegen häufig keine Zeitstempel, sondern nur die GPS-Koordinaten (Latitude und Longitude). Dann kann aufgrund der fehlenden Zeitstempel natürlich auch keine Zeitachse dargestellt werden.
Frage: Die Geschwindigkeitskurve sieht in einer anderen App deutlich anders aus: zwar etwas zittriger, aber dadurch auch genauer.
Zuerst zu den Stellschrauben: defaultmäßig werden die optionalen Kurven geglättet dargestellt. Man kann den Glättungsfaktor entsprechend justieren, sodass die Glättung umgangen wird. Ich selbst habe die Glättung fast immer aktiviert, weil sie durchaus sinnvoll ist, da zu stark verrauschte (zittrige?) Kurven m.E. keinen echten Mehrwert bieten.
Wie auch immer, ihr könnt die Glättung deaktivieren. Für die Geschwindigkeitskurve gibt es sogar einen eigenen Menüpunkt, mit dem die Glättung sehr einfach deaktiviert werden kann (was bei der Geschwindigkeitskurve in der Tat manchmal sinvoll sein kann).
Nun zu der erwähnten Besonderheit: WRPElevationChart versucht soviele Parameter wie möglich aus den Importdateien herauszulesen. Beim Fit File Format, das standardisiert ist, kann normalerweise jede, der von WRPElevationChart unterstützten Datenreihen, extrahiert werden.
Wenn das nicht möglich ist, wird die Speed anhand der GPS-Koordinaten und Zeitstempel eigenständig berechnet. Häufig sind die protokollierten Speed-Werte genauer - meistens auch smoother - gegenüber den Berechneten. Daher verwendet die App normalerweise die importierten (Geschwindigkeits)Datentreihen.
Andere Apps halten sich womöglich strikt an die GPX 1.1 Spezifikation und berechnen die Speed (Geschwindigkeitswerte) bei GPX 1.1 Dateien immer eigenständig oder man kann das in den Einstellungen der jeweiligen App einstellen.
Wie auch immer, wenn ihr glaubt, dass die Geschwindigkeitskurve nicht korrekt ist, dann könnt ihr die Berechnung der Speed über den Menüpunkt Geschwindigkeitskonvertierer (Geschw. basierend auf Distanz/Zeit berechnen) erzwingen. Ob diese Berechnung bessere Werte zu Tage befördert, ist noch einmal eine andere Frage. Diese Berechnung ist optional - erfordert also manuelles Eingreifen - und ich habe nicht vor, das zu ändern.
Frage: Das 3D Chart ist auf meinem alten Handy nicht sonderlich performant. Kann man da etwas tweaken?
Antwort: Es ist möglich, die Performance ein klein wenig zu verbessern, in dem man die Datenpunkte der 3D Grafik etwas reduziert. Wunder kann diese Datenreduktion allerdings nicht vollbringen. Aktuelle Mittelklasse Smartphones sollten in der Lage sein, die meisten normalen Tracks einigermassen flüssig in 3D abzubilden. Siehe Erläuterungen im offiziellen Benutzerhandbuch: 3D Modus
Frage: Das 3D Chart wird manchmal, trotz aktivierter Option 'Seitenverhältnis beibehalten', perspektivisch verzerrt dargestellt.
Natürlich könnte man die jeweiligen korrekten Seitenverhältnisse berechnen und die 3D Grafik entsprechend ausrichten, aber das würde mitunter dazu führen, dass die 3D Grafik sowohl auf X- als auch auf Y-Achse manchmal sehr gestaucht oder gestreckt werden müsste. Kurzum, je nach Track-Dimensionen würde man bei einer quadratischen Grundfläche manchmal sehr viel Projektionsfläche einbüßen, was bei einem doch eher kleinen Smartphone-Bildschirm nicht immer erstrebenswert ist.
Daher habe ich mich entschieden, selbst bei aktivierter Option Seitenverhältnis beibehalten, das Seitenverhältnis auf die absoluten Breiten- und Längengrad Dimensionen des Tracks zu beschränken. Es wird also bewußt in Kauf genommen, dass dieses 3D Höhenprofil auch etwas verzerrt dargestellt werden kann (je nach Trackausprägung, also Verhältnis Breiten- zu Längengrad).
Für den angestrebten Anwendungszweck dürfte das m.E. auch völlig in Ordnung gehen, zumal diese Verzerrung auch nur auffällt, wenn man auf das 3D Höhenprofil direkt von oben in der Vogelperspektive herabblickt (dafür braucht's dann aber auch kein 3D Höhenprofil :)).
Nicht alles, was technisch möglich ist, ist in der Praxis dann auch wirklich sinnvoll bzw. praxisrelevant oder anders ausgedrückt, ich strebe mit dieser 3D Höhenprofilgrafik keine wissenschaftliche Korrektheit an, zumal diese 3D Grafik sowieso immer perspektivische Verzerrungen bedingen (WRPElevationChart ist keine CAD Software!).
Weiterführende Links zum Thema:
https://de.wikipedia.org/wiki/Isometrische_Perspektive_in_Computerspielen
https://de.wikipedia.org/wiki/Parallelprojektion
https://de.wikipedia.org/wiki/Zentralprojektion
https://de.wikipedia.org/wiki/Isometrische_Perspektive_in_Computerspielen
https://de.wikipedia.org/wiki/Parallelprojektion
https://de.wikipedia.org/wiki/Zentralprojektion
Diverses:
Frage: Die App gefällt mir sehr gut. Was jetzt noch fehlt, ist eine Tracking bzw. Datenlogger Funktionalität. Wird die App dahingehend erweitert?
Antwort: Wie ich bereits an einigen Stellen erwähnt habe, ist nicht geplant, die App in einen GPS Datenlogger umzufunktionieren. Es gibt wirklich viele sehr gute GPS Logger Apps, die alles mitbringen, was des Datenloggers Herz begehrt. Einige Apps sind reine GPS Datenlogger, andere Universal-Apps, die sowohl als GPS Logger als auch als GPS Viewer Apps fungieren.
Da man Android Apps aufgrund der internen Schnittstellen sehr gut miteinander verknüpfen kann, ohne dass der Workflow darunter leidet, bin ich ein Freund dedizierter Apps.
Sehr gute GPS Datenlogger sind z.B.:
- (BasicAirData) GPS Logger
(Diesen GPS Logger nutzen wir in der Familie sehr gerne. Selbst meine schon etwas ältere Mutter nutzt ihn, um ihre Wandertouren damit zu protokollieren. Diese App weist eine bewusst einfach gehaltene Oberfläche auf und ist daher ohne größere Einarbeitung sehr angenehm zu bedienen.
Link zur Projektseite: https://www.basicairdata.eu/projects/android/android-gps-logger/) - GPSLogger (Mendhak)
(Wenn ihr bestimmte Aufgaben automatisieren wollt, dann ist dieser GPS Logger sehr gut) - Geo Tracker - GPS tracker
(Wenn ihr einen Logger und einfachen Viewer in einer App gebündelt haben wollt, dann bietet sich der Geo Tracker an -> dann braucht ihr WRPElevationChart auch nicht weiter verwenden :-)
Link zur Projektseite: https://geo-tracker.org/de) - GPSLogger II - AIO
(Ein GPS Logger, der laut eigener Einstufung, sehr auf Datenschutz bedacht ist. Sehr viele nützliche Funktionen, allerdings etwas verspielt, sodass man sich mit der App vertraut machen muss. Mich hat ein User vor kurzem darauf aufmerksam gemacht und das Projekt kommt sehr sympathisch rüber. Ich werde mir die App noch genauer ansehen.
Link zur Projekseite: https://emacberry.com/) - OpenTracks
(Auch ein GPS Logger, der nach eigener Einstufung, sehr auf Datenschutz ausgerichtet ist. Zusammenspiel mit WRPElevationChart aber ab Vers. 2.0.46, da ich den Intent-Filter* für OpenTracks anpassen musste)
Darüber hinaus gibt es für Android natürlich auch einige ausgereifte Navigations-Apps, die das gesamte Tracking- und Auswertungspaket abdecken (also funktionell über die genannten Logger-Apps deutlich hinausgehen).
Auch diese Apps kann man ggfs. mit WRPElevationChart verknüpfen und auf diese Weise die Höhenprofil-Funktionalität etwas erweitern.
WRPElevationChart kann ab Vers. 2.0.33 direkt mit Locus Map in dessen Trackansicht verknüpft werden. Bei anderen Apps besteht häufig die Möglichkeit, über die Share Funktion (GPX-, TCX- oder FIT Format Exporte) WRPElevationChart einzubinden.
Ich kann Euch daher nur empfehlen, eine - oder alle - dieser Apps anzutesten (wobei es natürlich noch sehr viele andere GPS Logger Apps gibt). Diese Apps sind allesamt sehr gut und es steckt einiges an Knowhow und Erfahrungen in diesen Apps. Wollte ich diese Funktionalität aufgreifen, würde das auf einen Kopierprozess hinauslaufen und dann ist es doch besser, beim jeweiligen Original zu bleiben und diesem mittels einer externen Verknüpfung etwas unter die Arme zu greifen. Gut funktionierendes Teamwork war noch nie verkehrt!
Again, man kann diese Apps sehr gut miteinander verdrahten (den oben erwähnten BasicAirData GPS Logger unc Locus Maps kann man sogar mit dem GPS Viewer seiner Wahl verheiraten :-) )
Mit anderen Worten: WRPElevationChart wird ein reiner GPS Viewer bleiben, der sich weiterhin bewusst auf die Kernfunktionen einer GPS Viewer App konzentrieren wird.
Frage: Wäre es nicht sinnvoll, die importierten Tracks in einer Datenbank dauerhaft abzulegen. Dann könnte man die Tracks in einer Listenansicht samt Vorschau-Trackgrafik auflisten, Sortieren, nach Keywörtern suchen, etc. Den Browser bräuchte man dann gar nicht mehr.
Antwort: Es gab meinerseits schon entsprechende Überlegungen, die ich allerdings schnell verworfen habe. WRPElevationChart soll eine leichtgewichtige GPSViewer-App bleiben. Eine Datenbankfunktionalität würde die App doch sehr aufblähen. Zumal alle mir bekannten GPS-Tracker Apps sowieso eine Datenbank aufweisen und dort die aufgezeichneten Tracks ablegen.
Die großen Universal Tracking Apps wie Locus Map, OruxMap, OsmAnd - um mal ein paar bekannte Schwergewichte zu nennen - können sogar Tracks importieren und diese in ihrer Datenbank entsprechend auflisten. Kurz gesagt, diese Apps bieten bereits eine Trackverwaltung, die nahezu alles abdeckt.
Und auf den Browser kann und will ich nicht verzichten, da auf meinem Smartphone immer mal wieder GPS-Dateien landen, auf die ich spontan zugreifen muss. Mitunter sind das Sample-Dateien von Usern meines TrainingLab Pro Projekts, die später nach kurzer Einsicht auch wieder auf meinem Smartphone gelöscht werden. Wenn das alles über Datenbankimporte gehandelt werden sollte, wäre das - zumindest was meinen persönlichen Usecase betrifft - sehr schwerfällig, da die GPS-Dateien auf meinem Smartphone häufig sehr volatiler Art sind.
Auch wenn der Browser technisch bedingt eine etwas langsamere Navigation gegenüber einer reinen Datenbanknavigation aufweist - da die GPS-Datenreihen beim Browsen durch die GPS-Dateien immer wieder neu geparst werden müssen, was je nach Datenformat und Größe der GPS-Dateien etwas aufwendiger sein kann -, erscheint mir das die schnellste Variante zu sein, wechselhafte GPS-Dateien auf dem Smartphone einzusehen bzw. durch diese zu zappen.
Alternativ müsste quasi bei jedem Neustart der App nach neuen oder auch nicht mehr vorhandenen GPS-Dateien gescannt werden und die Datenbank entsprechend neu indexiert werden, was unter Android ein sehr kostenintensives Vorgehen wäre. Machbar wäre das natürlich irgendwie, aber WRPElevationChart wäre dann nicht mehr diese leichtgewichtige App, die es ist.
Die großen Universal Tracking Apps wie Locus Map, OruxMap, OsmAnd - um mal ein paar bekannte Schwergewichte zu nennen - können sogar Tracks importieren und diese in ihrer Datenbank entsprechend auflisten. Kurz gesagt, diese Apps bieten bereits eine Trackverwaltung, die nahezu alles abdeckt.
Und auf den Browser kann und will ich nicht verzichten, da auf meinem Smartphone immer mal wieder GPS-Dateien landen, auf die ich spontan zugreifen muss. Mitunter sind das Sample-Dateien von Usern meines TrainingLab Pro Projekts, die später nach kurzer Einsicht auch wieder auf meinem Smartphone gelöscht werden. Wenn das alles über Datenbankimporte gehandelt werden sollte, wäre das - zumindest was meinen persönlichen Usecase betrifft - sehr schwerfällig, da die GPS-Dateien auf meinem Smartphone häufig sehr volatiler Art sind.
Auch wenn der Browser technisch bedingt eine etwas langsamere Navigation gegenüber einer reinen Datenbanknavigation aufweist - da die GPS-Datenreihen beim Browsen durch die GPS-Dateien immer wieder neu geparst werden müssen, was je nach Datenformat und Größe der GPS-Dateien etwas aufwendiger sein kann -, erscheint mir das die schnellste Variante zu sein, wechselhafte GPS-Dateien auf dem Smartphone einzusehen bzw. durch diese zu zappen.
Alternativ müsste quasi bei jedem Neustart der App nach neuen oder auch nicht mehr vorhandenen GPS-Dateien gescannt werden und die Datenbank entsprechend neu indexiert werden, was unter Android ein sehr kostenintensives Vorgehen wäre. Machbar wäre das natürlich irgendwie, aber WRPElevationChart wäre dann nicht mehr diese leichtgewichtige App, die es ist.
Wenn ich mir das allgemeine Feedback vor Augen halte, dann nutzen die meisten User WRPElevationChart als externen GPSViewer für ihre GPS-Apps. Für diese User ist das interne und reibungslose Zusammenspiel der verdrahteten Apps am wichtigsten -> diese Apps reichen quasi den Inhalt ihrer Datenbanken an WRPElevationChart durch und WRPElevationChart kann sich primär auf die Visualisierung der durchgereichten Daten konzentrieren.
Keine Kommentare:
Kommentar veröffentlichen