Messages

For me it is so that Strava currently always shows more altitude than Locus. Yesterday I had in Locus 905 hm and in Strava 1022. Use the Current Beta
Small differences should already be taken into account. Only unrealistic jumps should be filtered out. E.g. 3 hm within 3 meters.

Different algorithms for calculating the height difference can obviously give different results, but the top of a mountain must have the correct height regardless of the algorithm.

[@lor74cas]

@lor74cas
thanks. But it was worst before I believe  . You may also find apps that will have a higher values...

The difference 14% is not bad. Anyway best is to get better results of altitude values instead of tuning algorithm that filter these values. So suggest checking the "replace of SRTM data" or "Pressure sensor" values in the Altitude manager.

You are right, I can find bad apps and websites that calculate absurd elevations, but Locus being one of the best apps must give the most correct information possible while always remaining at the high standards that distinguish it from the others.

Yesterday's excursion compared with Locus, Garmin and Strava gave more similar data: Locus 462, Garmin 445, Strava 509. However, I compared the 3 graphs and I noticed that only Strava gave the correct maximum altitude 323 meters, Locus and Garmin 316.
323 is correct as it is exactly the height of the small peak climbed.

Obviously we can't know what algorithms and what data Strava or Garmin use, but to have such an accurate altitude, I suspect that Strava uses a higher SRTM detail than Garmin and Locus.

Unfortunately, currently I'm not able to make a comparison between the normal SRTM data and the more accurate 1' data because with the switch to android 13, I can't place them in the folder.

I find the accuracy of the altimetry only useful when planning on site, when you are far from the network, and these are rare cases (at least for me). I generally plan at home, preferably on the PC. However, the web planner could use more detailed SRTM data where available in order to return more correct information.
We could also have normal SRTM data on the phones avoiding clogging them with the GB data necessary for the 1' SRTM and updating the altimetry on the server in the cloud when the track is transferred (perhaps as an option).

Hello,
since these external devices almost all have the possibility of downloading the data in txt or csv format where there is a time stamp and the monitored data, perhaps the data could simply be combined at the end of the respective recordings.
Unless it is essential for the user to see everything immediately on Locus as is the case for cyclists who want heart rate and power always visible.
@Menion do you think it is possible to combine a csv with a data and timestamp to a gpx track in locus, a bit like this site should allow https://gotoes.org/strava/Combine_GPX_TCX_FIT_Files.php ?

- too high results compared to most of the other apps

I think this goal has not been achieved

When I go out, I record with both Garmin and Locus, I use Locus for maps and as a backup, often after the activity I delete the track on Locus. But I noticed a notable difference between the difference in altitude calculated between the two. Thinking it was due to the separate GPS data recordings or the fact that I often forget to stop the Locus track in time, I didn't give it any importance.
But reading Graf Geo's post I checked better and the calculation of Locus makes me doubt.

So to avoid comparing tracks taken with different devices, I downloaded the GPX from Garmin and loaded it into Locus, updating the altitude.

Locus 998
Garmin 860
Strava 864


Strava uses the same data as Garmin and there is a small difference between Garmin and Strava due to the different algorithm used, but Locus is very far from these values.

@Menion if you need I'll send you the GPX and the Garmin and Strava links privately

I remember this
https://forum.locusmap.eu/index.php?topic=8235.msg69978#msg69978
2 months and 2 versions ago and still not solved.

I tried the openstreetmap planner and all the possible profiles (Valhalla, OSRM, GraphHopper) they allow passage on the military road while locus does not.

@Radim V

[@lor74cas]

@lor74cas
hmm back button to the menu ... it is something I'm not perfectly OK with. The list of functions, even if it looks like a full screen, is closing when any function starts (like a small dialog). So "back" has nowhere to return. And I personally never had a problem with it.

you didn't have any problems because you are the developer  and you don't explore the functions of the app like a normal user, or a forgetful like me. I often navigate the locus menus and to do that I start from "all the function" and when I go back I expect to go back to the previous window instead of being slammed on the map, it's not pleasant.
You can always say it's a feature and not a bug, but that claim has been used in the past to little effect 

[Beta version 4.14.2.4]

New Beta version 4.14.2.4 just uploaded.

---

@lor74cas
This is a topic I was thinking about a few weeks ago. First, currently best solution I have, is in the weather screen. Cross button in the top-left that always closes the screen + hardware back allowing return from detail to full overview or close also.

Which screen has currently a major problems?

all-> general->  any sub screen / do not go back to General with back button
all-> map tools -> any sub screen / do not go back to MAP TOOLS with back button
ALL -> TRACK -> TRACK MANAGER ...

HI,
I noticed that several forms have the back button <- but in fact they don't go back to the previous form but exit completely.
Therefore:
for buttons <-- the forms should go back to the previous form
or
they should be modified with X to indicate the exit.

You cannot view this attachment.

Hello,
search for hardware (not for volume or button)

I think they are exaggerating a bit here. Why do they always have the screen on ? Normally they are hiking or biking and look at the path. On Locus you look only if you need information. So the screen can stay off 70% of the time.

Yes, I agree, but everyone uses his device as he sees fit, in my case:
I start recording with Locus and only use the phone to take pictures or at crossroads when I have to choose which way to go, so during any excursion Locus is only active for a few minutes.
I prefer to turn it on for a few seconds and thanks to the high contrast of the icons I can see all the details even in full light, changing these settings in my case would be worse.
The copyright symbol could be less shiny (it's only there as a requirement) and that wouldn't be a problem, but the other icons the way I use them shouldn't be changed.

In addition, the displays have timers that first reduce the brightness and then turn off the display to avoid this type of problem, just set a timer that suits your needs.

Perhaps the problem arises for those who use Locus as a navigator in the car and want to leave it always active. If this is the problem, it would be useful to tie the brightness of the icons to a profile for example for use in the car.

I believe that instead of only checking the accessibility values ��there is a filter on the name, just like I don't allow to pass "military road" so in your case it does not allow you to pass on "tram route"
https://forum.locusmap.eu/index.php?topic=8235.msg69978#msg69978

[@lor74cas]

@lor74cas
thanks for the reminder about older posts. The first is more on @Radim V , I've informed him. Second about HEIC ... well even the latest Android 13 on Pixel 5 is unable to take photos in this format. Your Samsung device is capable of?

https://www.quora.com/Why-are-my-Android-photos-HEIC-instead-of-JPG

just for reminder I remember the unsolved problems of the previous post:
https://forum.locusmap.eu/index.php?msg=69978
https://forum.locusmap.eu/index.php?msg=69953

[@lor74cas]

@lor74cas
Weather is discussed mainly here on the help desk. Two points are solved now. "Yellow", hmm, I do not know. I may delete value by 3, but on the second side, app display 3-hours interval ...

if you mean it as frequency it's better in 1h if you mean it as rainfall in time period then that's okay, but I'm used to the hourly frequency so it seemed anomalous to me

Hello,
some small problems on the weather forecast part
You cannot view this attachment.

BLUE: seems to indicate "back" but its function is "exit"
RED: The unit of measure is misaligned due to the word "Percepita" causing the text to slip
YELLOW: This is not an error, but it is strange to see a 3 hour interval, it is usually hourly, but it is indicated and therefore if one pays attention to it, one should understand it.

The source of the weather data is never mentioned, which is now openweather

The user guide is out of date with references to Dark Sky