This object is in archive!
Locus-Brouter: Navigation instruction attached to false trackpoint.
Solved
A T deviation and return: Navigation instruction is falsely attached (too early in time) to the wrong trackpoint. When returning instruction is not attached to the correct, same positoned, trackpoint later in time.
Example with the correct example by Mapsource_JavawaRtwtool is in the zip.
Files:
T-Test Locus_Ma...
The same problem 
hm, same here
tts sound: "...right" but Locus show me the "straight ahead" arrow.
hm, same here
tts sound: "...right" but Locus show me the "straight ahead" arrow.
Hi Gynta, thanks for test and observation.
- Locus "Route and measure": The main problem is here at the generation, because issue already occurs if direct used from database after design.
- Locus direct live "Navigation to": Placing one "Via Point" at the end of that T also has the same problem.
This strange navigation can also be explained by a look at the later "by export" generated tcx timestamps.
Locus generated Coursepoint "Right" has the wrong timestamp 2016-08-22T12:59:19Z. The correct timestamp should be: 2016-08-22T13:45:29Z. If you correct this manually, navhints will show up strict in time as: "ViaPoint" followed by "Right".
Locus navigation than is succesfull, on condition that in advanced settings: Strict route navigation selected !
Why ? IF in practical drive gps position is deviating to the south, navigation easily skips part of this track, or the short leg of the T toward the "Via Point". By set Strict: All trackpoints one be one in correct order MUST be consumed !
Such a simple circuit but a very though test for a navigation system !
This same circuit can even be made more challenging by removing the "Via Point". In "Route and Measure": not placing "Via Points" by adapted config.cfg.
Only those navsystems that use and check the timestamp references will be succesfull. Positive news: Locus does !
If following carefully you will notice that nav hint "Via Point" is rather meaningless. I want it to show and express: "Return". Or see my "one vote" idea and that other idea: Flexible add "Via point".
http://help.locusmap.eu/topic/locus-track-editor-convert-to-navigation-point-add-generic
Hi Gynta, thanks for test and observation.
- Locus "Route and measure": The main problem is here at the generation, because issue already occurs if direct used from database after design.
- Locus direct live "Navigation to": Placing one "Via Point" at the end of that T also has the same problem.
This strange navigation can also be explained by a look at the later "by export" generated tcx timestamps.
Locus generated Coursepoint "Right" has the wrong timestamp 2016-08-22T12:59:19Z. The correct timestamp should be: 2016-08-22T13:45:29Z. If you correct this manually, navhints will show up strict in time as: "ViaPoint" followed by "Right".
Locus navigation than is succesfull, on condition that in advanced settings: Strict route navigation selected !
Why ? IF in practical drive gps position is deviating to the south, navigation easily skips part of this track, or the short leg of the T toward the "Via Point". By set Strict: All trackpoints one be one in correct order MUST be consumed !
Such a simple circuit but a very though test for a navigation system !
This same circuit can even be made more challenging by removing the "Via Point". In "Route and Measure": not placing "Via Points" by adapted config.cfg.
Only those navsystems that use and check the timestamp references will be succesfull. Positive news: Locus does !
If following carefully you will notice that nav hint "Via Point" is rather meaningless. I want it to show and express: "Return". Or see my "one vote" idea and that other idea: Flexible add "Via point".
http://help.locusmap.eu/topic/locus-track-editor-convert-to-navigation-point-add-generic
Hmm, but if BRouter is used, Locus generates nothing, just graphically and vocally presents
the trusted hints provided by BRouter..... Unless is verified in Brouter GPX output
the Locus presents them incorrectly....
Hmm, but if BRouter is used, Locus generates nothing, just graphically and vocally presents
the trusted hints provided by BRouter..... Unless is verified in Brouter GPX output
the Locus presents them incorrectly....
Info;
- File gpx(locus) from B-router web, same issue.
- Locus-GraphHopper correct: See tcx file in attachment.
Added a converted to gpx file by the JavawaRTWtool for easy view.
Info;
- File gpx(locus) from B-router web, same issue.
- Locus-GraphHopper correct: See tcx file in attachment.
Added a converted to gpx file by the JavawaRTWtool for easy view.
As I say, it is BRouter, not Locus issue... Wrong interpretation was rather hypothetical option. Be aware that BRouter navigation hints are not yet in full mature quality, so btter is to address it in BRouter Google group.
As I say, it is BRouter, not Locus issue... Wrong interpretation was rather hypothetical option. Be aware that BRouter navigation hints are not yet in full mature quality, so btter is to address it in BRouter Google group.
Hi guys, Libor ... well it is not precise :). Locus do quite a lot of tasks after track is computed and well ...
In this case, Locus expect that next track segment will start on exactly same location as previous stopped. And seems it is not correct. In my testing, BRouter return second track segment starting on location that is 7 centimeters next to last point of first segment. And this caused small problem in indexes ... I've fixed this problem in Locus itself, so in next version it should works correctly.
Thanks Willy for bug report and other for extra feedback!
Hi guys, Libor ... well it is not precise :). Locus do quite a lot of tasks after track is computed and well ...
In this case, Locus expect that next track segment will start on exactly same location as previous stopped. And seems it is not correct. In my testing, BRouter return second track segment starting on location that is 7 centimeters next to last point of first segment. And this caused small problem in indexes ... I've fixed this problem in Locus itself, so in next version it should works correctly.
Thanks Willy for bug report and other for extra feedback!
Well, you are right, I have forgoten about Locus using Brouter multicall mode.
But the question remains why those 7 cm ? It is 0.000001 degree of longitude near 50N latitude. It looks like some rounding error. AFAIK Arndt mentioned some Locus waypoint coordinate rounding issue, but I have thought it is already fixed on BRouter side.
Well, you are right, I have forgoten about Locus using Brouter multicall mode.
But the question remains why those 7 cm ? It is 0.000001 degree of longitude near 50N latitude. It looks like some rounding error. AFAIK Arndt mentioned some Locus waypoint coordinate rounding issue, but I have thought it is already fixed on BRouter side.
Yes I know, weird. It's the only service where is the problem and I'm almost sure, that Locus do no modifications with coordinates before and after sending requests to compute route parameters. Anyway issue solved.
Yes I know, weird. It's the only service where is the problem and I'm almost sure, that Locus do no modifications with coordinates before and after sending requests to compute route parameters. Anyway issue solved.
For completeness
From May 21 is there a commit on BRouter GitHub, in time between 1.4.2 and 1.4.3 BRouter releases,
involving the file CoordinateReaderLocus.java, so it may depend what BRouter version the user used.
Fixed rounding bug in locus/orux waypoint reading
For completeness
From May 21 is there a commit on BRouter GitHub, in time between 1.4.2 and 1.4.3 BRouter releases,
involving the file CoordinateReaderLocus.java, so it may depend what BRouter version the user used.
Fixed rounding bug in locus/orux waypoint reading
Locus V 3.18.7 testreport.
By "Route and measure": Solved.
By "Navigate to": Same problem still exist.
Locus V 3.18.7 testreport.
By "Route and measure": Solved.
By "Navigate to": Same problem still exist.
Good day Willy,
thank you for a precise testing!
During yesterday I had completely rewrote function that "Merge" tracks. After all these years I had overcomplicated system for handling of loaded tracks, it's modifications, two versions how to merge them etc. So I've decided to simplify it and unity. It will be ready for testing in next Beta version. Except some new troubles as more features has changed, but I believe it will be solved fast ;).
Good day Willy,
thank you for a precise testing!
During yesterday I had completely rewrote function that "Merge" tracks. After all these years I had overcomplicated system for handling of loaded tracks, it's modifications, two versions how to merge them etc. So I've decided to simplify it and unity. It will be ready for testing in next Beta version. Except some new troubles as more features has changed, but I believe it will be solved fast ;).
Locus v 3.18.9.2
"Navigateto" Via Point <Name> = “Location coordinates” In "Routeandmeasure" <Name> = “Via Point"
See first page attached pdf.
Locus v 3.18.9.2
"Navigateto" Via Point <Name> = “Location coordinates” In "Routeandmeasure" <Name> = “Via Point"
See first page attached pdf.
Marked as SOLVED ? Continue here ?
See also that above noticed change.
As more changes are dedected:
Changed Navigation Priority Points autorecalculate behaviour using Beta version 3.18.9.2.
And I do not find me a solution for this (was perfect in existing Pro) .
Pse have a look at the attached .zip.
Has a text note included, and the example navigation gpx file.
Marked as SOLVED ? Continue here ?
See also that above noticed change.
As more changes are dedected:
Changed Navigation Priority Points autorecalculate behaviour using Beta version 3.18.9.2.
And I do not find me a solution for this (was perfect in existing Pro) .
Pse have a look at the attached .zip.
Has a text note included, and the example navigation gpx file.
Testreport V3.18.9.4
Function: Navigate to Point.
Issue: Via point: <Name> = by Coordinates !
https://youtu.be/QjRhHmk8U2M (Sound On)
Testreport V3.18.9.4
Function: Navigate to Point.
Issue: Via point: <Name> = by Coordinates !
https://youtu.be/QjRhHmk8U2M (Sound On)
Replies have been locked on this page!