Re: [APP] - version 3.37.+ ( 18. 3. 2019 )

[Žajdlík Josef]

Yes it's okay. Just point out the difference between PRO and BETA. It is not clear whether this is a intention or a mistake.

[Menion]

I remember I made some smaller changes here based on some discussion on the help desk, so yes, if there is the difference, it is intent. But the link to discussion is not stored in my memory, sorry .

Anyway, the idea behind this was for sure fact, that result of export is a) not so important because automatic = "I do not want to care at that moment" and also the result is visible in notify centrum.

[Žajdlík Josef]

It might be worth considering whether to display the information center details in the event of automatic export failure. But it is just such a thought, I have no problem with it because Strava.com will announce a new route notification anyway.

[zossebart]

@zossebart
Android 4.x was my pain for maybe 2-3 years. With Android 5.x I have no single problem, all works as I need. So I can't imagine a single reason why to drop support for these Androids. Something will come, but definitely not in the nearest years.

I just wanted to thank you for your answer. This means I might get along with my trusty little Z1c for some while. Thanks!

Gesendet von meinem D5503 mit Tapatalk

[CabrioTourer]

@menion
Sorry for the late answer. I'm quite busy with my buisness.

@CabrioTourer
What is the purpose of this your trip?

Just fun.
In case I travel from A to B I don't use Locus. I use Google Maps.

In this case, Locus Map correctly tries to get you back on route, isn't it?

I think your Definition of route priority is too strict.  Yes in principle the idea of the planned route is to touch every route point when you select route priority.
But there are two different reasons why to leave the planned route. First you simply missed the navigation or you took the wrong street if there are two close together. In this case your approach is right. Redirect will be short and turn you back to the missed point is totaly fine.
The second reason is the fact that the route can't be followed. Let's say a
roadwork or the road is closed etc. In this case guiding back to the missed point doesn't help.
Then the alternativ route might be longer because it simply depends on the sreets which are available. At least for me (and I think for the majority of users) the recalculation should bring you to a useful point of the track. "Useful" in terms of easy reachable.
After back on track it should continue the route and don"t send you back to the (more or less long) part of the route you missed. In very common cases this will be a oneway because of the roadwork/road closed etc.

The App doesn't know for which reason the route was left. For this I brought up the 2 recalculation idea.
First, Locus can assume it's just a simple missed navigation etc.
After this 2 recalcs the App should assume the route can't follow this way and should find another way which means it's fine to skip a part of the route.

Here is a general problem that you skipped quite a long route segment.

That's not up to me. This depends on the available streets. As I wrote some days ago. "long" in city environment is a different thing as in rural area. In first case it might be 2 km. In the second case it's 10-20 km or whatever.
I think the distance doesn't matter. The number of streets connected to the part which follows the missed point is the similarity.

It's totaly fine to wait for the good solution of recalculation logic.
The logic is the same for 1-2 ywars now. No problem to wait a bit. Main point is to do it and do it good.

[T-mo]

@T-mo
well and how works current Locus Map Pro with this map? There should be a similar problem. Well right, in LM Pro, upscale of level 13 isn't so visible as is in Beta. Two missing levels may be a problem here.
At which scale app switch from 16 to 13 and opposite? It is mentioned 13/274%? And when you zoom out from 16 then it's 16/?%

To be honest, the 13-map isn't the best. Mostly I use a difference of 2, z10+Z12 and Z7+Z9. Just realised a difference.
Attached pictures show the difference between PRO and beta.13
PRO Z16 @100% is different than beta Z16@100%, beta is much more 'zoomed in', too much to be of use @100%.
In the past at PRO I increased the map-resolution by 175% to find my sweet spot. The pictures are without increased resolution.
Beta.13 @35% is the spot where it switches from Z16 to Z13@274% btw. Very similar to my PRO-sweet-spot.
I guess that's my 'problem': to get my PRO-like-view I have to manually zoom out..and it might happen that it switchs to Z13.
I can also not get this view to 100%, I guess it would mean sth. like 'reduce resolution'..
I have to test further. just have the feeling that auto-zoom-levels might result in less-usable-views..

[Andrew Heard]

Does this happen only with vector maps? At least that zoom in/out fit it

@menion - sorry can't help as I only use vector maps.

[slarti76]

I know, this is more "Idea" territory, but I always think it would be fantastic if that Track info bottom bar that is shown in route planner could also be activated in normal view when selecting a track? Especially the quick elevation profile looks great and is super-helpful. Otherwise, have to go to the Track Details, where I might not have set the chart to "altitude vs. distance" right now, and which always gives a slightly wrong idea of the track because of the extreme Y axis enlargement.

[Menion]

@zossebart
I had also Z1C ... it was the best phone I ever had. By my stupidity I broke it maybe a year ago, anyway it is my personal interest to keep Locus Map working on this device as long as possible .

@CabrioTourer
really no need to sorry .

The App doesn't know for which reason the route was left. For this I brought up the 2 recalculation idea.
First, Locus can assume it's just a simple missed navigation etc.
After this 2 recalcs the App should assume the route can't follow this way and should find another way which means it's fine to skip a part of the route.

This is partially implemented. After two "failed" recalculations (user ignored new route), app place temporary no-go place behind the user to force routing engine to compute forward and not backward. Anyway, this logic does not affect "target" where recalculation is done and this is what we talk about here.

I still do not see a simple solution. I perfectly understand your reasons anyway as you wrote: "The App doesn't know for which reason the route was left.". In this case (your route) it is almost circular route which complicates the situation. App has absolutely no idea if you are off route because you want to skip the whole circle or you just pick some detour because of complications on road. In rare cases when this happens, exists in the navigation menu button "Nearest point" that should fix this situation.
It is not automatic, which means it is not an ideal solution.

I'll keep thinking about it and collecting ideas. For now, I really think that changes from last weeks are quite big and this not-so-often use case may be solved in another iteration.

@T-mo
understand and thanks for screenshots.
Hope you got the point of these changes in app. If now, simply: app try to unite visibility of content of all maps. Compare vector maps and some online (raster) in Pro and in Beta. Mainly check visible texts. In Beta, there should be very similar in terms of size. On modern devices (with huge DPI), all raster maps are useless in LM Pro.

You, as well as almost all other users,  had to solve this by "Map resolution" option. This unfortunately scaled also vector maps = problem.

So generally, "Map resolution" should be no longer important settings. It may be left on default 100% except for cases, you had worst eyes and really need a larger map.

@Andrew Heard
no problem. I found an issue in pinch zoom when work with world map = fixed. On your screenshot was higher zoom so it won't be this issue, but I'll keep watching it carefully, thanks.

@slarti76
something close to what you want is planned. Anyway, some other priorities firstly

[erfi]

Beta 3.37.2.11: After starting the route planner, the visible waypoints disappear.

Beta 3.37.2.14 RC: This Problem is now eliminated. Thanks! 

[jonny.blue]

There seems to be a numbering problem in route planer:
When creating a route with planning points ... then create a via point ... the via point gets a lower number then last planning point.
Pic1: 4 planning points
Pic2: new via point

PS: checked it in 3.37.2 ... there is the same poblem.

[john_percy]

I don't know if this is a BRouter problem or a Locus problem, but it occurred in real life using the latest beta version of Locus. I've boiled it down to a particular junction for this example but it's not the only time it happened.
Navigating from N 32.38866, W 03.90318 to N 52.38831, W 03.90242 using BRouter offline set for Locus profile Fast Eco I got an instruction to "turn around" instead of "turn left". The map show a "turn left" symbol on the route, but the itinerary shows a U-turn.

[Menion]

@jonny.blue
hmm, it depends on what you clicked. If on the middle button, it says to Locus: "insert this point to the nearest place in planned route as possible". In your case, it is inserted into previous points 3 and 5. So you probably really get a route from 3 to 4 and almost back to 5.
Try to use the last third button to add cache to the route. This says "insert this point to the end of the planned route".

@john_percy
Here is exact content from BRouter that is send to Locus Map (just fresh downloaded routing data).

<wpt> has name "u-turn" and also rtePointAction: 13 indicate to Locus that navigation command is u-turn.

Code Select Expand


<?xml version="1.0" encoding="UTF-8"?>
<!-- track-length = 201 filtered ascend = 11 plain-ascend = 11 cost=610 -->
<gpx
xmlns="http://www.topografix.com/GPX/1/1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:locus="http://www.locusmap.eu"
xsi:schemaLocation="http://www.topografix.com/GPX/1/1 http://www.topografix.com/GPX/1/1/gpx.xsd"
creator="BRouter-1.4.11" version="1.1">
<wpt lon="-3.903960" lat="52.388070"><ele>293.0</ele><name>u-turn</name><extensions><locus:rteDistance>110.0</locus:rteDistance><locus:rtePointAction>13</locus:rtePointAction></extensions></wpt>
<trk>
  <name>brouter_remote_0</name>
  <extensions><locus:rteComputeType>5</locus:rteComputeType></extensions>
  <extensions><locus:rteSimpleRoundabouts>1</locus:rteSimpleRoundabouts></extensions>
  <trkseg>
   <trkpt lon="-3.903181" lat="52.388660"><ele>282.75</ele></trkpt>
   <trkpt lon="-3.903502" lat="52.388477"><ele>285.5</ele></trkpt>
   <trkpt lon="-3.903802" lat="52.388360"><ele>287.75</ele></trkpt>
   <trkpt lon="-3.903931" lat="52.388255"><ele>289.75</ele></trkpt>
   <trkpt lon="-3.903960" lat="52.388070"><ele>293.0</ele></trkpt>
   <trkpt lon="-3.903483" lat="52.388088"><ele>293.75</ele></trkpt>
   <trkpt lon="-3.903146" lat="52.388137"><ele>293.75</ele></trkpt>
   <trkpt lon="-3.902419" lat="52.388305"><ele>293.75</ele></trkpt>
  </trkseg>
</trk>
</gpx>


[Žajdlík Josef]

Beta RC. Incorrect calculation of driving time and average speed.
I add SCR of the same route from BETA, PRO, Strava.com.
Cycle Computer Length: 51.72, AVG 23.3, 2:12 Travel Time

[erfi]

Beta 3.37.2.14 RC: The statistics energy consumption are not correct. They are too high.