Messages

Hello,
"add: option to hide all other tracks except the currently active one"
useful, but a little too hidden in the track menu under tools, an icon on the track info header would be better.

Be aware that if you use my attached icon you have to pay me the rights 

But isn't "search this area" exactly this? Or do you missing it even for category highlighting?

I usually use a zoom that allows me to see a very small area on the screen because I prefer to see the details.
So when I do a search as the area is small I get few results as they depend on the zoom. I would prefer to set up the search with a filter of, for example, a fixed radius of 5 km. So I would always have the list of found items regardless of zoom.
Or
You could show on the map the elements found that obviously fit on the screen, but also list those that don't fit in order of distance.
So if in the list I see what I was looking for that is outside the on-screen map, I can click on it without having to zoom out on the map and be directly centered to that point

A filter could be introduced to limit searches to a radius of x kilometers.
We thus avoid useless occurrences of results that are too distant both on the map and in the list.

@lor74cas It is correct behavior - this just indicates directions of results outside of your map while you can be anywhere else in the real. We plan to add distances from GPS position to the list of results bellow the map.

IMHO It's not what I would have expected.
If the search is done from the center of the map or from the GPS position, it is from that point that I would like the distance to be measured.

Hello,
The distance shown in the icon does not refer to GPS location or cursor, It seems the distance form screen border in mt.
Is this the correct behavioir?

For me, track recording is 4%, and optional navigation increases that to 8% (total). Will depend completely on battery size & condition & screen brightness. I therefore (mostly) never use navigation, and simply turn on the screen briefly before any potential turn. I find looking at the map far more informative & reliable than turn instructions. I have the screen timeout for 6s. Sometimes I use POI alert but to replace navigation commands would be very tedious if lots of turns.

I agree with Andrew.
In addition to keeping the consumption of Locus under control, it is also necessary to reduce that of the device.
If you don't need to be contacted by phone, you can put it in airplane mode.
If, on the other hand, a telephone connection is needed, but it is possible to give up the internet connection, data connectivity can be disabled.

I "relaxed" the policy towards permissive access in hike and bike

Yes confirmed, on the web planner now is available.
Thank you

4 months and 3 versions ago I reported this issue with the planners
https://forum.locusmap.eu/index.php?msg=69978
still not solved

Military road
access = no
but ...
foot = permissive
https://www.openstreetmap.org/way/220542005

I also allowed her to poll my position. Ie, she sends an SMS to me, my phone then sends position SMS in return. From what I understand this is what you also do.

Yes it is, but I like also your way. ICE it's a correct approach.

The reason is currently pretty simple. We do not have (yet) a system for the automatic distribution of 1' files on mobile devices. Because of this, web and also LoRouter data are computed with 3'' SRTM data > to make it "wrong" identically on all platforms.

Btw. did anyone notice the "Altitude threshold" parameter in the track edit screen? I'm experimenting with this value. For now, this may be set only for single route. Automatically is used value 5, when using SRTM data it is equal to 3.

For my use, the app and the PC are two separate worlds that communicate with each other thanks to the cloud.
On the app, to avoid memory saturation, I would be inclined not to install the LIDAR data (only let expert and aware users do it) while maintaining the updating of altimetric data as it now happens in an automatic and precise way.
But the web server doesn't have space problems, so it could contain LIDAR data where available, updates can also be made periodically based on communications from Sonny.
You could also add a feature like this:

• in Locus, in tracks settings an option "update altitude automatically during cloud sync"
• tracks are sent from the app to the cloud where the altimetry is reprocessed and then sent back to the app with a flag or description indicating that the altimetry has been reprocessed
• if you don't want an automatism, you could add an item to the already present "update altitude" in the tools with an "update altitude in cloud"

If then the problem is that of having two instruments that return two different results, just put a link on the web planner that explains what and how the altitude is calculated on the web and on the app.
Obviously it would be good to specify that it makes little sense to use a 1' reticle if you don't have a gps accuracy filter set at least below 50mt, preferably under 20mt.

[@lor74cas]

@lor74cas
...
because with the switch to android 13, I can't place them in the folder.
...

I just tested with x-plore on Android 13: even on EXT SD, this app can write to the private folders of /Android/data.
BTW: 1" alone is not delivering better results per se; only 1" plus LIDAR (Sonny's DTMs) will do.

HI,
I finally managed to install the 1" hgt files plus LIDAR (Sonny's DTMs) and they really make a difference.
To get around the problems accessing the srtm folder, I copied the files from the PC with adb by connecting the mobile phone to the PC with a USB cable.
There are several hurdles here as well:
you must have adb installed
You must have developer options enabled on your phone
you must have a good usb cable
you need to authorize the phone to connect
and you need to locate the full path to the srtm folder
but if you already have all or most of what you need then everything is resolved in a single command:
adb push /home/lorenzo/Scrivania/hgt/*.hgt /storage/self/primary/Android/data/menion.android.locus/files/Locus/data/srtm

I am more and more convinced that the webplanner must have 1" plus LIDAR data (Sonny's DTMs). There is too much difference between what locus compute with LIDAR data on the same trace computed on the webplanner.
If, for reasons of occupied space, it is reasonable that not all the 1" data be downloaded to the mobile phone, but only those of the most used areas, I don't see why on the server hosting the palnner it is not possible to have this data for all areas where they are available.

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