This object is in archive! 

Navigation route sometimes rendered behind other objects or inconsistently

Andrew Heard shared this problem 7 years ago
Solved

Example below of navigation route apparently rendered behind the road:

8ea75a2ab5f86dc4197a20b5492e7298

Example below of navigation route rendered partly thick (correct) and partly thin:

301e7fb40b11a0c44e65d83c6e0c2a4d

For comparison, example below of properly rendered navigation route which is similar to screen cap in the manual:

794a61189164928ac5cba1724b5ba11b

Sorry but I don't have a track or way to reproduce this behavior.

Replies (14)

photo
1

Something +/- similar to next observation ? (I hope it helps here)

See picture with navtrack and POI: "Knooppunten" (name = number).

I prefer POI symbols on top above the navtrack ...they are, IF using map rotation !

c5789bb3ab93b128336760a38533ef89

photo
1

Hello guys,

this issue is in Locus for many years already. Issue is in (probably) incorrect computed part that should be drawn fat and part (behind current location) that should be drawn thin. So line is not hidden, it's just incorrectly drawn.

photo
1

Q: Is the example with the Icons versus navtrack similar ? I did not report as I mostly use map rotation, so is no issue, just is +/- strange. I notice this mainly while taking a nice screenshot only.

photo
1

The 3 screen captures were all from the same track while in navigation mode.

photo
1

Hello Willy, no no this is different story. In this case, order how items are draw on screen is little bit different in case of rotation. And in this case, track is drawn little bit later then points. Technical unsolved complications ...

photo
1

Aaaaa ecstasy!! Issue finally fixed ... thanks Andrew for a kick in right time. After many years, I'll finally see my most wanted fat line before navigation cursor, all the time :).

photo
1

Perfect Menion! For me it has occurred very rarely. I don't know how to reproduce or verify any fix. It seemed to be in testing when I stopped/ restarted navigation part way along the track. If I ever see again I'll try to capture & report.

photo
1

Not sure entirely solved. Below are screen caps from 3.20.1.12 with good (thick) & bad (thin) navigation lines. Problem still with track that does U-turn and returns to original start position?

aab6e6dc3b30c82a9f6245e18981b8b192c2d03866bf0c4ede299ea85d675ff8

photo
1

Andrew,


May I ask how did you test ? Real drive or Virtual by moving center position ?

Settings-> Navigation -> Advanced Settings -> Strict Route following: SET !

Out and Return sections: Correct Navigation by Locus ! Must Set Strict !

http://www.locusmap.eu/another-playing-with-locus-navigation-settings/

See 4. Strict navigation with auto recalculation

https://www.youtube.com/watch?v=PVivEWy3TpE

photo
1

Real bike ride.

Strict route following:UNSET.

Navigation works fine for out & return. That wasn't my point.

I am indicating the rendering of the navigation line (thick in front of current position/ thin behind) was thin instead of thick.

photo
1

Hello Andrew, Willy,

unfortunately no matter what I do, I'm unable to simulate this problem anymore.

Is this happen to you with all tracks? Any idea what trigger this problem, since which moment? Thanks

photo
1

Hi Menion. I wondered in this specific example whether the out/ return route may be a factor? It is certainly not with all tracks. I will probably ride this route in next few days so will check more closely when the rendering issue begins. I could also try to simulate. Leave it with me ;-)

photo
1

Hi @Menion. I can easily reproduce incorrect rendering of navigation track (thick/ thin) with the attached TCX route. In this example I am sure it is related to route being out-and-back along same road.

Screen cap below 15.5km remaining: position is nearing U-turn. All thick nav-track is correct:

efdae47da9ac864771d84d6a3074b434

Screen cap below 15.0km remaining: position is just after U-turn. Nav-track between U-turn and big blue arrow should be thin:

0bba9bfa2c3932f10594eda4fe183517

Screen cap below 11.7km remaining: near to strange thin/ thick nav-track. Nav-track above/ right of big blue arrow should be thin, not thick. And nav-track below/ left of arrow should be thick.

584b9581ffda3cbd06b958aca6cfcbad

Screen cap below 11.4km remaining: nav-track above big blue arrow is correct (maybe luck because now past mystery point of last screen cap), but nav-track below arrow should be thick:

ac3bb10c2eb7da52c285625f92e61aee

Files: test.zip
photo
1

Virtually I can't reproduce that behaviour. What a strange ugly generated navtrack.

Total distance: 16,13 km Traveltime: 313h55m13s ! Sloooow... ...pfff

That tcx course includes 20 Coursepoints, but 6 of them are identical.

In the example pictures (by gpx) around the return point: 15,5 km and 15 km to go ?

photo
1

good observation - track is 16km, but near 8km U-turn Locus displays 15km to go

photo
1

Hello Andrew, please export track as GPX, not TCX, there seems to be lost some parameters (like u-turn) and I'm unable to simulate your problem, unfortunately. Thanks

photo
1

Thanks Menion. GPX in V1.1 format is attached. I normally only export as V1.0 to retain maximum future compatibility. I did another test of route yesterday on bike, this time not virtual/ simulated, and noticed even more unusual double change of nav-track line thickness:

52ead3509776179b00ecd14c42f74d51

photo
1

Ah perfect, this helps, thanks! Track was separated into two segments and Locus was not able to correctly compute parts fat/slim.

photo
1

Was that my fault? To create out/return route I merged out/return tracks, each with own turn instructions. Maybe I forgot to merge without gaps? Or should Locus handle track (route) composed of multiple segments better?


Would that also explain wrong Distance to target below? Actual distance is ~4km, not 12km.

706898bbfb28f609fe731c36504dafa3

And here 7.2km to target but map shows red flag and ruler, only about 200m to target.

2e83decb15bf1d836a53f3729d489e31

photo
1

It's definitely not your issue! It may happen (gaps in track), so Locus should handle it better of course. Distances are anyway interesting. It has nothing to do with how track is drawn, so I'll rather check these as well, thanks!


EDIT: hmm I'm unable to simulate it. Maybe it's already solved? :), you will see in next version ...

photo
1

I see 2 segments but the navigation waypoints seem to be distributed "in the wild" ? Looks a very complicated, failure success inbuilt, system to me. If nav instructions where combined direct into track points even multiple track merges without any loss of attached info, would be as simple as a piece of cake. Or cut , split, merge track operations without any extra complication caused by associated waypoints. Not ?

photo
1

Menion, I don't think this bug is fixed. Attached is screen capture at end of navigation track. Clearly visible is thin navigation line then further on the proper thick line. The screen shows GPS location. It happens rarely, but in last few days each day. Track created by external BRouter method.

photo
1

Good day Andrew,

thanks for a bug report. I saw similar problem a day before on wife's phone and can't believe it. I do not know exactly this happen and even with your track, I was not able to simulate it.

Anyway I'll be watching it, thanks for notification!

photo
1

Did you have multiple tracks on the same route when you saw the problem? I had multiple tracks, different BRouter profiles of course. No problems other days but I hid the unused ones. Made no difference. I simulated too just before real completion and seemed same issue but maybe just my inexperience. At least you also see the issue. Thanks.

photo
1

Menion, I had the same repaint issue today. A few comments and recollection from when topic originally written

1 this problem fixed if route recalculated but I never wish to recalculate because precise existing route is often varied

2 no problem if use Navigate To function instead of navigation using existing track


One question: (re)calculation of existing BRouter track appears to ignore any nogo areas. Consideration of visible nogo areas (point) when creating any track using Locus track creator or editor may be good new topic.

photo
1

The day after my previous comment I observed same issue. The proper thick navigation line was only drawn 1km ahead of GPS position!


But in following 5 days of navigation using same track creation and navigation there has not been a single problem. I've tried various tricks to provoke the problem but all OK.

photo
1

Good day Andrew,

heh funny ... you personally may see, that simulate this issue is not so easy. Thank you for additional information. I'll be watching it carefully as well, so hope that soon or later we will find the key on this puzzle. Thanks for now!

photo
1

Being a cycle tour I will only be riding the track once, so not possible to test either sorry. At least it is not always a problem but somewhat strange no other reports?

photo
1

Hi Menion. Have now finished cycle tour - 3000km. As promised, attached are 3 screenshots from 3 weeks ago when last discussed. As you can see whole sections of map not rendered until Locus restarted, or even on one occasion phone restarted. There have been no more problems since.

photo
1

Good day Andrew,

3000 km, quite crazy! Hope you had a nice time not disturbed by rare Locus problems, or bad weather :).


Thanks for a screenshots. I'm riding on bike or moto last days quite a lot, always using navigation and never saw this problem. You write that for next three weeks, no more problems again. Hmm I think that issue may still be there, but because of unpredictable and really rare occurrences, we may leave it for now, thank you!

photo
1

3000km in 60 days, so not too much distance each day. Plenty of days off the bike for rest and avoiding bad weather. While traveling Locus is like my totally dependable best friend, always there when I need him for help. Hard to explain.


Planning each days route to minimize steep hills or unsealed surface is always problematic. My dream is Locus Pro 3D. Surely v3?


For sure leave it, I just wanted to let you know it was rare. Could there be a byte or two corrupted in the 800MB Italy map file maybe? I guess unlikely because a restart always fixed the problem.

photo
1

Ah 60 days, right ... nice :).


It won't be an issue in map as it has nothing to do with this. More probably some my algorithm to compute in which part of track are you currently. I just do not understand that it appear so rare and is almost impossible to simulate. Never mind ...


And 3D ... I was working on it maybe an week or two year back, but it's too much on me now. Anyway some options are coming so I definitely do not say "never".

photo
1

Menion - I have again observed this bug as discussed 3 months & longer ago where LoMap map is no longer displayed. It happened on two recent days, only when navigation enabled, only after many hours of navigation. This time with Australia>Tasmania map, previous Italy, so I believe nothing to do with actual map. I was not able to do any good testing because riding in rain and/or with other people. Observe POI and track are displayed but no roads. I was using Voluntary theme not a Locus theme and didn't have time to switch/ test.

36914661e77ec0cdff9b1a78fd178eff

Navigation stopped few minutes later:

b0f823970667bb6bbce850069dd0e605

photo
1

Hello Andrew,

sorry to hear that problem with visibility of map appear again in latest version. Unfortunately I'm sure you will understand, that without ability to simulate this problem (which is almost impossible here), it is also almost impossible to fix it. I'll be watching it ... thanks

photo
1

It's no problem for me but thought I'd report it. I don't usually use navigation for local rides but will see whether I can characterize the problem better on future longer rides. Just the fact no one else has reported anything similar is strange in itself; not sure why it would only happen to me.

photo
1

I believe you are not the only one with this problem. Few people already reported similar problems on forum as I remember. Over all these years, I wrote many various optimizations how to save some CPU power here and there during map rendering and some may be in conflict, some may not work on 100% and this is result. Solution? Find exact steps to reproduce it or completely rewrite it from scratch. First one is a problem and second ... ah, not yet :). Thanks

Replies have been locked on this page!