"voice hint generation" after "Load Track as Route"

[EssBee59]

test_origin_trackonly.gpx.txt
test_origin_osmandStyle.gpx.txt
test_afteruploaded_track_osmandStyle.gpx.txt

Hello,

I am using the Brouter-web to create gpx-tracks to be used in Osmand and set for that the parameter "turnInstructionMode" of the profile to Osmand-style (=3).
By a first generation of a track the voice hints are generated as expected.
But, if I try later to change the track using the "Load Track as Route" function, the voice hints are sometimes in error (left and right are inverted).
remark:
By the "Load Track as Route" I only upload gpx-tracks (result of export with turnInstructionMode=0), not the gpx track+route as exported with turnInstructionMode=3. (upload of a gpx track+route loads the tour twice!)

I attach some gpx files I created with Brouter-web using the standard "Trekking" profile:
test_origin_trackonly.gpx ==> turnInstructionMode=0 (using standard "Trekking" profile)
test_origin_osmandStyle ==> turnInstructionMode=3 (only this change was made and applied in the "Trekking" profile)
test_afteruploaded_track_osmandStyle ==> exported after "load Track as Route" of the above "text_origin_trackonly" & turnInstructionMode=3
Here the third voice hint (1944 meter after start) is set to "right" instead "left".

The feature "Load Track as Route" is very good, my bikefriends and myself like and use it:
Am I doing something wrong?
Or is a modification/work arround possible?
Regards
EssBee

[EssBee59]

Remark:
Each time the generated turn instruction is wrong, 2 identical "trkpt" are generated for this point in the track after upload..

origin track:
getrkpt lon="8.731992" lat="50.034217"
trkpt lon="8.733453" lat="50.032993"
trkpt lon="8.736330" lat="50.034201"

Track after upload:
trkpt lon="8.731992" lat="50.034217"
trkpt lon="8.733453" lat="50.032993"
trkpt lon="8.733453" lat="50.032993" <== ???
trkpt lon="8.736330" lat="50.034201"

[EssBee59]

... and the problem not only occurs after "Load Track as Route": it seems, the brouter itself some times fails...
Example:
http://brouter.de/brouter-web/#map=13/50.0393/8.8003/osm-mapnik-german_style&lonlats=8.719727,50.043361;8.733453,50.032993;8.743148,50.037229&profile=trekking

(set turnInstructionMode= OsmandStyle for testing)

[EssBee59]

Yes, as Nrenner I think we have a minor bug in the Brouter!
The problem only occurs when an intermediate point of the route has special characteristics (==node?).
I never encountered the problem whis routes where points was set manully... but it seems, the "reverse routing" process creates a lot of such points,leading to this issue report.

[nrenner]

Thanks for reporting and investigating.

I also created an issue for BRouter: brouter#282 Voice hint for route point on junction node.

But I guess we still need to avoid via points on junction nodes in the client by moving the simplified points a bit.

[EssBee59]

I think also, "faking" the intermediate RTEPT´s by nearly 2 meters could be a workarround...
Not sure, so I hope the Brouter team can help!

Note:
Yesterday I discovered an other (or similar?) weakness with the voice hints in the Brouter, example:
http://brouter.de/brouter-web/#map=18/50.00251/8.55325/standard&lonlats=8.553114,50.001561;8.552996,50.002343;8.553844,50.002595

(Strange route, but I had such a situation in my route, as I had defined an intermediate point not exactly at the jonction)
The track generated is OK, but the voice hint is wrong as it ignores the TU in the north point, only after returning it says "left"..

Regards
EssBee

[nrenner]

My proposal for fixing this in the client would be to move the route points determined by simplification a bit along the original track (forward or backward?). I think Turf along could be used for that.

This might also give a better hint to the router on which way to take, as with a route point on a junction node it is not clear in cases where two ways with equal cost lead to it.

@printpagestopdf what do you think?

[EssBee59]

Hello Norbert,

Thank for your work on this subject!
First I tried to fix the bug in the brouter itself... but the problem is very complex and I did not found a solution till yet...
Secondly I tried to "fake" the intermediate WP´s generated in the brouter-web during reverse-routing:

My changes in the module RouteLoaderConverter.js:
for (var i = 0; i < simplifiedLatLngs.length; i++) {
console.log("RouteLoaderConverter push INITLatLngs[i]=" + simplifiedLatLngs[i] + " lat=" + simplifiedLatLngs[i].lat );
// CHANGE SB 23.01.20
// simplifiedLatLngs[i].lat = simplifiedLatLngs[i].lat + 0.000051 ;
// simplifiedLatLngs[i].lng = simplifiedLatLngs[i].lng + 0.000071 ;
// simplifiedLatLngs[i].lat = simplifiedLatLngs[i].lat + 0.000001 ;
// simplifiedLatLngs[i].lng = simplifiedLatLngs[i].lng + 0.000001 ;
// ==> UNEXPECTED results!! NOGO

This simple change leads to unexpected results (some errors desapper, new errors appear).
I also manually tried to select the WP BEFORE the junction during reverse-routing, but this delivers some times a "near" junction and errors further occur.

I think, the change you suggest could / should be a workarround.in most of the situations.
But problems could remain, as example by bike-tracks where a lot of junctions are are near from an other (10 -20 meters)
(the programmation seems complex, I am not able to try myself)

Any response from Arndt to the issue you opened (#282) ?

For me, it would be nice to have a solution, but it has not top priority..
(my bike-friends prefer first an implementation of #332, any news?)

I said "nice to have" for this issue: my use case is, the following:
I get a simple track (from a friend or download from the internet) and intend to navigate it with OSMAND.
In order to enjoi the turn instruction of the Brouter (much better as the geometric hints) I start a "load track as route" and export then the gpx after setting the turninstructionmode to OSMAND-Style..

Regards
EssBee

[EssBee59]

A further possible change:
From the initial trkpt´s select the middle WP between the junction trkpt (the ons selected curently) and the trkpt before (or after)
This could run, and possibly simpler to programm...
Will look at the code..
Regards

[EssBee59]

RouteLoaderConverter.js.txt

Hello,

I got the change running (replace the intermediate WP´s with the middle point between the WP and his previous WP in the original track)
My first tests are promissing, I do not see differences in the Voice-hints between after / before "load track as route"

I installed the change in my test instance on the brouter server, can any body start new tests?
http://brouter.de/essbee/#map=11/49.9576/8.5752/standard
regards

[EssBee59]

Hello,

I tested with different GPX files and discovered 2 situations with unexpected results:

Case 1- the GPX file contain a track AND a route (as example generated by the brouter with turninstructionmode=3)
The coordinates of the rtept´s are loaded and considered as trkpt! This have no sense and should be avoided!
In the new test version, only coordinates of trkpt´s are loaded

Case 2- the GPX file contains a lot of duplicates (attached, an example, a GPX file created with garmin base camp)
Here I suspect a bug in turf.cleanCoords:
The example GPX file contains 250 trkpt´s. After "turf.Coords" only 131 trackPoint´s remain (by duplicates, all points are deleted, I had expected a UNIQUE point remain?)
As result of this, the middle of a point with his previous point is NOT in ALL cases on the track!!! Bad for the official version, ugly for the first test version which modify the simplified WP (see above)!!!

In the new test version of "load track as route" I delete the duplicate before "turf.cleanCoords" and... 179 trackPoint´s remain after processing!!!
This solved the errors I detected!

Regards
Ess Bee

RouteLoaderConverter.js.txt

garmin_track.gpx.txt

[nrenner]

Any response from Arndt to the issue you opened (#282) ?

This is a bit a superfluous question.

(my bike-friends prefer first an implementation of #332, any news?)

As mentioned in #329 (comment) #68 might change the way Export works, so I wouldn't want to have #332 before #68 is done, which is the most requested feature by far. I started looking into that and try not to get distracted again.

I pinged printpagestopdf above, and would wait at least two weeks, to see if he is interested and has time/energy to look into this issue, as he is the author of this feature and probably has test cases to better judge any impact of changes than me.

[mjaschen]

I've created pull request #369 with the changes made by @EssBee59.

[EssBee59]

Norbert,
I am very sorry to have disturb you , I liked to contribute to the product, but I should learn the procedures...as coding is only a part of the work.
Now I got help to create a pull request for this issue (that can be closed?).
To come back to #332:
Doe s it make sense to create now a pull request for it?
(due to probable conflicts with an other request which will be developped first)
Reghards
Ess Bee

[printpagestopdf]

Ohh, I am very sorry, I overlooked this thread, because I am in the moment deeply involved in another Project and don't have free resources. Reading over the thread I am in doubt that I could be very helpful for the decision. Regards edit (nrenner): remove email reply citation

[nrenner]

@printpagestopdf thanks for the feedback

[nrenner]

To come back to #332:
Doe s it make sense to create now a pull request for it?

I probably won't merge it until #68 is done. It might still make sense though, as a pull request really helps with seeing what the changes are and commenting on those. And I guess your implementation might need some further work before it is ready to be integrated.

[nrenner]

replace the intermediate WP´s with the middle point between the WP and his previous WP in the original track

My concern with this was, that moving the via point to the middle of a longer straight way with only two nodes might be too much and lead the route to go back and take a shortcut that the track didn't take.

So for example, when the via point of this original route is moved back too far, the route takes the straight shortcut:

But that seems to be only a theoretical consideration, I haven't found an actual example for this. When exporting above original route and loading again as route, the via point for the next corner will still force the route along the track.

Case 1- the GPX file contain a track AND a route (as example generated by the brouter with turninstructionmode=3)
The coordinates of the rtept´s are loaded and considered as trkpt!

That's a separate bug then. When there already is a route in the file, we should use those route points, instead of guessing them from the track.

Here I suspect a bug in turf.cleanCoords:
After "turf.Coords" only 131 trackPoint´s remain (by duplicates, all points are deleted, I had expected a UNIQUE point remain?)

That probably was turf#1255 cleanCoords() omits valid coords.. It's fixed in brouter-web since 15 Jan, when I updated to the new Turf version.

[EssBee59]

Norbert,
Thank for the information, yes I started the change under 1.13.0 and had the problem with cleanCoords!
sorry!

About the "middle" point:
Instead using the "simplified trkpt´s" as route point I suggest to use the middle point between the simplified trkpt and his previous trkpt in the original track (not the previous simplified trkpt!)
My understanding of a "track" is, the track must contain enough points in order a biker can "follow" the route using it during navigation..

• without a corresponding map
• and without route calculation (routing).
  To reach that, the "route" (way ) between 2 following trkpt´s must be nearly a line!
  (by recorded track´s it is not really a line at a turn, but the deviation should not exeed some meters)

So, I think, the new calculated point for the routing remains ON the track / way ...

I my assumption is not true, the pull request should be cancelled..
Regards
Ess Bee

PS:
If the pull request is accepted, I suggest the following steps:

• close this issue
• open a new issue about the rte points (do not load them as track point)
• I also suggest to write a short "user guide" or help document for "load track as route": most a the user have problems to understand this powerful feature, and to use it in an optimal way (as example, the choice of the profile after the load is very important and should be explained for new users)

[nrenner]

I my assumption is not true, the pull request should be cancelled..

No worries, as I wrote I think it's fine and is probably just theoretical. And yes, it wouldn't apply to normal GPS recordings.

But we can't know if a track isn't already simplified. Simplification with a low tolerance only removes redundant intermediate points on straight lines and leaves the overall geometry intact, so still perfectly navigatable, but longer distances between points.

Also, exporting a route and later reloading the track as route is a valid use case (bookmarks are better of course), then you have only points for OSM nodes, which might mean only two points for a straight way. That is what I meant, but again, probably not a real issue.

If the pull request is accepted, I suggest the following steps:

I agree with those.

[EssBee59]

As a solution is in view, I close now this issue!
As discussed above, I will open a new issue to only upload real track-points for the function "load track as route"

Ess bee