Re: [APP] - version 3.38.+ ( 22. 5. 2019 )

[Mips]

@menion
The problem occurs to me with different profiles. First I noticed it with "car", but also "fastbike" and "trekking" produced the same results.
I have been using the used profiles for years without any problems.
After the change back to V3.37.2, the backup was restored, the same simulation was run with the same settings and the result was immediately correct.
(I can create the video and upload it if you are interested.)
I can't tell at which V3.38.x the error occurred for the first time, but I think it was V3.38.4 or higher.

Regards
Mips
Translated with www.DeepL.com/Translator

[Menion]

Hmm, this is really weird ...

New version 3.38.7 on Google Play (just uploading). I believe I've found a reason why this happens but needs verification from anyone, who has this problem of course. Thanks

[Mips]

@menion

The first short test already looks very good.
The recalculation worked and the [Calculation...] banner disappears after a short time.
Very good!
If the long test also runs like this... .

Supplement:
The first longer test was also successful. 

Thank you
Mips

[Graf Geo]

I can confirm Mips' statement so far. The mentioned errors are no longer present.

Today during an outdoor test I noticed that the automatic recalculation under BRouter does not work reliably during navigation. Most of the time it is simply not recalculated when you leave the track. I tried it with GraphHopper and it works fine. So it seems to be a BRouter problem.

Anyway, many thanks to Menion for the tireless work.

Translated with DeepL

[Menion]

Hello guys,
thanks for confirmation of this fix. The weird problem really.

I do not know if you tested it with exactly same situations, but just keep in mind that in the app is hardcoded limit for automatical recalculation: max. once per 30 seconds.

[Mips]

@menion

...limit for automatical recalculation: max. once per 30 seconds

Thanks for that info. I didn't know that yet but that explains some unexpected behaviour. So the setting "Deviation from which the recalculation starts" is only valid if the last recalculation took place at least 30 seconds ago. This information is especially important for narrow inner city courses.

Regards
Mips

[Tapio]

Auto recalc every 30 seconds is an important information. I was also wondering if there is some delay. Please at least add the info close to the recalc settings... Or maybe you can even make it configurable... via config file at least?

[Menion]

Do not understand it incorrectly.

This value says, how much often (maximum frequency) recalculation may happen. If you start navigation and you get out of the track, recalculation happens immediately. But, if you will still ride out of this track, next recalculation won't happen sooner then after this 30 seconds.

The parameter was more dynamic in previous versions and this was a problem that happens. So in last public version is again hardcoded to 30 seconds .. for now.

From my experience during years of riding, this value is good compromise between too frequent and too late recalculations I believe.

[Tapio]

Yes, but the information should be in the UI. Keep in mind eg people are testing/simulating routing a lot with turned off GPS. 30 seconds delay until next recalc is a necessary info in this scenario.

[Graf Geo]

30 seconds is a good value.
When simulating at home with the GPS switched off, BRouter also works the way it should. The first recalculation in case of deviation takes place immediately, the next one after 30 seconds at the earliest.

Only outside with GPS switched on no recalculation took place with me mostly, neither immediately nor later after deviation.
With GraphHopper it worked as intended.

I will try BRouter again this weekend.

Translated with DeepL

[Mips]

@tapio

...people are testing/simulating routing a lot with turned off GPS

That's exactly why I haven't just switched off GPS for ages and then moved the cursor, but always use Fake-GPS for my simulations.

@menion
Maybe you can provide a variable on the config.cfg as suggested by @tapio in  for experimental users who also know what they are doing.

Regards
Mips

[Tapio]

Menion, currently your POI databases are only shown, if there is a v3 map file with the same name. Now we are in the transition to v4 maps and as you know, many of us use OAM maps. I buy your lomaps only for the poi db.
In order to display those poi dbs, I have to store v3 maps additionally. Which is unintuitive for people who do not kniw, but furthermore, creates a messy map overview. Pls at least accept same name v4 maps!

[Mips]

@menion

How is the estimated travel time calculated during route planning?
I noticed that the same route with the same settings and the same profiles on two different devices produces completely different results.
Is there an explanation?

Regards
Mips

[Menion]

@tapio
I do not agree. Some value "30 s" has nothing to do in UI. Firstly, no one should be interested in such value. The app works or not, that's the point. I told you this to give a better overview of what happened under the hood. And secondly, I really plan to make this value more dynamic, so there won't be a single "30-sec" value.

POI database should work the same, no matter which map version you have. Do you have correct naming, same as your map?

@Graf Geo
does problem with recalculation in the field happen also when the screen is on? Because if you have Android 8.x, there is a possible problem on some devices in case, the screen is turned off.

@Mips
agree that fake GPS or any similar app is definitelly better and more robust system how to test. But, a lot more complicated (more steps).

Travel time: you mean travel time at bottom panel? In case of GraphHopper routing, times on route segments is estimated on their server. From my experience, they are usually quite precise.

In case of BRouter, there are no time and Locus Map know absolutely nothing about the route itself (surface, city/highway, ...). Just a routing type and is able to compute elevation. So app internally records your traveling speed during track recording or navigation for known activity and then use this average speed for a time estimate. Time is something like an "average" from the last 60 minutes. So these times are usually fine for a hike, where your speed is around the certain average value. In case of a bike, it may be worst mainly if you change a surface or bikes. In case of the car, these values are usually useless, mainly if you combine hour of a ride over the city and then you plan route over highway . Hope my explanation is clear.

[Tapio]

OK. As for poi, I have:
Netherlands_ML.map (from oam)
Netherlands_ML.db (from lomaps)

Netherlands are not shown in country picker in poi screen.