Messages

Note if you disable the GPS (satellite screen > tap to disable) then it is even simpler to see this problem. Depending on other Locus settings I do this: move cursor to track > tap on track > Navigate > Navigate - hear double beep - Locus warning that off-track. Observe that Locus is in guidance mode rather than navigation mode. Ensure cursor (simulated GPS position) is on the track > tap top/left Navigate question mark icon > Recalculate - now navigation is working.

The UI now feels very unresponsive while simulating navigation, which suggests Locus is using lots of CPU for no good reason. I will be able to confirm this tomorrow after I measure battery % after a longer ride. It is normally about 3% battery per hour.

@Andrew Heard

Pelverata Road - unfortunately I'm not sure if this is issue or not. My goal was to limit long named roads that are fare from Cities or towns. Because named road outside the city is not street (from my central European point of view ) And such road should not be in address database. When you try the reverse search near Pelverata city you can get correct value - because there is a record in offline database for this part https://www.openstreetmap.org/way/59454330 of Pelverate road

@voldapet - hmmm, strange, because another road few 100m south of example road (Talbots Rd) has correct long tap label and found with offline address search. This seems only example I have found. The road IS in the address database, simply that long tap displays wrong one. I think best to ignore report for now.

Do you think that all named roads should have a record in offline DB? Let's say that there is a long road that have about 40 km. Is it important (in Australia) to use such long road for offline address search?

absolutely, but that appears case at present?

So simple routing works fine . The issue reportedly ( Andrew, 0709 ) occur if the route goes through some trackpoint more times,
therefore there is multiple trackpoints and waypoints with the identical coordinates.  ( I cannot yet confirm )

@poutnikl no my example was just the "general case" of single waypoint corresponding to multiple track points. But it may be "red herring". Real problem is here - http://forum.locusmap.eu/index.php?topic=5119.msg42845#msg42845.

Observation: Locus will (sometimes) start in guiding mode (ignores the first waypoint/ navigation command) but with the same track other times starts correctly in navigation mode (displays distance to first navigation command). It is not dependent on whether I "Add new route" in Locus or use To/From quick-point BRouter method.

With a very simple track Locus starts 100% reliably in navigation mode.

I have also found a workaround - while guiding then tapping "Recalculate" Locus then always goes into navigation mode and displays the next waypoint (navigation command if any).

I don't know whether this applies more widely than with using BRouter as a navigation source because I only use BRouter. I hadn't experienced this problem before BRouter 1.4.x, but then again I haven't used navigation for a few months.

I'm pretty sure I've just found a BRouter bug after doing my first actual ride with BRouter navigation. But I'm a little surprised no Locus users have reported the problem, so I could be wrong, and would therefore really appreciate any Locus/ BRouter users to confirm my suspicion please.

Summary: The BRouter GPX file doesn't include a timestamp to associate each <wpt> with each <trkpt>, and so even though Locus correctly displays a blue dot icon for the navigation command, when in navigation mode Locus is unaware these waypoints are part of the track, and no navigation commands occur.

But instead of further explaining here I've done a very long post to the BRouter Google group. Please see what you think. Thankyou (!)

PS (1 day of testing later) - ignore the above text, I will create a new topic with further observations.

https://groups.google.com/forum/#!topic/osm-android-bikerouting/3A8xA6UOhOI

Huge release. Well done.

The update of Locus maps & buying of LoCoins for offline addresses worked perfectly.
I've noticed even more improvements to my "check list" of offline addresses. Streets previously associated with wrong cities have now been fixed.

I think "Points Of Interest (Beta)" was introduced in V3.5.0 December 2014. I use it a lot. Great feature. So is this really still beta? And I wonder whether it would make sense/ consistent to integrate with other "Search" functions instead of stand alone button? When I look in the list of Search functions there is group "SEARCH IN OFFLINE POI" > Search in Points/ Tracks. Isn't this also where search of POI logically should belong instead of lost & alone?

Hello Andrew, hallo Menion
...Abrensch did find the problem and I could confirm it.

@Joachim - ahh yes, glad resolved, this has caught me out too many times, I don't like the way it is either - I always try to add at least one via point so that Locus does not generate its own instructions.

<...>And sometimes when I place a point after point I do not get any routing. Than I delete the last point and repeat it and then I get a routing again.
Something is not right between Locus and the routing engine.

@Joachim - do you maybe have OsmAnd installed? I just ask because turnInstructionMode  = 1  # 0=none, 1=auto-choose, 2=locus-style, 3=osmand-style. I don't experience your problems sorry.

@Andrew Heard: hmm ... sorting location is quite common - enabled GPS? Then it's used GPS for sorting, otherwise is used map center. Don't know what may be wrong here. If you give me some data to simulate this problem, I may check it ...

@Menion - true, GPS was not enabled - I am testing from desk. However the 1st point is 92m away (correct), and the next 2 points are 16,000+km away (correct), so what is definition of "nearest"? Are you just displaying all enabled points sorted by distance? If so, then list is correct, but to me misleading. If so then maybe database query should include distance < X. Minor suggestion.

How is this new feature "nearest points" supposed to work? Clearly below 2 points are 16,000km away.

I'm playing around with BRouter turn instructions, but my beta version (3.16.2.12) doesn't want to use them.

@Joachim are you using the short-bike profile? short-bike for me is mapped to BRouter trekking.brf which I think is the only profile with new turnInstructionMode=1. It works for me nicely unless I misunderstand your situation.

Well that's what I thought ... problem is a number for you. In this case, number has increased for one single extra button at bottom, nothing more.

Ok, as I wrote, I'll discuss it with Petr and Michal and consider also your opinions, thanks.

For me buttons on left have increased from zero to one. Surely easy and consistent to have similar visibility control like other buttons and panels, suggestion: settings > Map - control & panels > Left buttons hiding?

I have noticed a new? bug with long tap labels displaying the wrong offline address. I don't recall a problem prior to current beta 3.16.2.12 but maybe I just hadn't tapped in the "wrong" places. Below I long tap on "Huon Highway" (Oceania> Australia> Tasmania) S42.59.036 E147.11.591 https://www.openstreetmap.org/way/131480712 - address in label is correct:


But when I long tap on another way "Pelverata Road" 200m to south S42.59.142 E147.11.650 https://www.openstreetmap.org/way/254103410 - observe that label incorrectly shows "Huon Highway" instead of "Pelverata Road":


So I did some more testing. Mostly the label address is correct, but sometimes not.

I can do an offline address search and the road is correctly found: map=Tasmania city=Pelverata street=Pelverata Road.

PS issue still remains in 3.17.0 Pro.

+1 = I totally agree with Michael on his "usability" comment.