Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - WRPSoft

#1
Hallo Zusammen,

Quote from: Christian on April 22, 2026, 00:20:05Danke @Menion für Deine Beteiligung und Deine Offenheit.
Ich möchte meine Emotionen hier im Thread ein wenig differenzieren.
Ich bin wegen der Ignoranz hier im Thread ziemlich verärgert. Das ist für mich nicht tolerierbar. Es hilft Dir nicht, der App nicht, uns allen nicht.

Ich bin von der App enttäuscht: die strategische Ausrichtung gefällt mir nicht (zu viele Baustellen (auch iOS, Webplanner, Android Auto...), zuviel Hickhack, nicht zu Ende programmiert, zu komplex*, zu viele Fehler). Ich glaube, Du planst die Arbeitslast für Asamm Global Enterprise, bist aber nur zu zweit.

Ich möchte mich hier gar nicht größer einbringen, weil ich Locus Map zu selten nutze (eigentlich nur zum Wandern, primär nutze ich GPS-Sportuhren und -Bikecomputer) und daher sicherlich einen sehr subjektiven und eher unkritischen Blickwinkel habe. Das meiste was ich mit Locus Map mache, funktioniert - allen Unkenrufen zum Trotz- bei mir recht stabil (ich nutze Locus Map aber auch nur in seinen Grundfunktionen).

Aber als Softwareentwickler kann ich die Probleme vielleicht etwas einstufen. Menion hat es ja bereits sehr direkt angesprochen, dass das Locus Map Projekt sehr alt ist und daher sicherlich viel Code auch historisch gewachsen ist. Die Umschreibung historisch gewachsen kennt sicherlich jeder Softwareentwickler (und auch viele User).

Man will das zwar immer verhindern, aber irgendwann hat dann doch (fast) jedes Softwareprojekt jenen Status erreicht, in dem Altlasten den Takt vorgeben. Man fängt dann an, alten Code neu auszurichten (besser/schöner umzuprogrammieren) und irgendwann hat man dann viele neue Nebenbaustellen.

Bei Android kommt erschwerend hinzu, dass Locus mittlerweile sicherlich gegen die ein oder andere Deprecated-Falle anzukämpfen hat. Android ist ja nach wie vor ein relatives junges OS und Google hat leider überhaupt keine Hemmungen, Altlasten mit der Zeit als depcrated einzustufen.

Irgendwann kommt man dann nicht umhin, am Code größere Anpassungen vorzunehmen, weil Google die APIs grundlegend umbaut und die Entwickler zwingt, den Code anzupassen, wenn man die App weiterhin im Google Play Store anbieten will.
Nutzt man dann noch externe Libraries, wie das bei Locus - und fast allen komplexeren Apps - ja der Fall ist, dann muss man mitunter sehr tief ins System eingreifen und Code anpacken und umbauen, der jahrelang stabil funktioniert hat. Wenn es schlecht läuft, dann muss man einige der genutzten Libraries austauschen, weil sie nicht mehr aktualisiert wurden oder ebenfalls grundlegend neu programmiert wurden.

Menion hat zumindest einiges in dieser Richtung anklingen lassen.

Natürlich kann man sich unter dieser Prämisse, die ja mehr oder weniger von Außen vorgegeben wird, fragen, ob es dann Sinn macht, parallel zuviel neue Funktionalität aufzugreifen und nicht besser den alten Code erst mal gesund zu migrieren, um erst einmal eine stabile Adaption zu haben, die dann erst im nächsten Schritt ausgebaut wird. Da kämpft dann häufig die Theorie gegen die Praxis an und vice versa.

Fakt ist, wenn man sowieso am Unterbau dran ist, dann macht es hin- und wieder schon Sinn, gleich Neuerungen aufzugreifen, weil man neu Klassen baut oder Alte grundlegend umgestaltet und dann viele zukünftige Schnittstellen/Funktionen schon berücksichtigt werden sollten. Sonst hat man das Problem, dass man sehr schnell wieder an einem historisch gewachsenen Code laboriert, weil man zu wenig vorauschauend entwickelt hat und das neue Geschäftsmodell natürlich auch Anreize beim User generieren muss, das neue Geschäftsmodell überhaupt zu unterstützen.
Denn mal ehrlich, wenn Locus Map 4 nur eine fehlerbereinigende und an neue API Vorgaben angepasste Version wäre, dann würden viele Altkunden auf die Barrikaden gehen. Bereits bei der Umstellung des Geschäftsmodells gab es im Locus Map Blog zumindest einige sehr unfreundliche Kommentare.

Ich denke, das ist ein großer Spagat, den Menion und seine Truppe hinlegen müssen. Und ja, seine Firma ist nicht MS, nicht Apple, nicht Google, nicht Adobe und wie die Großen alle heißen. Manpower ist demnach begrenzt und die genannten Firmen sind ja auch ein gutes Beispiel dafür, dass selbst Manpower alleine nicht genügt (fast jedes größere OS Update der oben genannten mutiert ja mittlerweile zu einem Bingo Spiel).

Selbst gut gewartete Software lebt und genauso wie wir Menschen hin und wieder krank werden und einen Doktor benötigen, ist das bei Softwareprojekten nichts anders. Und nicht jeder ärztliche Eingriff ist immer erfolgreich, manchmal braucht es auch etwas Geduld, um wieder 100% gesund zu werden.

PS: Hier wurde das mangelende Qualitätsmanagement angeprangert. Ich bin seit > 25 Jahren in der prof. Softwareentwicklung tätig und es gibt wirklich wenige Bereiche, wo es mit dem Qualitätsmanagement immer gut funktioniert (medizinischer Bereich, Aeronautik, etc.). Das soll keine Entschuldigung sein, aber so ehrlich sollte man dann doch sein...
The following users thanked this post: Menion, tramp20, michaelbechtold, Graf Geo, freischneider, Joska
#2
Quote from: hawe07546 on July 27, 2025, 11:51:38
Quote from: Tapio on July 24, 2025, 21:49:19Die Erwartung, es müsse folglich alles so weiterlaufen war vor 100 Jahren unter Beamten vielleicht passend.
Eigentlich erwartet jeder rational denkende Mensch, dass durch Softwareupdates KEINE Fehler eingebaut werden.

Manchmal kommt man als Entwickler leider nicht umhin, am Unterbau Änderungen vorzunehmen (bei Android sogar öfter als einem lieb ist, da Google immer mal wieder etwas an den APIs ändert und dann vieles als deprecated deklariert wird, was im schlimmsten Fall größere Codeanpassungen bedingt).

So kann es immer mal vorkommen, dass sich selbst in altem (fehlerfreien) Code Bugs einschleichen, die man als Entwickler nicht auf dem Monitor. Schön ist das nicht, aber gänzlich vermeiden lässt sich das einfach nicht. Und Locus Map ist ja nun mal eine sehr komplexe App, Komplexität hat dann immer mal ihre Tücken, was man immer wieder aufs Neue vorgeführt bekommt.

Ich finde aber, dass das Locus Map Team den Spagat stabile App vs. Komplexität über die vielen Jahre sehr gut gemeistert hat.
The following users thanked this post: Menion, freischneider
#3
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.

The following users thanked this post: Menion, Andrew Heard
#4
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.
The following users thanked this post: Menion, Tapio, Andrew Heard
#5
Hi again,

Quote from: WRPSoft on September 13, 2024, 10:01:00...
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  8)
The following users thanked this post: Menion, michaelbechtold
#6
Quote from: Tapio on September 13, 2024, 13:30:31Thank 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) :-)
The following users thanked this post: d:BUT
#7
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
The following users thanked this post: Menion, michaelbechtold, Tapio, Michal, Andrew Heard, Mick FU
#8
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 :-)
The following users thanked this post: eph, Andrew Heard
#9
Quote from: Menion on August 23, 2024, 11:09:22Hello,
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
The following users thanked this post: BERNHARD.FRIESS
#10
Quote from: Menion on July 22, 2024, 09:25:07Hello 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);

            }
        }

     
The following users thanked this post: BERNHARD.FRIESS