Navigation for imported track
There is one function that I'm thinking about for a long time.
When I go for a trip (road bike), I grab recorded track from bikemap and I use voice directions generated from the shape of track.
It took me quite a long time to go through crossing straight ahead without any voice and any fear that something is wrong.
BUT there is something really annoying. I'm getting voice navigation in every bent or turn. I't quite OK when you ride on highway, but when riding in serpentines...
My idea: you can detect changes of direction (you generate voice order for a such place). What if you make it via-point for navigation and generate navigation from those via point? You don't have to use all turning points, its very likely, that generated navigation would be the same even with fewer points. You can "validate" navigation track and possibly to add some more via point and re-generate.
The result would be common navigation (orders in straght crossings, no orders in bents without any crossing).
I like this idea 
Good day Hrabosh,
interesting idea if I understand correctly, but how may this be done? You wants to compute navigation ( by MapQuest probably ) between all generated navigation points and then merge it? So shape will be same as original track, but only valid commands will be there. Am I understand correctly?
Good day Hrabosh,
interesting idea if I understand correctly, but how may this be done? You wants to compute navigation ( by MapQuest probably ) between all generated navigation points and then merge it? So shape will be same as original track, but only valid commands will be there. Am I understand correctly?
Good evening
I proposed one more step. I guess that computing navigation between all navigation points would demand too much system resources. I think that you can pick one via point every 5km (or so), compute and then compare if all generated point are on the computed navigation track. I not, you would add some more via points and recalculate (or replace that part with data from the uploaded track).
Here https://mapy.cz/s/DDoy you get just "turn left" on the top of the hill, then you build up a speed, you pass the crossing and the bridge and Locus is mute. Then you go for next 700m (quite a lot on bike) before you get command that confirms the direction. It took me one season to stop double checking in such situations.
On other places you get so many commands that Locus doesn't finish one before it starts another https://mapy.cz/s/DDmw SHUT THE FUCK UP! I do know where to go, there are steep rocks!
Finally, here: https://mapy.cz/s/DDpv you don't get any command (there is no significant bent on the track).
Good evening
I proposed one more step. I guess that computing navigation between all navigation points would demand too much system resources. I think that you can pick one via point every 5km (or so), compute and then compare if all generated point are on the computed navigation track. I not, you would add some more via points and recalculate (or replace that part with data from the uploaded track).
Here https://mapy.cz/s/DDoy you get just "turn left" on the top of the hill, then you build up a speed, you pass the crossing and the bridge and Locus is mute. Then you go for next 700m (quite a lot on bike) before you get command that confirms the direction. It took me one season to stop double checking in such situations.
On other places you get so many commands that Locus doesn't finish one before it starts another https://mapy.cz/s/DDmw SHUT THE FUCK UP! I do know where to go, there are steep rocks!
Finally, here: https://mapy.cz/s/DDpv you don't get any command (there is no significant bent on the track).
A nice idea indeed.
I already had a test as such, earlier but it seems now I had missed that important step to generate from the .tcx Coursepoints ! Now I produced in a fast test (late evening) a new Nav file file from a simple track source.
And a first testreport ! This first result indeed seems not to be that bad !
The resulting track has only some small trackglitches. (Zoom in along track to see).
Probably because the source track was generated based on google maps materal I supose and all other steps are based on sligthly different OSM map material.al
Further I do miss a part of the start and the end of the track.
The reason for that is that in the produced tcx ( file 2) no start and no stop coursepoints are generated. 2 x Generic (flags) placed on start and stop should solve that problem for the (re)router I suppose.
So in attached zip you find the produced files from all steps. Study help of JavaWaRtwTool as it can go faster by direct reimport (recycle) the midstepresults in the JavaWaRTWtool.
1. A normal (generated) +/- 2 year old gpx track, probably based on google map material from an online generator I think the origin was from www. fietsnet.be. And later timestamps corresponding to 18kmh where added.
2. By JavaWaRTWtool generate a tcx course with coursepoints generated if trackpointangle >50° . Coursepoints generation is based on the single trackpoint angles, see help JavawaRTwtool.
3. Then by the JavaWaRTWtool from the new tcx course convert the coursepoints to gpx waypoints, by Right click to show the waypoints. Than convert "skip track" and select all waypoints (the old coursepoints) to convert these to Direct route. (gpx)
4. Import direct route gpx in Garmin Mapsource. Used map: "open fietsmap" (nl) a routable Garmin compatible map based on OSM sources).
The direct route show the typical straight lines between the few coursepoints so in mapsource now select recalculate route. then export in the .gdb garmin file format.
5. Open the .gdb file with the Javawa RTWtool convert to .tcx with Coursepoints. Ready for Locus.
6. Converted .tcx file with coursepoints to .gpx file with associated waypoints. To study open this last file with freeware "gpx editor" for example.
A nice idea indeed.
I already had a test as such, earlier but it seems now I had missed that important step to generate from the .tcx Coursepoints ! Now I produced in a fast test (late evening) a new Nav file file from a simple track source.
And a first testreport ! This first result indeed seems not to be that bad !
The resulting track has only some small trackglitches. (Zoom in along track to see).
Probably because the source track was generated based on google maps materal I supose and all other steps are based on sligthly different OSM map material.al
Further I do miss a part of the start and the end of the track.
The reason for that is that in the produced tcx ( file 2) no start and no stop coursepoints are generated. 2 x Generic (flags) placed on start and stop should solve that problem for the (re)router I suppose.
So in attached zip you find the produced files from all steps. Study help of JavaWaRtwTool as it can go faster by direct reimport (recycle) the midstepresults in the JavaWaRTWtool.
1. A normal (generated) +/- 2 year old gpx track, probably based on google map material from an online generator I think the origin was from www. fietsnet.be. And later timestamps corresponding to 18kmh where added.
2. By JavaWaRTWtool generate a tcx course with coursepoints generated if trackpointangle >50° . Coursepoints generation is based on the single trackpoint angles, see help JavawaRTwtool.
3. Then by the JavaWaRTWtool from the new tcx course convert the coursepoints to gpx waypoints, by Right click to show the waypoints. Than convert "skip track" and select all waypoints (the old coursepoints) to convert these to Direct route. (gpx)
4. Import direct route gpx in Garmin Mapsource. Used map: "open fietsmap" (nl) a routable Garmin compatible map based on OSM sources).
The direct route show the typical straight lines between the few coursepoints so in mapsource now select recalculate route. then export in the .gdb garmin file format.
5. Open the .gdb file with the Javawa RTWtool convert to .tcx with Coursepoints. Ready for Locus.
6. Converted .tcx file with coursepoints to .gpx file with associated waypoints. To study open this last file with freeware "gpx editor" for example.
For me Locus with offline "compute instructions" set is useless because as Hrabosh says "I'm getting voice navigation in every bent or turn". Known issue. Many many other related discussions in help and forum. So for my time so far with Locus over last year I simply use offline BRouter and manually add navigation instructions with the track editor. Tedious for long cycle daytrip but better than instruction for every minor bend where no actual junction. But Hrabosh check out BRouter - is experimenting with auto generating navigation instructions itself, and so far the results have been excellent, so I am eagerly waiting for the next non-beta BRouter version. It doesn't help with exact suggestion of existing recorded track but maybe still worth learning.
For me Locus with offline "compute instructions" set is useless because as Hrabosh says "I'm getting voice navigation in every bent or turn". Known issue. Many many other related discussions in help and forum. So for my time so far with Locus over last year I simply use offline BRouter and manually add navigation instructions with the track editor. Tedious for long cycle daytrip but better than instruction for every minor bend where no actual junction. But Hrabosh check out BRouter - is experimenting with auto generating navigation instructions itself, and so far the results have been excellent, so I am eagerly waiting for the next non-beta BRouter version. It doesn't help with exact suggestion of existing recorded track but maybe still worth learning.
Of coarse Andrew, when creating a new track. And lets hope, by Brouter soon to be able also to create intelligent instructions, even when mobile.
But what Hrabosh is talking about, is to add intelligent instructions to already existing simple track. Create a simple track is no probem, and some online services (http://www.fietsnet.be) also offer to add simple POI's, but rarely with embedded strict navigation instructions. And if they do, the output system is by .tcx files (Ride with GPS) and without any addition of simple information POI's. ( .tcx !)
Actually the best method to transform existing tracks was to use the "old track" as template and redesign a new track with help of "a" router program. Creating a new design in a few clicks and add the "intelligent" Navinstructions.
Idea launch here: ¨Possible ? Test only by a pc, should be no problem, is only to show if idea is usable, yes or no. Goal: (Re)create the track inclusive new "intelligent" navigation instructions and export in .tcx format.
Or ? Export into *universal gpx track with strict nav instructions, and so keep all normal POI's from the original track(s), as less limited than in .tcx system. Aahumm..*.(= there is actually no such a gpx standard norm ! )
Yes, many steps are necessary in previous late evening test, but if delivering succesfull results, of coarse to be automated, otherwise this brings no time gain against designing a new track (by a router) with only a few clicks (using track template).
The problem I had in my previous tests. I always had big track glitches because there is no function "snap track on mapped roads" . In the end, I had such large trackglitches where many navigation instructions "in and out" of these glitches where placed. Or total useless.
Where it went wrong in previous test ? To long ago to remember where my mistakes where.. And now this suggestion by Hravosh, so a retry. To my surprise in last late evening test, the generated navinstructions are at the correct places and not at trackglitches !
See the difference between tcx file 2 and file 5 !
Of coarse Andrew, when creating a new track. And lets hope, by Brouter soon to be able also to create intelligent instructions, even when mobile.
But what Hrabosh is talking about, is to add intelligent instructions to already existing simple track. Create a simple track is no probem, and some online services (http://www.fietsnet.be) also offer to add simple POI's, but rarely with embedded strict navigation instructions. And if they do, the output system is by .tcx files (Ride with GPS) and without any addition of simple information POI's. ( .tcx !)
Actually the best method to transform existing tracks was to use the "old track" as template and redesign a new track with help of "a" router program. Creating a new design in a few clicks and add the "intelligent" Navinstructions.
Idea launch here: ¨Possible ? Test only by a pc, should be no problem, is only to show if idea is usable, yes or no. Goal: (Re)create the track inclusive new "intelligent" navigation instructions and export in .tcx format.
Or ? Export into *universal gpx track with strict nav instructions, and so keep all normal POI's from the original track(s), as less limited than in .tcx system. Aahumm..*.(= there is actually no such a gpx standard norm ! )
Yes, many steps are necessary in previous late evening test, but if delivering succesfull results, of coarse to be automated, otherwise this brings no time gain against designing a new track (by a router) with only a few clicks (using track template).
The problem I had in my previous tests. I always had big track glitches because there is no function "snap track on mapped roads" . In the end, I had such large trackglitches where many navigation instructions "in and out" of these glitches where placed. Or total useless.
Where it went wrong in previous test ? To long ago to remember where my mistakes where.. And now this suggestion by Hravosh, so a retry. To my surprise in last late evening test, the generated navinstructions are at the correct places and not at trackglitches !
See the difference between tcx file 2 and file 5 !
@Andrew: It seems that you've missed my point. I can download road bike marathon (200km+) from bikemap and I want to get useful command for that track. I don't bother whether I get useful navigation commands online or offline in this topic. I know that there are some geek solutions (and I know how to use it), but Locus is not aiming at geeks. So geek solutions are simply unacceptable :-)
Locus team seems to work a lot on navigation possibilities in these months and they've recently added via-point possibility for navigaton, so my suggestion started to be actual. I'm thinking about that approximately for two years, but without via-points was the idea useless.
@Andrew: It seems that you've missed my point. I can download road bike marathon (200km+) from bikemap and I want to get useful command for that track. I don't bother whether I get useful navigation commands online or offline in this topic. I know that there are some geek solutions (and I know how to use it), but Locus is not aiming at geeks. So geek solutions are simply unacceptable :-)
Locus team seems to work a lot on navigation possibilities in these months and they've recently added via-point possibility for navigaton, so my suggestion started to be actual. I'm thinking about that approximately for two years, but without via-points was the idea useless.
I got your point. But in case your suggestion never gets implemented I was just politely trying to offer possible workaround.
I got your point. But in case your suggestion never gets implemented I was just politely trying to offer possible workaround.
Long discussion I would like to stop till you all spend on it too much time.
I think that such solution is impossible to create for a two three main reasons:
Quite nice solution is see now is using our new system we prepare for offline search of addresses. Theoretically it should be possible to test it, if certain generated command is on any real cross, or at least close to any.
I'll be thinking about it once our system for offline address search will be tuned enough to do some other tasks with it. Hope my arguments are clear. Thanks for understanding.
Long discussion I would like to stop till you all spend on it too much time.
I think that such solution is impossible to create for a two three main reasons:
Quite nice solution is see now is using our new system we prepare for offline search of addresses. Theoretically it should be possible to test it, if certain generated command is on any real cross, or at least close to any.
I'll be thinking about it once our system for offline address search will be tuned enough to do some other tasks with it. Hope my arguments are clear. Thanks for understanding.
And what if converting a recorded (high density) track (by Locus) ? See the results in zip.
I added one additional step. Open the record in gpx editor. Right click on the track and select edit track points.
Simplify by Point reduction by Douglas Peucker and save file gpx. The new source file to convert to a navigating track. In a few minutes generates a tcx track with the coursepoints.
For your info I added in File 7 = the gpx version with the associated waypoints !
No Locus app support for this associated gpx file, but result is very similar to .tcx !
Have a look at both tracks positions and for more comfort open in "gpx editor" pc program.
Open the waypoint file list.
See the detailled street info in <cmt> and <desc> and <sym> is using the standard Garmin symbols.
From tcx to gpx by JavawaRTWtool. ( A mainly Garmin supporting app !)
Mapsource and routable maps ? http://www.openfietsmap.nl/
btw Menion I just missed your previous reply ;-).
For those users in search for a nice conversion using pc programs ... ! ! Give it a try.
I hope some good info.
And what if converting a recorded (high density) track (by Locus) ? See the results in zip.
I added one additional step. Open the record in gpx editor. Right click on the track and select edit track points.
Simplify by Point reduction by Douglas Peucker and save file gpx. The new source file to convert to a navigating track. In a few minutes generates a tcx track with the coursepoints.
For your info I added in File 7 = the gpx version with the associated waypoints !
No Locus app support for this associated gpx file, but result is very similar to .tcx !
Have a look at both tracks positions and for more comfort open in "gpx editor" pc program.
Open the waypoint file list.
See the detailled street info in <cmt> and <desc> and <sym> is using the standard Garmin symbols.
From tcx to gpx by JavawaRTWtool. ( A mainly Garmin supporting app !)
Mapsource and routable maps ? http://www.openfietsmap.nl/
btw Menion I just missed your previous reply ;-).
For those users in search for a nice conversion using pc programs ... ! ! Give it a try.
I hope some good info.
Don't know how they do it, but here they do some nice routeplanning: http://www.outdooractive.com/de/tourenplaner/
Don't know how they do it, but here they do some nice routeplanning: http://www.outdooractive.com/de/tourenplaner/
That would be a very important function. When hiking, the unneeded instruction is very bad. every time take the phone out of his pocket. If the track recalculated with Brouter would be very nice. Did it for a hike 10 km made. every 200m in the route planner set an shaping point. The calculation went very fast. So Locus could do that automatically. In the route planner every 200m convert a track point into an shaping point and recalculate it with Brouter.
That would be a very important function. When hiking, the unneeded instruction is very bad. every time take the phone out of his pocket. If the track recalculated with Brouter would be very nice. Did it for a hike 10 km made. every 200m in the route planner set an shaping point. The calculation went very fast. So Locus could do that automatically. In the route planner every 200m convert a track point into an shaping point and recalculate it with Brouter.
Navigate a track (No navigation info attached !) Sharing my experiences so far:
By various track sources.
A: Low quality (off road) recorded track. = Large gps deviations, uncleanded "dirty" tracks.
B: Normal quality "on road" track generated by (a) router but without integrated navinstructions.
Source A+ B: By trackshape. My actual setting. UNSET.
* Settings > Navigation > Advanced settings > Frequency of commands: None.
Source A . Attach nav instructions by B-router or GraphHopper by manual edit.
Create nav track using the displayed track as template. A few clicks and ready.
** Avoid unexpected track glitches and strange nav commands !
Source B: Auto attach navinstructions inclusive a "track to street snap" method.
I had some experimental short tests only, for now no practical usage for the Locus app.
*** Test by Komoot web > app. (GraphHopper engine ? )
* http://help.locusmap.eu/topic/vibration-and-vocal-announcements-navigation-on-wear#comment-62061
** http://help.locusmap.eu/topic/confusing-arrows-and-voice-commands-during-route-navigation#comment-62069
*** http://help.locusmap.eu/topic/why-points-with-low-gps-accuracy-get-recorded-anyway#comment-62071
Navigate a track (No navigation info attached !) Sharing my experiences so far:
By various track sources.
A: Low quality (off road) recorded track. = Large gps deviations, uncleanded "dirty" tracks.
B: Normal quality "on road" track generated by (a) router but without integrated navinstructions.
Source A+ B: By trackshape. My actual setting. UNSET.
* Settings > Navigation > Advanced settings > Frequency of commands: None.
Source A . Attach nav instructions by B-router or GraphHopper by manual edit.
Create nav track using the displayed track as template. A few clicks and ready.
** Avoid unexpected track glitches and strange nav commands !
Source B: Auto attach navinstructions inclusive a "track to street snap" method.
I had some experimental short tests only, for now no practical usage for the Locus app.
*** Test by Komoot web > app. (GraphHopper engine ? )
* http://help.locusmap.eu/topic/vibration-and-vocal-announcements-navigation-on-wear#comment-62061
** http://help.locusmap.eu/topic/confusing-arrows-and-voice-commands-during-route-navigation#comment-62069
*** http://help.locusmap.eu/topic/why-points-with-low-gps-accuracy-get-recorded-anyway#comment-62071
This is an important topic. Currently we have to rebuild tracks to have them useful for routing. Locus could show more support here.
This is an important topic. Currently we have to rebuild tracks to have them useful for routing. Locus could show more support here.
here is also in the German forum a discussion on this topic:
http://forum.locusmap.eu/index.php?topic=6285.0
The topic of navigation is becoming increasingly important. there are a lot of discussions in the German forum right now.
here is also in the German forum a discussion on this topic:
http://forum.locusmap.eu/index.php?topic=6285.0
The topic of navigation is becoming increasingly important. there are a lot of discussions in the German forum right now.
Many are looking for tracks on the internet, for example at Komoot or Outdooraktiv. Then they want to have a good navigation with BRouter at Locus.
Many are looking for tracks on the internet, for example at Komoot or Outdooraktiv. Then they want to have a good navigation with BRouter at Locus.
Navigation becomes a very important topic. Good navigation of tracks from the internet is a very important feature. And BRouter is the best app for it.
Navigation becomes a very important topic. Good navigation of tracks from the internet is a very important feature. And BRouter is the best app for it.
There are often navigation announcements that are not necessary. The road makes only a slight bend but you can not drive otherwise. Unfortunately that happens very often and disturbs a lot.
If you let the track be calculated by BRouter while navigating a track, that does not happen. For this, Locus would have to automatically place the shaping point on the track. Has already been mentioned.
There are often navigation announcements that are not necessary. The road makes only a slight bend but you can not drive otherwise. Unfortunately that happens very often and disturbs a lot.
If you let the track be calculated by BRouter while navigating a track, that does not happen. For this, Locus would have to automatically place the shaping point on the track. Has already been mentioned.
The navigation of an imported track is bad. There are no necessary instructions.
I always have to redraw the track with the route planner. Then come good instructions from Brouter.
For this I have to put a point in many places on the track. This work could do Locus automatically !!!!!!!!!
The navigation of an imported track is bad. There are no necessary instructions.
I always have to redraw the track with the route planner. Then come good instructions from Brouter.
For this I have to put a point in many places on the track. This work could do Locus automatically !!!!!!!!!
Yes, this is because of the quality of the trackpoint recording.
But yes. Locus Map, more generally, could offer a track repair function which would align tracks to the closest road/path/etc.
Yes, this is because of the quality of the trackpoint recording.
But yes. Locus Map, more generally, could offer a track repair function which would align tracks to the closest road/path/etc.
I also think the quality of the original recorded track is very important. I have na example of one of my own recorded tracks, length 6,5 km.
If I navigate along this track calculated with B-router and the proper walking profile it gives me about 25 commands and the only diversion is seen in the attached image. Purple is the original track and blue is the calculated navigation track. So no problem for me.
I also think the quality of the original recorded track is very important. I have na example of one of my own recorded tracks, length 6,5 km.
If I navigate along this track calculated with B-router and the proper walking profile it gives me about 25 commands and the only diversion is seen in the attached image. Purple is the original track and blue is the calculated navigation track. So no problem for me.
Is something planned here? It is always very tedious to rebuild the imported track with shaping points. Locus could do something like that automatically. Then check it once again and correct any small Things.
Is something planned here? It is always very tedious to rebuild the imported track with shaping points. Locus could do something like that automatically. Then check it once again and correct any small Things.
This is easy to say, not so easy to even come with a suitable algorithm to do so.
E.g. a real turning point in the original track must not become a shaping point, as it would otherwise become an endpoint for a route segment calculated by BRouter. Brouter for obvious reason does not create navigation hints for route endpoints.
Another thing is, how LocusMap would know which points are true turning points, which track points to remove and which to stay to become shaping points ?
As a workaround for such an approach I see:
passing the original track through very strong online track filter like Douglas Peucker algorithm,,eliminating most of less important points, importing the track, turning some of non-true-turning points into shaping points, deleting the rest and letting BRouter to recalculate thr route.
But IMHO much less work would be creating a no
ew route with just a few needed shaping points ( or preferably viapoints for round or near round routes ) in the Router planner, according to the visual pattern of the displayed original track.
This is easy to say, not so easy to even come with a suitable algorithm to do so.
E.g. a real turning point in the original track must not become a shaping point, as it would otherwise become an endpoint for a route segment calculated by BRouter. Brouter for obvious reason does not create navigation hints for route endpoints.
Another thing is, how LocusMap would know which points are true turning points, which track points to remove and which to stay to become shaping points ?
As a workaround for such an approach I see:
passing the original track through very strong online track filter like Douglas Peucker algorithm,,eliminating most of less important points, importing the track, turning some of non-true-turning points into shaping points, deleting the rest and letting BRouter to recalculate thr route.
But IMHO much less work would be creating a no
ew route with just a few needed shaping points ( or preferably viapoints for round or near round routes ) in the Router planner, according to the visual pattern of the displayed original track.
Place a shaping point at the beginning of the track. Then set a shaping point every x meters (for example 200m) and at the end another one. Then have it calculated. Correct by hand where the displayed track does not match the planned route.
Place a shaping point at the beginning of the track. Then set a shaping point every x meters (for example 200m) and at the end another one. Then have it calculated. Correct by hand where the displayed track does not match the planned route.
At 40 km and one point every 800 meters, there are 50 shaping points. That shouldn't be too much. But the user could choose the distance between the points. A minimum distance should be limited by Locus (possibly not less than 400m)
Track errors occur when the track runs a little behind the intersection due to inaccurate GPS. Then it may be that the shaping point is set exactly there and is on the wrong path.
How can wrong shaping points be prevented:
Automatically placed - or even more optimal say: All Shape points that are positioned in a forbidden circular protected area near junctions should absolutely be rejected in a (re)calculate (all) actions. It would be better for Locus to check this before the automatic setting and then set the point a little earlier. Or one before and one after.
At 40 km and one point every 800 meters, there are 50 shaping points. That shouldn't be too much. But the user could choose the distance between the points. A minimum distance should be limited by Locus (possibly not less than 400m)
Track errors occur when the track runs a little behind the intersection due to inaccurate GPS. Then it may be that the shaping point is set exactly there and is on the wrong path.
How can wrong shaping points be prevented:
Automatically placed - or even more optimal say: All Shape points that are positioned in a forbidden circular protected area near junctions should absolutely be rejected in a (re)calculate (all) actions. It would be better for Locus to check this before the automatic setting and then set the point a little earlier. Or one before and one after.
https://help.locusmap.eu/topic/navigation-from-track#comment-91786
"Menion does not want to use online services (too costly) so only option is by OFFLINE (B)Router.
BUT BRouter does not generate the important non directional very usefull U-turns.
So I requested:
https://forum.locusmap.eu/index.php?topic=7202.msg61737#msg61737
(Re)calculation delay tests by Kurviger OFFLINE operations.
- In Kurviger general setting: Select OFFLINE BRouter operation !
- In the BRouter app select the Zossebart-Enduro.brf
YOU MUST SET the best fit according profile !
- BRouter Server mode: Set motorcar fast > ok.
-Kurviger app: Routing > Select Import route.
- Select the atttached (prepared) test gpx file.
"TET_trk_wpt_0.5km_shaping_tickmarks.gpx"
- Set Coverage: Track & Routecalculation: Waypoints. (Set max 200)
- Push: Ok > Calculation DONE and READY in about 2 seconds !
https://youtu.be/zXNpMyYMeIo
To Know:
White dot = Shaping Point. Yellow dot = Navigation command.
Shaping Points are not announced routing references and targets @ navigation.
Via Points are announced routing references and targets @ navigation.
The calculated route result has a trackglitch !
Find the instruction with a nearby falsely positioned Shaping Point. (Yellow dot white dot)
But BRouter does not generate the important non directional U-turn instructions.
Important instruction for automatic detection and removal of falsely positioned Shaping Points.
https://help.locusmap.eu/topic/navigation-from-track#comment-91786
"Menion does not want to use online services (too costly) so only option is by OFFLINE (B)Router.
BUT BRouter does not generate the important non directional very usefull U-turns.
So I requested:
https://forum.locusmap.eu/index.php?topic=7202.msg61737#msg61737
(Re)calculation delay tests by Kurviger OFFLINE operations.
- In Kurviger general setting: Select OFFLINE BRouter operation !
- In the BRouter app select the Zossebart-Enduro.brf
YOU MUST SET the best fit according profile !
- BRouter Server mode: Set motorcar fast > ok.
-Kurviger app: Routing > Select Import route.
- Select the atttached (prepared) test gpx file.
"TET_trk_wpt_0.5km_shaping_tickmarks.gpx"
- Set Coverage: Track & Routecalculation: Waypoints. (Set max 200)
- Push: Ok > Calculation DONE and READY in about 2 seconds !
https://youtu.be/zXNpMyYMeIo
To Know:
White dot = Shaping Point. Yellow dot = Navigation command.
Shaping Points are not announced routing references and targets @ navigation.
Via Points are announced routing references and targets @ navigation.
The calculated route result has a trackglitch !
Find the instruction with a nearby falsely positioned Shaping Point. (Yellow dot white dot)
But BRouter does not generate the important non directional U-turn instructions.
Important instruction for automatic detection and removal of falsely positioned Shaping Points.
did you try my rerouting profile (https://www.github.com/zossebart/brouter-misc/tree/master/reroute.brf) already? Not sure about ferries and don't know if the voicehint prios fit your needs, but it is designed to simply route over nearly every way.
did you try my rerouting profile (https://www.github.com/zossebart/brouter-misc/tree/master/reroute.brf) already? Not sure about ferries and don't know if the voicehint prios fit your needs, but it is designed to simply route over nearly every way.
Note for others: Willy aka 0709 likes to intentionally misquote. It took him few weeks, but he finally moved from Brouter to the Brouter client to address the shaping point/viapoint U-turn issue. I was going to write for him the ferry friendly profile, addressing straight hinting he founds excessive. But it has to be from someone else, as "promise is promise". If someone insists on driving right in England and gets into problems then there is something "seriously wrong".
Note for others: Willy aka 0709 likes to intentionally misquote. It took him few weeks, but he finally moved from Brouter to the Brouter client to address the shaping point/viapoint U-turn issue. I was going to write for him the ferry friendly profile, addressing straight hinting he founds excessive. But it has to be from someone else, as "promise is promise". If someone insists on driving right in England and gets into problems then there is something "seriously wrong".
Another question: do these things still have to do with the actual topic?
Another question: do these things still have to do with the actual topic?
That would be my biggest wish to Locus.
That would be my biggest wish to Locus.
Want to test ?
Use decent (short) track records.
Roundabout support not (yet) available.
RouteYou web, by free account.
https://www.routeyou.com/nl-be
Plan a route > Upload a route (= gpx trk rec) (recalculate on existing roads where possible) > Save.
Download > Locus map = a map matched trk inc Locus turn by turn commands in trkpt.
Check
1. Open in (pc) gpx EDITOR.
Eventually add original trk as template
Set a colour for navigate trk & record trk.
Set show a dot when a trkpt has a sym.
Check the trk map matching result.
Check instructions (edit) by trkpt list.
Turn attach mode is self-explanatory.
Check instructions near @ U-turns.
2. Locus import & test navigation.
Want to test ?
Use decent (short) track records.
Roundabout support not (yet) available.
RouteYou web, by free account.
https://www.routeyou.com/nl-be
Plan a route > Upload a route (= gpx trk rec) (recalculate on existing roads where possible) > Save.
Download > Locus map = a map matched trk inc Locus turn by turn commands in trkpt.
Check
1. Open in (pc) gpx EDITOR.
Eventually add original trk as template
Set a colour for navigate trk & record trk.
Set show a dot when a trkpt has a sym.
Check the trk map matching result.
Check instructions (edit) by trkpt list.
Turn attach mode is self-explanatory.
Check instructions near @ U-turns.
2. Locus import & test navigation.
The parameter "Settings - Navigation - Advanced settings - Command frequency = Small" does not help in this situation?
The parameter "Settings - Navigation - Advanced settings - Command frequency = Small" does not help in this situation?
Replies have been locked on this page!