Messages

@WRPSoft: Der Nutzen von ungenauen, stark verrauschten GNSS-Höhendaten ist sehr gering. Da hilft auch Glätten wenig. Am besten man verzichtet auf GNSS-Höhendaten. Die Höhendaten während einer Tour müssen also auf anderem Wege ermittelt werden (z.B. via DEM/DGM). Vor und nach der Tour ermittelt man die Höhendaten ja ohnehin schon via DEM/DGM.

Ja, das ist ja mein Reden Eine Frage ist halt, wie bzw. ob man das zur Echtzeit eintüten kann.

Abstrakt betrachtet möchte man mit Track-Statistiken drei Dinge erreichen:

• Vor der Tour: Informationen zur Streckenlänge und zu den Höhenmetern.
• Nach der Tour: Informationen zur Streckenlänge und zu den Höhenmetern.
• Während der Tour: Wieviel Strecke und wieviele Höhenmeter kommen noch?

Die Statistiken vor und nach der Tour macht man am besten auf Basis von DGM/DEM-Daten. Die Schwierigkeit während der Tour ist die Berechnung der Höhenmeter. Hier sind GNSS-Daten (Satellit) ungeeignet, weil sie zu ungenau und zu stark verrauscht sind. Der Vergleich von "GNSS-Höhendaten mit DGM/DEM-Höhendaten" entspricht einem Vergleich von "Äpfeln mit Birnen". Um während der Tour eine vernünftige Aussage zur Frage "Wieviele Höhenmeter kommen noch?" treffen zu können, sollte man richtigerweise dieselbe Basis verwenden wie für die Planung.

Anders ausgedrückt: Der Nutzen von GNSS-Höhendaten ist sehr gering. Am besten man verzichtet darauf. Die Höhenmeter während der Tour müssen auf anderem Wege ermittelt werden.

Daan bleibt zur Echtzeitberechnung aber nicht mehr viel, was man aufgreifen könnte:

- Barometerbasierte Höhenmessung wäre eine Möglichkeit, allemal besser als reine GPS-Höhenwerte.

- Oder die Höhenwerte bereits zur Echtzeit durch DEM-Daten ersetzen. Ist dann die Frage, wie hochauflösend die DEM-Daten sind, ob man diese lokal auf dem Gerät speichert oder diese jeweils per Internetverbindung pro Datenpunkt (ggfs. nur alle X Datenpunkte abfragen und die Zwischenwerte interpolieren) zuweist.

Das Thema ist sicherlich noch nicht ausgereizt, aber gerade die Echtzeitberechnung wird noch den ein oder anderen Stolperstein zu Tage befördern. Bin gespannt, wie sich das zukünftig entwickelt.

@WRPSoft: Ich habe Deinen Blogeintrag zum dem Thema gelesen. Ein hervorragender Artikel zu den Problemen mit der Höhenberechnung. Und ich zweifle nochmals an meinen Fähigkeiten, ordentlich zu einem Thema zu recherchieren. Auch  die Seite hatte ich nicht gefunden 

Freut mich zu hören, danke für die netten Worte. Wobei ich natürlich sehr subjektiv an das Thema herangehe, weil meine Wurzeln wie gesagt im Bikecomputer- und Wanderuhren-Bereich liegen. Die erste Generation dieser Geräte konnte noch keine GPS-Daten protokollieren, das waren rein barometerbasierte Höhenmesser und da war die Hysterese quasi die einzige Stellschraube. Glätten musste man dabei nicht viel, da die Höhenmess-Chips schon recht früh im cm-Bereich auflösen konnten und dieses feine Grundrauschen konnte/kann man mit der Hysterese sehr gut egalisieren.

Heutzutage sieht das natürlich etwas anders aus, aber zumindest die Echtzeitberechnungen auf den Geräten selbst, laufen m.E. immer noch ähnlich ab (man hangelt sich von Datenpunkt zu Datenpunkt und operiert mit den Deltas).

Das ist sicher richtig. Die Frage ist, welchen Aufwand man betreiben muss, um aus offensichtlich falschen Werten einigermaßen vernünftige Werte zu machen. Da sollte Menion schon ein Interesse haben, insbesondere wenn das mit anderen Apps verglichen wird. Aus Aufnahmeprofil und Quelle für die Höhenangaben sollte man man schon mal in die richtige Richtung kommen. Absolute Genauigkeit erwarte ich nicht. Und ich ging davon aus (und sehe mich durch Deinen Blog-Eintrag bestätigt), dass die Algorithmen zu dem Thema bekannt sind. fsk hat mit seinem Service vielleicht die Möglichkeit viele verschiedene GPX-Dateien zu sammeln und auszuwerten (sofern es das in seinen Nutzungbedingungen darstellt, habe ich jetzt nicht geschaut). Vielleicht kommt er dann auch zur Erkenntnis, dass es die eine Methoden mit wenigen Parametern nicht gibt.

Ich glaube, Interesse wird bei Menion schon vorhanden sein, aber er muss halt gegen eine sehr große Bandbreite an Geräten und Daten ankämpfen und das macht's nicht gerade einfacher Wir haben hier drei aktuelle Mittelklasse-Smartphones in Verwendung, eines davon protokolliert leider sehr grausliche GPS-Koordinaten. Da macht dann sogar eine nachträgliche Korrektur der Höhendaten nur bedingt Sinn, weil man eigentlich vorher die GPS-Ausreißerkoordinaten korrigieren/filtern müsste.

Auch das könnte man natürlich irgendwie angehen, die einfachste Variante wäre ein Glätten der GPS-Koordianten mittels Douglas-Peucker-Filter, wobei das aber auch keine Universalwaffe ist und ich nicht weiß, ob Locus Map die GPS-Daten im Hintergrund bereits etwas aufbereitet.

Wie gesagt, recht anspruchsvoll, könnte man wahrscheinlich eine Doktorarbeit draus machen

Beim Aspekt "Glättung" sehe ich folgende Sachverhalte:
 
Die DGM1-Höhendaten sind extrem genau, was aber dazu führt, dass ein unebener, horizontal verlaufender Naturweg plötzlich Steigung und/oder Gefälle aufgrund der Unebenheiten aufweist. Glättung?

Die DGM1-Daten sind natürlich extrem genau (vergleichbar mit einer barometerbasierten Messung bei stabilem Wetter). In Kombination mit vielen GPS-Fehlern (schlechte Empfangsbedingungen oder 'schlechten' GPS-Chipsätze, die es leider immer noch gibt), sind sie aber nicht mehr so extrem genau, sondern nur noch feinauflösend.

Und bei sehr fein auflösenden Daten hat eine Glättung in der Regel weniger Auswirkung, zumal man die Glättung dann sehr fein runterregeln muss (bei DGM1-Daten operiert man dann ja im cm Bereich, analog zu Barometerbasierten Messungen, die heutztage auch im cm Bereich die Höhe messen).

Läuft bei Pausen die Trackaufzeichnung weiter, führt dies oft zu mehr oder weniger ausgeprägten Punktwolken. Diese Punktwolken führen zu Steigung und/oder Gefälle obwohl keine Bewegung erfolgte. Glättung?

Also kommt man leider nicht umhin, die (GPS)-Daten vorher - vor der Höhenwertzuweisung bzw. Höhenwertreparatur - aufzubereiten. Da gibt es mehrere Möglichkeiten, Tapio hat das ja beschrieben. In Echtzeit stelle ich mir das sehr schwierig vor; nachträglich durchaus machbar, wobei aber die Frage bleibt, wie weit man das automatisieren kann.

Vielleicht hilft ein Beispiel. Der Track sollte so um die 250 Meter Steigung und Gefälle aufweisen:

Höhenmeter-Auswertung basierend auf ungenauen Höhendaten via GPS-Signal:
Uphill: 672.4 m (weighted moving average)
Downhill: 676.5 m (weighted moving average)
Uphill: 1183.7 m (unfiltered)
Downhill: 1187.8 m (unfiltered)

Höhenmeter-Auswertung basierend auf hochgenauen DGM1-Höhendaten:
Uphill: 245.7 m (weighted moving average)
Downhill: 248.0 m (weighted moving average)
Uphill: 277.4 m (unfiltered)
Downhill: 279.7 m (unfiltered)

An deinem Beispiel sieht man recht gut, dass die Glättung vor allem bei verrauschten Daten große Auswirkungen hat, bei den fein abgestuften DGM1-Daten aber weniger.

Ich habe - wie gesagt - auch recht viel mit solchen Daten experimentiert, spätestens dann, wenn man stark unterschiedliche Touren aufbereiten/normalisieren will, kamen dann aber wieder größere Abweichungen zustande.
Z.B. Rennradtouren vers. MTB-Touren vers. Wandertouren, kurze Touren vers. langen Touren, stark verrauschte Daten vers. eher genauen Daten (auch oder vor allem, was die GPS-Daten betrifft), lange Anstiege gegenüber Achterbahntouren (z.B. Wandern in Weinbergen), verwendete Aufzeichnungsintervalle (da bietet Locus Map ja sehr viele Einstellungsmöglichkeiten), etc.

Ich konnte das mit einer Universalformel leider nicht einfangen. Wenn man z.B. einen Ötztaler Radmarathon alleine mit der Glättung der Höhendaten berechnen will, dann kommen m.E. immer deutlich zu viele Auf- und Abstiegsmeter heraus, sodass ich bei dieser Art Tour um eine zusätzliche Hysterese nicht umhingekommen bin.

Das mögen jetzt Sonderfälle sein, aber Locus Map muss das ja quasi alles eintüten und erschwerend kommt hinzu, dass Locus Map mit vielen Arten von Android Phones zusammenarbeiten muss und daher eine sehr große Bandbreite, was die Zuverlässigkeit der Aufzeichnungen betrifft, aufschlagen dürften).

Nicht gänzlich unmöglich, aber ich glaube, das ist schon eine sehr, sehr großen Baustelle, wenn man das alles auf dem Phone berechnen will. Wahrscheinich viele Stellschrauben, die man konfigurieren muss, um diese unterschiedlichen Ausgangsdaten handeln zu können.

PS: Das ist jetzt alles sehr subjektiv, da ich mich selbst sehr viel mit Radaufzeichnungen beschäftigt habe. Man hangelt sich ja immer von einer bestimmten Ausgangslage zur nächsten und versucht im nächsten Schritt, eine allgemeingültige Variante zu finden.

Was auf der Webseite noch fehlt, ist ein Dienst "Track-Analyse" der die genauen Höhenangaben im GPX-Track statisch auswertet. Also zum Angaben wie "Höhenmeter bergauf" oder "Höhenmeter bergab" ermittelt.

Die "Track-Analyse" müßte eine Reihe von Randbedingungen und/oder Benutzerparameter zur Glättung der Daten berücksichtigen. Welche genau, darum ginge es mir im Rahmen einer Diskussion. Das Diskussionsergebnis soll dann in die konkrete Implementierung einfließen.

Das ist eigentlich ein guter Ansatz. Leider öffnet man damit bei GPS-Daten, die ja doch sehr unterschiedlicher Natur sein können, mitunter die Büchse der Pandora. Im schlimmsten Fall kommt man nicht umhin, an den Faktoren immer wieder manuell Hand anzulegen.

In meiner App (https://forum.locusmap.eu/index.php?topic=9063.msg78707#msg78707) kann man einen Glättungs- und einen Hysteresefaktor in Echtzeit variabel zuweisen.

Auf diese Weise kann man die Auswirkungen dieser beiden Faktoren sehr gut einsehen.

Bei sehr feinauflösenden Höhendaten (barometerbasierte Messung oder eben sehr fein auflösende SRTM-Daten) hat die Glättung m.E. weit weniger Einluss. Da wirkt sich vor allem ein Hysteresefaktor aus, sofern man diesen nutzt, um kleinere Erhebungen zu egalisieren (was bei Barometerbasierten Daten m.M. sinnvoll ist -> ich habe meine Wurzeln in der Bike-Computer Ecke).

Was ich sagen will, eine Verbesserung der Track-Analyse in Locus Map wäre sicherlich schön, wenn Menion das aber in trockene Tücher packen will, also diese Randbedingungen und/oder Benutzerparameter zur Glättung der Daten automatisieren will, dann wird es wirklich schwierig. Gerade dann, wenn man konform mit diversen Webdiensten (Komoot, etc.) gehen will, die ja alle ihre eigenen Höhenmeter-Wahrheiten offenbaren
Ich bin jedenfalls bei dem Versuch, das zu automatisieren, mehrmals gescheitert (also bei meinen Versuchen geht es gänzlich ohne manuelles Eingreifen leider nicht)

You cannot view this attachment.

I want to revisit this thread.
There have been a few more updates and the app has now adopted some illustration features from my very old Windows-based HRMProfil project.
In short, the interaction with Locus Map has also been slightly improved: waypoints can now also be transferred and imported.

However, the waypoints must have a timestamp, as waypoints can only be assigned internally based on the timestamp (or distance), which should be the case for all Locus waypoints inserted during an active recording.

Even though I primarily use the app for support tasks of my own projects (to be able to quickly look at GPS files while on the go), the app can be useful for illustrating the logged tours on the smartphone a little better afterward (the lap marker titles that can be embedded to the graphics and can be edited relatively easily).

Although a PC might be the better tool for this, as space on a smartphone display is very limited and the use case for this type of illustration on a smartphone is certainly rather rare. But up in a mountain hut with a nice cold Pilsner Urquell, sometimes you get silly ideas and play with your phones

Anyway, the app is still free (adfree too) and in certain situations maybe a good add-on for our beloved Locus Map.

@Michal - the 1st images in https://www.locusmap.app/new-locus-map-4-26-dynamic-offline-lomap-rotation-and-other-features-not-only-for-cyclists/ doesn't display?

I had to reload the page several times until all images were displayed (by pressing the reload button in the browser)

PS: the new map rotation is really cool

Dear Joska,

...
Have I got it wrong? Is there perhaps a simple howto on how to quickly switch to the 3D display while the track is running?

Greetings, Joska

Thanks for asking. Michael has already answered the most important thing!

Basically the app is just a small GPS viewer app with the main focus on the elevation chart (combined and synchronized with the map view).
In principle, you can do all of this yourself with Locus Map, but above all you should create a real-time elevation profile using Locus' own dashboard.

My app is only suitable for post 'analyses', as it can display the elevation chart slightly differently. So it's actually just an add-on to check the recorded data later in a slightly different form compared to the Locus Map' altitude chart functionality.

New version with direct transfers has now been released.
Unfortunately I had to make a few more changes than planned at the last minute yesterday (updating some Google libraries, OSMDroid library, Locus API was also updated :-), etc.).

As I won't have time to program this week, I just took the plunge and hope that the library updates mentioned don't have any side effects.

Locus Map Track exports should now be very performant, as the track to be transferred is transferred directly as a Locus Track object (without file-based handling).

PS: Many thanks to Menion for the good advices.

Hi again,

...
PS: ... It's just a tiny and lightweight GPS Viewer app, that is doing it's job.

Feedback is welcome.

There was some constructive feedback via email and Menion gave me good tips on how to link to Locus Map without cached files (direct transfers via Locus API Track object).

There will be a small update at the end of the week. Transfers from the Locus Track Manager share menu will then perform really very fast and smoothly and some minor issues will be fixed.

I will test it for a few more days, but I think it has turned out really well.

I would be happy if the app in its current form is of use to one or another user. Maybe I will add a few more new features in the winter.

PS: The Locus API is awesome, there are many new ideas in my head 

Thank you. There was an instant itch to a) zoom the 3D view via pinching and b) make the 2D/3D view fullscreen. If there was a quick toggle between diagram and map, that could be helpful.

Unfortunately, the 3D calculations are quite computationally intensive so that the pre-calculated 3D graphics can be rotated and tilted relatively efficiently in the next step.

The 3D chart also has to be projected onto a square surface, because otherwise the whole calculation would be too complex and, depending on the track dimensions, too much area would remain unused if the projection surface was not square.

I go into this in more detail in the FAQ, which is unfortunately currently only available in German: https://wrpsoft.blogspot.com/2024/04/faq-zu-wrpelevationchart.html

The app is also currently very much geared towards smartphones. If you switch the smartphone from portrait to landscape mode, the 3D graphics are switched to 'full graphics mode'. But as I said, you don't gain much from this due to the limited square projection surface.

Zooming in 2D mode is also implemented in a somewhat unconventional way, partly for performance reasons, but primarily because I can select the zoom areas most precisely with the current approach. I haven't managed to do this very well with the pinching zoom normally used for zooming in Android.

Maybe I'll try it again, but I think I'll exclude the 3D graphics from it because it would be really difficult to implement. The 3D Chart is more a gimmick, but could be sometimes very usefull for a better overview.

But you should never say never, it could well be that I will change everything again a bit (winter time is coming soon) :-)

Hi to all,

After Menion pointed out to me here in the forum that apps can be linked very well with the Locus Map track manager via the Locus API, I modfied my app called WRPElevationChart accordingly.
The result is that the app can be called up directly from the share menu in the Locus Map track view.

WRPElevationChart is a really lightweight GPS viewer app that focuses on linking the 2D/3D-elevation profile with the track view at the map. The analysis functionality is deliberately kept to a minimum, but the app is ideal for quickly overviewing the track data. For me, it is a good addition to the Locus Map track view because the elevation profile can be scaled very well via gestures.

Perhaps it will be useful for one or two Locus Map users.

Note:

The app calculates the statistical data (ascent and descent, speed average, etc.) independently. Therefore, there will always be deviations from the values calculated in Locus Map. Calculating ascent and descent is a science in itself, and it has given every developer a few grey hairs :-)

However, there will be a small update in the next two weeks where you can fine-tune these calculations a little more and optionally choose whether the track should be transferred in FIT or GPX format (both formats have their advantages and disadvantages, especially on smartphones with weaker performance, generating and parsing the FIT files can take a few milliseconds longer compared to GPX files :-)).

Anyway, if you want to test the app, here is the link. I hope this post is okay for the Locus Map team.

https://play.google.com/store/apps/details?id=de.wrpsoft.wrpelevationchartmaker

Some use cases: https://wrpsoft.blogspot.com/2022/07/what-can-you-do-with-wrpelevationchart.html

If you have any problems, please let me know, so I can take them into account in the next update (coming soon).

PS: This app is a side-project, I need for support purposes. Therefore it's free (also add-free) and will be free in the future. And of course, no trackers are embedded! It's just a tiny and lightweight GPS Viewer app, that is doing it's job.

Feedback is welcome.

Regards Ralph

Primarily for cross checking various bike computers, I created a simple dashboard that shows the most important comparison parameters in Locus Map.

The dashboard only makes sense in portrait mode; in landscape mode, some fields will probably be cut off.

Perhaps one or two cyclists will be able to do something with it.

Feel free to modify it :-)

Hello,
thanks a lot for such a detailed description. Yes, I use FIT SDK and this should work.
...
Btw, out of topic, it should be possible to integrate the WRPElevationChart app into the "Share" sub-menu of the Locus Map. It is already implemented in the "Locus API - Sample" app, but because I'm lazy with docs, it is not described in detail. So if there will be interest.

Dear Menion,

Thank you for your reply. I have sent an email to your official email account.
I would be happy to hear from you again.

Bernhard has already commented on the rest. I am happy to help with questions about the fit file, but I don't currently know how to read this data from the power meter. I haven't dealt with the hardware (ANT power profile?) for too long.

Regards Ralph

Hello Bernhard,

if I'm correct, the power meter reports only a single "power" value + "balance" value, right? So what do you mean by "record Power left/right"? Also, what do you expect that app to do with these values? Currently, power meter values are visible in the chart, and dashboard, recorded to the track, and exported to GPX and FIT. How to deal with left/right? I have no idea.

I do not know ipbike app, but seems it is more focused on sports activities. Locus Map is more focused on the hike/bike so the more precise work with the power values seems to be out of the app's scope.

Dear Menion,

If you are using the official Fit File SDK and (Android) Java, that would be one way to extract and write the balance data. See embedded code fragments.

But I also think that these specific things are not necessarily within the scope of data/functionality supported by Locus.

      /////////////////////////////////
      // balance from fit session message
      /////////////////////////////////
     
      public void onMesg(com.garmin.fit.SessionMesg mesg) {
          if (mesg.getLeftRightBalance() != null)
          {
              int ibal = mesg.getLeftRightBalance();

              //#define FIT_LEFT_RIGHT_BALANCE_100_RIGHT ((FIT_LEFT_RIGHT_BALANCE_100)0x8000) // data corresponds to right if set, otherwise unknown
              // boolean bright = Bitfield.testBit(15, ibal);
              boolean bright = (ibal & (1 << 15)) == (1 << 15);

              //#define FIT_LEFT_RIGHT_BALANCE_100_MASK ((FIT_LEFT_RIGHT_BALANCE_100)0x3FFF) // % contribution scaled by 100
              int ival = ibal & 0x3FFF;

              int ileft = 0;
              int iright = 0;

              // if stored balance value is right based?   
              if (bright) {
                  iright = ival;
                  ileft = (100 * 100) - iright;
              }
              // Note: there are some discussion as to whether unknown should be treated as left based or not (= not defined therefore invalid)
              // else {
              //    ileft = ival;
              //    iright = (short) (100 - ileft);
              // }

              //////////////////////////////////////////////////////////
              // Cross checking for writing back to fit file
              // this should be used for writing balance(*100) to SESSION message  (fit activity file)
              // be aware of the right based flag!!!
              // modulate balance value for writing (back) to fit file
              //////////////////////////////////////////////////////////

              // valid balance? -> right based
              // ((FIT_LEFT_RIGHT_BALANCE_100)0x8000) // data corresponds to right if set, otherwise unknown
              int ibalnew = (1 << 15);
              // add right pedal balance value
              ibalnew = ibalnew | iright;
              // does it work?
              assert ibalnew == ibal;

              // code for writting fit file session message
              // must be placed in fit export method of course
              // SessionMesg sessionMesg = new SessionMesg();
              // sessionMesg.setLeftRightBalance(ibalnew);

          }
      }

    /////////////////////////////////
    // balance from fit record message
    /////////////////////////////////
    @Override
        public void onMesg(com.garmin.fit.RecordMesg mesg) {

            if (mesg.getLeftRightBalance() != null)
            {
                short ibal = mesg.getLeftRightBalance();

                // #define FIT_LEFT_RIGHT_BALANCE_RIGHT ((FIT_LEFT_RIGHT_BALANCE)0x80) // data corresponds to right if set, otherwise unknown
                // boolean bright = Bitfield.testBit(7, ibal);
                boolean bright = (ibal & (1 << 7)) == (1 << 7);

                // #define FIT_LEFT_RIGHT_BALANCE_MASK ((FIT_LEFT_RIGHT_BALANCE)0x7F) // % contribution
                short ival = (short) (ibal & 0x7F);

                short ileft = 0;
                short iright = 0;

                  // if stored balance value is right based?   
                if (bright) {
                    iright = ival;
                    ileft = (short) (100 - iright);
                }
                // Note: there are some discussion as to whether unknown should be treated as left based or not (= not defined therefore invalid)
                // else {
                //    ileft = ival;
                //    iright = (short) (100 - ileft);
                // }

              //////////////////////////////////////////////////////////
              // Cross checking for writing back to fit file
              // this should be used for writing balance to RECORD message (fit activity file)
              // be aware of the right based flag!!!
              // modulate balance value for writing (back) to fit file
              //////////////////////////////////////////////////////////
              // valid balance? -> right based
              // ((FIT_LEFT_RIGHT_BALANCE)0x80) // data corresponds to right if set, otherwise unknown
              short ibalnew = (1 << 7);
                // add right pedal balance value
              ibalnew = (short) (ibalnew | iright);
              // does it work?
              assert ibalnew == ibal;

              // code for writting fit file record message
              // must be placed in fit export method of course
              // RecordMesg recordMesg = new RecordMesg();
              // recordMesg.setLeftRightBalanceibalnew(ibalnew);

            }
        }