Voice hints from existing track possible?

[demiantres]

Hello,

Is it possible to feed the BRouter RoutingEngine with an existing track (for instance read from a GPX file) and then generate voice hints from this?

[polyscias]

That is basically the same functionality as rerouting the existing track again, for example to convert a track of ride to one that is following the roads.

I found:

Snapping GPS tracks to Roads using QGIS and OSRM

That script is for OSRM but something like it can work for BRouter. The script is going over all input track points and for each point is asks OSRM to give the "roads" within a given radius of that input track point.

Brouter has also that functionality, for the begin and the end of a track the route needs to snap to the road, but there is no separate API available, so you can (yet) not make a script to do the same.

The other question is how good this algorithm is, I did not play with it but I see quite some possible problems.

Edit: Some further digging shows that this is called Map matching

For now I would go to https://brouter.de/brouter-web, load the existing track and the make a new route that exactly follows the existing track. That sounds as a lot of work but if all is good the existing track is good for cycling and brouter also generates a route good for cycling so only adding a few via points should suffice. Would be good to hear from you if this works.

[poutnikl]

It usually takes just few route dragging ( either on Brouter-web either in e.g. LocusMap route planner) to make BRouter to stick to original route. The number depends on how well the provided track fits preferences of the used profile.

[EssBee59]

Hello,

I tested an other solution: "load track as route" in the brouter-web... (to get the best result, choose a profile corresponding to the type of track you have, MTB, trekking, fastbike etc...) Then you can set the "voice option" you need (osmand, orux, locus) and re-export the track with the turn/voice instructions

but I discovered a bug ... https://github.com/nrenner/brouter-web/issues/356

I have not the current status, but you can try to use my test-instance containing a work-arround to this problem: http://brouter.de/essbee/#map=11/49.4838/8.1422/osm-mapnik-german_style

regards Ess Bee

[demiantres]

I took a look at the BRouter web code. It simplifies the loaded GPX road to a set of waypoints and sends these to the server: https://github.com/nrenner/brouter-web/blob/master/js/plugin/RouteLoaderConverter.js

[EssBee59]

Yes, "load track as route" "simplifies" the track (reduces the number of points using a special allgorithm). The simplified points are then used ase route points... (limited number!) With a very long track, the distance between 2 route points becomes longer .... That for, to recalculate the track, choose a profile corresponding to your original track- else, small differences could appear between original and recalculated track. As I prefer the "Brouter voice instructions" to other systems, I convert each tracks I get from internet using this procedure!

About the bug: I hope the work arround will be distributed on the brouter-web instance with the next release, a pull request was allready created. Regards

[afischerdev]

@EssBee59 I had a look at your reported bug nrenner/brouter-web#356 and your work around with this sample. In my opinion a generell fix is needed.

Now I made a work around inside the brouter-core to prevent double nodes. So no manipulation of the input way points is needed. And on the sample it returns same result like no sub point is used.

I don't have a server present, but I made local tests for speed. Not feelable with this few points but on ~308 km (~5600 pts, 7 sub points) I had 50-150ms (total 2080ms) difference.

If you like you can test it with the my branch wpt_problem.

[EssBee59]

Hello, I generated a new jar using the sources from wpt_problem and tested with a longer track: (I create a track with brouter, export it, then load this track as route and reexport using "OSMANS style") But the test was not successfull, I had many errors in the turn instructions... Regards Ess Bee

[afischerdev]

Hello, thanks for the test. My change was focused on the problem with double points in export bug. I can't test the reimport, I don't own a server.

[EssBee59]

Hello,

just a remark: The "problem" with hint-voice generation occurs only in very limited situations (the origin track has been generated by a routing tool, as ex. with Brouter, and the user tries to generate voice instructions by using "load track as route"). So it has not for me high priority, and possibly Norbert will deploy the work-arround in nex releases...

To test new jar´s or changes in Brouter-web I installed a local brouter + brouter-web on my windows PC. The installation is easy, I use an apache seerver. Regards Ess Bee

[afischerdev]

Hi, thanks for the clearing. The problem I see is the equality of a route point and a way point in your sample. Yes, this only occurs in special situations but it ends in wrong routing hints and should be solved - for all, web and standalone server. I'm not satisfied with my work around, so still working on it.

I use good old command line for testing.

[EssBee59]

Hello,

Yes, you are right! Don´t hesitate to recontact me if I can help (as example installing apache/BRouter-web locally or installing a tool which help to verify the turn instruchtions quickly) Ess Bee

[polyscias]

But the test was not successfull, I had many errors in the turn instructions...

Never used turn instructions but wanted to see how it works so did fire up brouter and then issued

curl -o track.gpx "http://127.0.0.1:17777/brouter?lonlats=5.15,52.086%7C5.207,52.062&profile=trekking&alternativeidx=0&format=gpx&timode=3"

Then loaded this track.gpx into QMapShack and reviewed the data.

What surprises me is:

1. Most of the times side roads and crossings where you go straight are "ignored", no voice instruction (so just go straight), but sometimes there is a voice instruction
2. Most of the times when you have to make a turn there is a turn instruction but not always

Ad 1)

This is a cycle way along the road with two side roads crossings, we go straight so why then a turn instruction?

Ad 2)

Why is there no turn instruction on the first right turn in this picture? (and why is there a turn instruction for the next footway)

But maybe this is more something for a separate issue.

[polyscias]

Probably should have know but the problem for 2) is the OSM data:

There is a 0.6 meter piece of road before the crossing that has the same direction as the continuing road so no turn instruction makes more or less sense. Let me correct the OSM data.

For 1) no explanation yet.

[EssBee59]

Hello polyscias,

the generated instructions are mainly controlled by the profile! In your case 1(), if you retest with another profile, you will not get the two "straigt"..

Here as example using my profile "fastbike-verylowtraffic": http://brouter.de/essbee/#map=12/52.0849/5.1507/osm-mapnik-german_style&lonlats=5.15,52.086;5.207,52.062

(set manually the turninstructionmode to osmand-style for testing!)

[afischerdev]

@polyscias Good sample, it shows what we are fighting with.

The equal way point and routing point problem generates a distance of 1m and has also a direction.

Seems that we need something like a 'junction snapper'. Not all points can be changed manually.

[polyscias]

the generated instructions are mainly controlled by the profile! In your case 1(), if you retest with another profile, you will not get the two "straight"..

Here as example using my profile "fastbike-verylowtraffic": http://brouter.de/essbee/#map=12/52.0849/5.1507/osm-mapnik-german_style&lonlats=5.15,52.086;5.207,52.062

Did download the track and it takes another route but the good thing is that the turn instructions are close to prefect, I see only one "useless" instruction (case 1). I can also reproduce that on the command line:

curl -o track_essbee.gpx "http://127.0.0.1:17777/brouter?lonlats=5.15,52.086%7C5.207,52.062&profile=fastbike-verylowtraffic&alternativeidx=0&format=gpx&timode=3"

Forcing the route to the original route I see it also being perfect apart from the 0.6 meter problem I detailed earlier (and that is meanwhile solved in OSM)

Had a look at the differences between your profile and the default trekking profile:

turnInstructionCatchingRange 40 (trekking) versus 8 (EssBee) - 40 meter seems more for cars, 8 seems better for cycling turnInstructionRoundabouts false (trekking) versus true (EssBee) - not relevant in this track priorityclassifier assignment is different, for trekking unclassified is 20 and residential 6, for EssBee it is both 8

Your setting are for sure a better start then the ones in the trekking profile.

The equal way point and routing point problem generates a distance of 1m and has also a direction. Seems that we need something like a 'junction snapper'. Not all points can be changed manually.

Yes, I was thinking along these lines also.

Just learned about the turnInstructionCatchingRange and I think it would make sense to me to drop all intermittent nodes within for example a radius of halve that turnInstructionCatchingRange. Could be done partly in the map making process (a la Douglas-Peucker/doDPFilter) but as the .rd5 files are used for foot/bicycle/car/boot/etc I think part of it must be also done in the brouter App. Probably needs a bit more of tinkering.

[EssBee59]

Hello Polyschias,

I could finally clarify the situation for 1)...

Your "Regulierengring" is mapped in OSM as "unclassified" highway.. (why not as residential?) As in the treking profile unclassified has a priority of 20 and cycleway has 6 you get the hint !!! In my profile, unclassified has the same priority as cycleway. (remember the brouter logic from the profile_developers_guide: ...... To avoid a navigation instruction flood, it was decided that the instructions are provided only if:

1/ You are supposed to turn at a crossroad/junction and some other ways having the same or higher Priorityclassifier value. OR 2/ You are supposed to go straight ahead and some other ways having the higher Priorityclassifier value. ......

[poutnikl]

Hehe, I recognize the guide quote as I have included it, copying it from my GitHub glossary. :-)

[EssBee59]

Hello poutnikl,

I think, your documentation is perfect, you did a great job! The only point I see: is it possible to grant new brouter users a better access to all the documentation? (I remember my start with brouter some years ago, where I had a lot of questions about OSM, voice hint, profiles..) The example above shows the complexity of an analysis (combination BRouter, OSM and profiles..). To help users (and avoid new issues/questions), could it help to extend some documents and offer them to the users who intend to open isues?

Regards Ess Bee

[poutnikl]

What exactly do you have in mind ? Editor access? Or more advertized URL?

The wiki is mostly for context of usage of my profiles, even if there is an overlap with general Brouter topics, mainly in the Glassary page.

One option could be to exclude the Brouter general stuff and making it a content of a new project, dedicated to documentation.

Arndt prefers plain text docs as they are now within BRouter project/application, so occational content porting was done.

But I admit I am not a good doc creator, what I did is like doing my best.

[polyscias]

I could finally clarify the situation for 1)...

Your "Regulierenring" is mapped in OSM as "unclassified" highway.. (why not as residential?) As in the treking profile unclassified has a priority of 20 and cycleway has 6 you get the hint !!!

The Regulierenring is mapped as unclassified as this is ... not a residential area but offices/companies.

Yes, that part is clear now, but thinking a bit further: Why do need to have "straight" instructions at all if our cycle route crosses a "higher priority" road. For car traffic I think it makes sense because for car traffic, it is normal to take "higher priority" roads as for these roads the max speed is higher and there are less interruptions like traffic lights and crossings, so as the route is not following that a "straight" instruction might be fine.

For cycling I on the other hand better I typically like "low priority" roads, less traffic.

So why not make the priorityclassifier for cycling a fixed value? Had a look on how this priorityclassifier is used and I see it is also in the Java sources but not really used apart from in VoiceHint.java. In the profile it is also used to set a isgoodforcars and that is used in VoiceHintProcessor.java to do something in the context of roundabout's.

Still like to play a bit with the turnInstructionCatchingRange

[poutnikl]

The Regulierenring is mapped as unclassified as this is ... not a residential area but offices/companies.

It should be then IMHO marked rather as highway=service, or generic highway=road, if status is unclear. Highway=unclassified has the special meaning within the major road network as the road class just below tertiaries ( not used in all countries ).

Yes, that part is clear now, but thinking a bit further: Why do need to have "straight" instructions at all if our cycle route crosses a "higher priority" road.

I would agree here, I think there is needed modification/exception to omit Straight-ahead, if the leaving way has the same priority as the approaching way.

Typical scenario is a major road with connected service roads, that are regularly crossed by a whatever minor way parallel to the major road ( typically independent cycleway or track)

[polyscias]

I think the classification as highway=unclassified at least in Dutch context is correct. Is it not highway=road as the classification is clear and it is not highway=service because it has two lanes.

[poutnikl]

Too low catching range may cause taking a wrong turn, if the network is dense, position inaccurate or if there is a voice hint delay behind the position. About the delay - I got quite consistently ( withing LocusMap) voice hints I am farther from a crossing than I am physically at the moment by 15-30 m. (I mean at the moment when the distance number is said)

It may happen you should take this turn, but the hint makes impression you should take the next turn just behind it. The area leaving direction may help to avoid it, if options differ in directions they take.

[EssBee59]

As explained, for me the voice instruction generated by the brouter are perfect (yes, I have an own profile, but it has not big differences with the standard profiles) Some times, I prefer a bit more hints as absolutly necessary (catching range 8 meters, classifiermask no isbadoneway) ... The resson: I make big use of the option "display on / off" in the Navigation-app on the bike to reduce the batterie usage: Each voice hint turn the display on automatically... regards

[poutnikl]

I use voice hints almost exclusively, especially if on multiday trips. I find watching the screen disturbing and on bright days visually challenging. So I check the map very occasionally if situation gets suspicious.

[0709wiwiwi]

turnInstructionCatchingRange.

The intention may be noble, but the result brings mostly more problems than benefits. As the default value of 40, which is far too large, leads to mostly strange bad results. A default value of 12 is probably more optimal, or even the removal of the rule.

The problem has already been demonstrated with confusingly bad results. https://groups.google.com/g/osm-android-bikerouting/c/1zl5NSLR0y8

[0709wiwiwi]

Ad 1)

This is a cycle way along the road with two side roads crossings, we go straight so why then a turn instruction?

Results by GraphHopper: https://t.ly/SDbv

Ad 2)

Why is there no turn instruction on the first right turn in this picture? (and why is there a turn instruction for the next footway)

By GraphHopper map. No turn instruction on the first right turn ? ( Zoom in: there is no turn = A normal road continuation.)

routeyou-trk-navtrkpt-locusmap.gpx.txt

Best view using gpx editor. https://sourceforge.net/projects/gpxeditor/ Options > Settings > OpenStreetmap > "Put a dot on the map if a trackpoint in a track has a symbol"

[afischerdev]

Thanks for adding an online sample. It is always helpful to have the exact sample you use - like this.

With the announced version of the avoid peaks I got this gpx export:

testtrack0.gpx.txt

But I had to add a cutter for straight voice hint - not sure if this is a good way, some of them were dropped before, but not all - and there is a correction for distance to next voice hint.

[0709wiwiwi]

Ok Roger.

So if I understand you have shown now that you can indeed use the track points. But not yet in a usable format, to say with the correct 'sym' text for Locus map. As shown in the example gpx track file by the RouteYou web planner. (Without falsely attached language tag (non gpx standard) that I removed)

Locus reads the discrete instructions into track points, condition, use the correct 'sym' text. Locus promotes these track points to Turn and Via or Shaping points. The 'sym' text selectivity was crucial for proper robust functioning.

• Anyway, I suppose you might be familiar with the correct Locus standard 'sym' text list ?

Further I notice that the gpx tags order is not respected. Many programs do not object to this. But Garmin programs don't accept it anyway. Garmin is very strict before importing a gpx file. Even if Garmin does not use the tags so one must 100% follow the gpx standard exactly.

Validate gpx files by Windows Notepad ++ using the XML Tools plug in. Import in the "gpx editor" program and by export "save as", the tags in the correct order. Garmin accepts the import of the next gpx track file.

testtrack0_save_as_by_gpx_editor.gpx.txt

_I also expect a start and a finish trackpoint which are defined and named. So both as a 'sym' pass_place 'type' Via with an appropriate 'name'. Via Point(s) as routing and announced navigation targets in navigation. In the BRouter by using the 'name' "From" and 'name' "To". So you can easily 'distill' a (rte) route with (rtept) routepoints from this track.

The Locus [EN] 'sym' for turns follows next recommandation. https://www.topografix.com/gpx_for_developers.asp "Use the GPX tags the way they were intended"

The Locus [EN] 'sym' for turns is generated by:

• RouteYou web into the navigation trackpoints.
• Plotaroute web in associated navigation waypoints.

[afischerdev]

@0709wiwiwi for the current source of avoid-peaks I added a new export option (7) for Locus new voicehints. There is already a Locus version (2), but this exports waypoints and has old references to voicehints. Not sure if old one can be dropped.

I'm not very used in Locus, but I could import this track and see the linked routing tags in a list. Could you please give this a test?

testtrack0.locus.new.gpx.txt

[0709wiwiwi]

@afischerdev

Nice progression what you present. This works perfectly.

What to optimise?
For turnpoints leave the name tag free. I know it is a habit, but it is unnecessary double info. Locus map automatically translates the EN sym turns into "local language" TTS instructions.

The name tag is reserved for Via Points and is very useful especially in combination with U-turns.

In Via Points you can, if you like, put an informative name (local language) in the name tag.
The name (untranslated) of the via point is reported by the TTS via point announcement in navigation. Shaping Points are operationally identical except that they are not announced at all in the navigation.

Very nicely to be used in combination of announced Via Point PLUS announced U-turn.
A Via trackpoint and the so triggered U-turn do always share the same trackpoint location. You can so indicate by the Via point name that the U-turn is indeed a planned one.

Example.
App NL language. The EN sym instruction is always automatically translated. A motorbike ride to a café in a side street, after which you return to the main route. Give the Via Point a clear name. "koffie en koeken".
The NL TTS announcement: "Na 60m koffie en koeken - keerom ".

See and listen to a demo result in the next video. https://youtube.com/shorts/8VL5WilHzGU