Messages

@menion - regards "chg: connection to GPS automatic restart in case of connection troubles" - I have now experienced twice that GPS never starts if the device has been inside with GPS disabled for few hours then I run Locus outside with GPS enabled. The satellite map just sits with nothing on the map forever:


It makes no difference if I disable > re-enable the GPS from the satellite map.

Only workaround (so far) - drag down Android top notification panel > disable Location > enable Location > then from Locus satellite map disable GPS > enable GPS > then satellites appear as normal, fairly quickly.

With some help from @poutnik I have more to report. I have navigation recalculation mode = Never. It appears in this mode that when navigation along existing track, and if GPS position is not precisely over track, then navigation mode never occurs, or is very unreliable:


I started navigation 10 times, and only once did it work. The other 9 times guidance mode commenced, and never switched to navigation. It also seems that the longer the track the less likely navigation will commence.

When I set recalculation mode = Route, operation automatically switches from initial guidance to navigation shortly after moving, so for now I'll use this mode.


When I read the manual http://docs.locusmap.eu/doku.php?id=manual:user_guide:functions:navigation:settings&s[]=recalculation it is still not clear when mode = Never why starting navigation is so unreliable if the position (as shown in screen cap) is directly over the track.

Just guessing -  Is possible you have for any reason too low value of off-route threshold,
when Locus switches to guidance instead of naviagtion ?

I generally use "Maximum allowed deviation"= 50m. It has never been a problem before.

Other reason may be Locus gets confused and under mysterious conditions interprets Hint waypoints as waypoints for Guidance.

Either new setting or something else has changed because I never had this problem before now.

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.