Messages

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);

            }
        }