Messages

As we discussed in the "App update" topic, this should be correctly solved now. Thanks!

[@Graf Geo]

@Graf Geo
problem with incorrect order of nav. points > should be fixed

missing path in the new gallery to attachments > added "Info" dialog

@Diddi
update of geocaches > there were some updates of Geocaching4Locus and if I am correct, the last one fixed this.

@jonny.blue
lab caches > and do you have disabled "Incl. found by me" at the end of the filter?

@balloni55
it is important to tell me if the feature comes from Geocaching4Locus or internal Locus Map. If you are un-sure, from where you start not working feature?

[@Tapio]

@Tapio
thanks for the map & theme. I'm unfortunately still unable to simulate it. This happened some time ago, but I hoped, it is fixed, hmm.

Hagen trip > I'm getting a nice 5.5h when using LoRouter https://link.locusmap.app/r/sjie8b . For me, a priority now is to fine-tune LoRouter times & parameters. We may look at BRouter later...

@Graf Geo
ah, thanks and sorry you had to describe it "again". I've forgotten to instructions generator  . The "Navigation" button in the toolbar is a shortcut to start the navigation immediately, without the "Navigation/guidance chooser". And yes, there was an issue. Fixed, thanks!

@Diddi
thanks, got it. Check please Beta tomorrow (or Friday) or there will be for 90% new public version on Google Play next week.

Only the German translation of "collapse/expand" is not ideal. Perhaps "einklappen/ausklappen"

done, see next version

Old topic, sorry ...

Analyzing and .. interesting problem.

The last point of the "Startteil..." route has an almost identical location as the first point of the original recorded route. This is probably what you wanted. Because of this, the app refused to insert a space (break point) between them and the result was, that time was from "0" (1. 1. 1970) till the day of the second route. This was not the case of the second manual route, where the last point was not identical.

I've improved this behavior, so it should be better in the next app version.

And I've again merged posts into this one topic, sorry

This is not so easy task to do. As you may see, even online maps in the Android app do not have this feature. Because online maps are currently based on the raster (so simply JPG/PNG pictures), it is not possible to modify it's content. So maps without hiking/cycling trails means second web server that will supply "duplicate" map. Very expensive solution!

Because of iOS version we are working on (not just), we are discussing the option to use vector data also for the online maps! Well better > we will have to use vector data for online maps soon or later. This will allow us to also quite easily implement this feature.

It will take some time, hopefully not much. Locus Map for iOS is already prepared for online vector maps. Web planner will be for sure during next year and Android ... hmm, it will be harder, but in the worst case, Android may still use raster data ..

Hope my explanation is clear. Feel free to ask if something is not clear ...

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.

Here's a good read for a better understanding of why elevation gain calculation can vary drastically - there is no simple truth. It helped me a lot. Eg., "Choosing an elevation threshold" is a very relevant factor.

https://www.gpsvisualizer.com/tutorials/elevation_gain.html

Haha yeah, I only use Sonny's best hgt files. Last year I had to disappoint a friend of mine who proudly walked over a 1050m hill in Schwäbische Alb, which in fact was <1000m. Also a lot of hill elevations in OSM are rather drastically off (>50m at times), source may have been barometric measurement or lack of geoid model, I correct those attributes if I find them. Well, some data are pretty old.