Navigation for imported track

Hrabosh shared this idea 8 years ago
Gathering feedback

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).

Replies (31)


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

  1. You should not work on Sunday.
  2. You got the initial idea. Shape should be the same, but with more useful commands.

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 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 SHUT THE FUCK UP! I do know where to go, there are steep rocks!

Finally, here: 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

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. 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.


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 ( 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.


I got your point. But in case your suggestion never gets implemented I was just politely trying to offer possible workaround.


Ok, thanks.


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:

  1. Even on a very short part of track, is highly possible that computed track will be on different road. Just a street next to original street, but it results in a problem.
  2. Huge number of commands leads to huge number of requests on routing service = huge time needed to compute whole track from a segments
  3. there is no service that may do it for a hike / bike now, except GraphHopper. MapQuest routing is working nice, but because of overpriced policy it will be dead to our pocket. It's partially now already, but it's still not so bad as it should be with this feature implemented :).

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.


2. Could you specify what you treat as "huge number"? I suggest to cut the path to 5km splits, so 200km track (I don't expect that many would exceed) would result in 40 splits. Is that "huge number"?

1. This could be partial problem in the cities (with high street density), but not in countryside, where, I suppose, Locus is mainly used. You can suppose, that the author of the track was not fool and rode the track wisely, so it's quite likely that it would be the same. If generated navigation doesn't match with original track, you can either:

1.1. fall back to current solution for that split

1.2. add one via point in the middle and re-generate that split.

3. you have implemented micropayments (LoCoins). Use it. You can give all users some navigation for free (say 20-50 via-points/month, don't know the pricing policy). OR you can use micropayments just for this feature. We're paying for maps, so we can pay for navigation.



more then "one" is huge number for me now :). Anyway I'm not saying it's not possible to do it. I just think that it's enormous amount of work that is impossible to do without perfectly and quickly working offline navigation support.

I'll can leave topic open for now, but without some other changes in Locus (mainly fast offline navi), do not expect it will be realized. I really don't want to use any online service for such task now. Thanks for understanding.


Hi Menion....As I prefer to do some work, more easy with pc, so not urgent (for me).

About routable maps....I do not use fear, I stay here with Locus.

But it seems they use routable maps ? Did you ever have a look at their maps ?

And those produced in the garmin provided by

OSM based free maps and they seems to work (perfect) in Mapsource ?

Remark I did not try over longer distances.

Just curious more, not pushing.



I've looked on both. But OsmAnd is GPL, so using of their system force Locus to release it's source code as GPL as well. Garmin maps .. there is no routable library available for Android devices as I know.


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 ?

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.


Info: Some more tests. More simple set up ! (Only by pc programs !)

Add intelligent Navigation instructions on a (recorded) track. (more tests/testers pse).

Last year tests with a similar set up did not work. Somewhere I had a mistake ? Because not ok at that time, a one year pause ;-) And now a new retry !

Used method:

Programs: JavaWaRtwTool and Mapsource with routable map.

1. Recorded gpx track.

Open in RTWtool. Export to gpx. Track: export as direct route *Filter (15 pt). Convert and Save file.

2. Direct route gpx file.

Import in Mapsource. On the left pane select the route. Right click and select recalculate route. Save new route as .gdb file ! Important !

3. Route .gdb file.

Import in RTWtool. Export to .tcx and Export as courses set add coursepoints. Convert and Save file.

4. Course file tcx with Coursepoints.

Ready to be used by compatible Android apps as Locus or Track Navigator. And Garmin Edge 705 ? Cannot test, sold that unit.

More Demo:

RTW tool Recycle (or import) previous tcx file to the import screen of RtwTool. (By right click on the import screen convert coursepoints to waypoints.)

Eport to gpx. Track: export as track. Waypoints: export as Waypoints. Convert and Save file.

5. Track file with (associated) Waypoints (= compatible navigation by "Track Navigator" )

Open in freeware program "gpx editor" . Select Waypoints. Select Point list. See the Navigation instructions in the list.

* Filter: total points !

Best: Limit total routepoints to a minimum = minimising track glitches in the final result

In attachment: All example files 1 to 5.


Thx for that! A little more convenient would be nice :-)


Indeed, so one year after.

Mobile solution and operation by planner Locus_B-router.

Display track (= template). Plan "New" design -> save -> use.


Don't know how they do it, but here they do some nice routeplanning:


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 ? )





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.

But here I have to place a lot of shaping points so that the routing is exactly on the track. This work could make Locus automatic. As I described above.


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:

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.


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.


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 !!!!!!!!!


Note that I did something similar, but with OSM route-relations and not by Locus but by a server-script (

The script is able get osm route-relations (for example bike or hiking routes) and re-routes them using brouter (also on the server). The result is downloaded to locus and one can navigate it (with useful navigation instructions). Of course, this only works well if the route-relation is mapped in a continuous way (without gaps) in openstreetmap (which often is not the case :-( ).

The script first generates via-points 10 meters into and in the middle of every osm-way and then uses brouter with a simplified routing profile to recalculate the track with nav instructions (using the generated via-points). Even though the original track lies exactly on osm-ways (as opposed to a downloaded track from somewhere of the internet), there are sometimes cases where the routing skips part of the route. I plan to either enhance the algorithm to re-check the track after the first run and do additional rerouting of skipped parts or implement something similar to your idea (add via-points at regular intervals). However, I fear the interval might have to be very short to get good results and thus the routing gets inefficient (many very small routing requests).

And if the original track does not lie exactly on osm-ways, you have to rely on the mapmatching-algorithm (of brouter, in my case). What about two ways very close and nearly parallel to each other? The resulting track might end up on the wrong one (for example a busy primary road instead of the cycleway parallel to it).

You don't know which kind of track the user wants to reoute, so using a transport-specific routingprofile for the rerouting is not possible (which would prefer the cycleway in the example above).

For reference: here's the minimal brouter profile I use for the rerouting:

All I want to say is: based in my experience, it's not an easy task and requires quite some finetuning etc...but of course I would be very happy to have something like this in Locus!


The idea of Zossebart is good. But unfortunately only for specialists. That's nothing for the average user. It would have to go to Locus everything automatically.

Menion could take over the concept for the beginning. You can choose how you want to navigate. 1. based on change of direction 2. based on Brouter calculation.

It does not have to reproduce 100% of the old track. 80% is already good. I see in the route planner the old track and the newly calculated route. Where it does not match then I can help by hand.

In places where the calculation does not work, because OSM no way or authority. Since then you can change the place from (mountain bike or hiking) to manual routing style.

The solution is better than having to create all by hand with many routing points.


Nothing usable found so far, the results have too many errors.

This due to small track glitches and false turn directions.

Repair is time consuming, produce a new design is faster.

Even as a premium feature is offered here, find comment ;-)

Reply Tuesday, 29 Sep 2020 08:46:44

So I had already given up completely on the idea.

But after an excursion to the Kurviger app maybe a possibility is still open ?

Trackglitches are created by Shaping points at road intersections that are positioned on a neighboring road.

Prevention measure.

A. Avoid reference points around road intersections, so don't refer to track points. You will find these concentrated around the critical positions.

B. Allow some out and return trackglitches to occur but detect these and remove the cause, this automatically than removes the trackglitches.


a. Using distance set SHAPING tickmark waypoints so there is much less chance of them falling close to critical positions.

b. In case of an out and return trackglitch a non directional U-turn (-98) is generated by the GH Router.

Menion before said not to use any online service, so sit is a pity but (offline) Brouter does not generate the non directional usefull necessary U-turns !

As a non-directional U-turn is THE indication that there is an error due to a poorly positioned tickmark Shaping Point.

Remove the associated false positioned tickmark Shaping Point, this triggers a recalculation after which the trackglitch is gone.

An (auto)cleaner removes the Shaping Point from "Shaping U-turn" combinations, but NOT the "Via U-turn" combinations.

If a non-directional U-turn command is DESIRED so protect it by promoting the Shaping to a Via Point.

Find (NOTHING automated) manual tests here:


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.


This is not about the navigation with Brouter. This is good.It is about the navigation of an imported track (without Brouter). Normal browsing does not use a Brouter. This is only used if you create a track with the route planner. When navigating an imported track, Locus navigates by changing the direction. If the track has a curve, an instruction comes. Even if there is no other road.


Even though Locus improved the navigation function the navigation with imported tracks is still somehow annoying because of the amount of unnecessary information.

E.g. when following a long way in valley (let us say 5km) without real turns / crossings Locus displays a "turn" approximately every 200m when the way makes a bend and there is no other way to drive / go.

Ideally Locus should "compare" the GPX track with the in reality available ways of the map along the track and should provide navigation hints only when an information is necessary because of a turn or a fork.


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.


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.


Hm, There is really no sense in such dense SP placing. Rather just setting start, end, and then dragging the route to create an extra SP only so many times to get the original route. It can be done both in LM Route planner or BRouter-web.


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.


But LocusMap has no direct or easy way to know what point is at/near junction/crossing to eliminate such a shaping point.

It could implement some geometry empirical checking, excluding point with coordinate based turning above some threshold. It could be done iteratively with lowering threshold until there is reached some avarage distance of points that would then be used as shaping points.

Illustrative example:

1. eliminate points with turning >90 degrees. result: AVG distance 150 m. Too close yet.

2. eliminate points with turning >45 degrees. result: AVG distance 350 m. Too close yet.

3. eliminate points with turning >22 degrees. result: AVG distance 800 m. Good enough. Make them Shaping points.

Perhaps the end criteria can be both angle threshold or distance threshold, whichever is reached sooner.

Personally, I would use much greater distance. My trips usually use less then 5 shaping points and very rarely more than 10, because I use a profile that more or less follows my preferences.

Consider also that dense shaping points may overpaint a lot of map features.


If I want to plan a new route, I don't need a lot of points. Beginning and end and the rest makes Locus, Das Profil and BRouter.

But the topic is to follow a track from the internet as closely as possible. But only to get turn instructions where there are intersections. and not with every sharp turn on the track.


But that was what my post was about. Few points comment was rather a side note. But even an imported recorded track can be reduced to very few shaping points.


Please have a look at latest Brouter-web (0.13.0). It has the new functionality "load track as route" (Load -> Track as Route). With the help of the tuning-slider, one can change the fuzziness (frequency of auto-generated shaping points) and then the track is rerouted with the help of this shaping points!

It is recommended to use a simple profile like "shortest" for this.

It would be extraordinary great to have something like this in Locus! Maybe you could have a look at the brouter-web implementation?


Maybe @ Libor can shed some light in this matter


"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:

(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.


- Set Coverage: Track & Routecalculation: Waypoints. (Set max 200)

- Push: Ok > Calculation DONE and READY in about 2 seconds !

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.


Find and locate trackglitches by U-turns.

Kurviger app. A demo by manual edit operations !

Part 1. By Online Kurviger router (GH engine)

- Find the U-turns in the instructions list.

- Tap U-turn instruction and use max + map zoom.

- Locate the nearby harmfull located Shaping Point and remove.

-Track glitch and false instruction problem is solved.

- Finally double check for any route vs track reference deviation.

- Check and find trouble zones by OSM source verification.

- Kurviger road motorbike profiles do not route over paths_tracks !

- By U turn detection the process could be automated.

Part 2. By Offline BRouter.

- BRouter does not generate the important usefull U-turns.

- Removing the harmfull Shaping Points has the same curing effect.

- Notice the unnecessary Straight turn command generation.

- By BRouter expect more strange non optimal turn commands.

- The Zossebart-Enduro BRouter profile allows passing of "paths_tracks".

- Missing U-turn detection the process hardly can be automated ?

Using higher density (< 200) tickmark Shaping Points hardly do retard the calculations.


See the Brouter logic for Straight hints. It can be modified by tuning PriorityClassifier in profiles, but it may affect the turn hint logic.


@ Libor.

As you see in the video's the B-router offline track to route design performance is perfectly fast.

I patiently wait for any expert who offers a more optimal and even a ferry boat friendly profile.

As there are multiple issue's. No U-turn generation, some strange navigation hints, ferry boat unfriendly.

And as I am not a BRouter profile expert I can't tackle this all, as I am mainly a profile consumer.

Anyway when I recommand a nice best fit profile, I do mention the author. That's fair not ?


What are your exact ferry-related requirements to have them balanced with roads ?

Brouter recalculates everything, like priorities and penalties, as a distance. Either as one time distance, either as distance per physical distance.

What one time distance penalty you wish for ferries ? To count with uncertainty of ferry departure time and frequency, also involving dock manipulation time. It is different if you know you will be there just in time, or if you have no idea how long you will be waiting.

Brouter cannot calculate with realtime arrivals and ferry schedules.

How many kilometres of an ideal road should be equivalent to 1 km of a ferry ? This should be related to ferry versus bike speed, corrected by preferences. What is the ratio ?

Also, Is 15 min of riding equivalent to 15 min of ferry moving ?

Knowing that, you can change 2 single numbers in your favourite profile and you would have the ferry friendly profile.


About the rest ( shaping/via point U-turns, hint direction and extra hints)

you already know well about the reasons from Brouter maillist,

but you keep writing like

if you have never read it.

In one sentence:

"It is not a bug, it is a feature".

( If you start with nonsensical stories again, this would be last time I ever respond.)


U-turns at via/shaping points are not manageable by Brouter profiles nor by Brouter.

Brouter routing engine does not work with shaping/via points and does not provide hints for them. They are provided to BRouter engine by Brouter clients as starts/ends of a serie of independent subsequent routes. Routes are then joined into the single one at the client side .

Any creation of hints at these points must be done by the BRouter client ( BRouter web, Kurviger, LocusMap, OsmAnd ). Any change to that ( to be done by Brouter) is on the Brouter developer and I am not sure it would be done.

AFAIK, there is also an issue, if the same navigation point is passed multiple times by different ways, due the way how navigation points are stored in the route. It may be safer to create independent routes here.


Logic behind counterintuitive directions of Brouter hints has been already explained to you, so results are not unexpected for you any more.

Always keep in mind arriving and departing direction in wider physical context, instead of the particular immediate shape of the crossing.

You are arriving to crossing about from north,

You are departing from crossing about to south,

you get straight hint ( or nothing, it depends).

The fact you turned in last meters to west, and then back to south, does not matter.

You keep the southern direction.

You may not like it, but you have to count with it, if you want to use Brouter. It is like left driving in GB. You need not to go there, you need not to like it but if you go there...


Logic behind when the turning or straight hints

are or are not provided was explained to you as well, aside of being described in my GitHub Glossary.

Turning OFF the straight hints that seem unnecessary (like going on "smaller" way, crossing "bigger" way) is possible, but you would not get such a hint when it would be more than handy, if continuing straight may not come to your mind. ( E.g if the tertiary you go along turns right but you should go straight along a grassy track of grade5.)

You have to specify, which hints at which scenarios are to be or not to be provided.(not direction, but comparison of involved OSM ways ).

I may then try to create such a hint logic in the profile, within constrains of hard coded Brouter logic.

If all ways were set equal, then you would always get hint, if Brouter is about to tell you to turn, but you would never get straight hint.

But this wouldnot address your straight Vs left confusion.


U-turns at via / shaping points are not manageable.

The Kurviger app manages this perfectly.

So I did ask in the Locus forum. Roger ?

"this would be last time I ever respond.

Pse, you make my day. Promise is promise.


did you try my rerouting profile ( 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.


Hi Zossebart.


You can test this yourself with the multiple available Elbe transfer services

Zossebart reroute profile often refuses ferries. Sometimes works with Zossebart-mtb or standard shortest profile

ALL free ferries in Flanders, very popular in the summer season, also seem completely unattractive to BRouter.

Navigation instructions.

Also with the reroute profile, navigation commands are sometimes weird and even just absurdly wrong.

If you have to turn 90 ° to the Left then get the command Straight, then something is seriously wrong.

This may have nothing to do with profiles, the problem may be much deeper.

And you just do not see these problems with GH routing


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?


@ freischneider.


Announcement OFFLINE GraphHopper will no longer be supported.

My favorite OFFLINE GraphHopper so should be replaced by BRouter.

And this does have sure an influence on the original tread started here.

With Offline BRouter I so noticed already some disturbing elements.

- Ferries are barely accessible for most BRouter profiles. A No Ferries button so is not really useful.

- LEFT turn where * ALL other tested routers generate a correct LEFT except BRouter which generates Straight

- Brouter also generates quite a few unnecessary straight forward instructions in places where other routers do not generate anything,51.051889;3.83637,51.048733

& turnInstructionCatchingRange 0

* Routers tested: GraphHopper, Plotaroute, Ride with Gps, Routenet, Bikemap, Garmin Basecamp Mapsource, Via Michelin, Google maps, Here

So the least I can do is report this to the BRouter author via the BRouter forum.

I also notice that the 2nd or 3rd WEB routing alternative sometimes runs over Ferries.,51.109026;4.173496,51.109939

That is why I ask for real valuable help without nonsense that I cannot do anything with as I am not an expert on these BRouter profiles. I just do consume nice profiles.

Due to unnecessary reaction, this problem message report unfortunately threatens to disappear in the background.

Locus forum Navigation for imported track.

Since I think I now see a possibility recently, I report this here in the Locus forum.

I thought possibly valuable after all and it is exactly about the original item started here.

So I also added all data and some demo video's about how far I have progressed.

Report what is good and what may be an obstacle with only the OFFLINE BRouter offer.

So invite other users to test something and report experiences to improve eventually.

Due to unnecessary reaction, this item also threatens to disappear in the background too quickly, unfortunately.


Thanks Libor for very excessive and precise explanation.

Willy is nearly right with the statement that my rerouting profile prohibits ferries (not "sometimes", but always).

I will add ferry routing because the profile is intended to recreate any track, even if it goes over a ferry.

However, I do not plan to alter the priorityclassifiers for now (they are based in the default brouter trekking profile).


Tnks Zossebart.

Should be nice if more ferry friendly routing would be tuned into ALL standard profiles.

(Before Covid) A very popular ferry. In Summer sometimes continuous operations @ max capacity

File by BRouter web: Generates a correct directional u-turn left altough is not reflected into the name.


Note again that the rerouting profile is meant to be used only for rerouting of existing tracks to get turn instructions, NOT for routing of new tracks. It is essentially a "shortest" profile without access restrictions, so will happily route over access=private, construction etc.


That would be my biggest wish to Locus.


Given that this is quite difficult task to achieve, I suspect not to see much progress over the next 20 years.

And because of the quite few tests and still very weak general results is it even worth the extra development time ?

So as for now you can hardly see any progress on this subject, because it is for sur anything but easy to achieve.

The only thing that worked reasonably correctly well by a test was by placing (internal) distance (km) tickmarks on a (recorded) track of very GOOD quality.

Reference tickmarks which so hardly deviate from the osm (profile) street pattern and that may also not be positioned on 'forbidden roads' for the means of transport.

NOK: A (recorded) motorbike track which runs over a bicycle path or footpath is 'of course' never accepted by the routing engine if the correct motorbike profile is selected.

The reference tickmarks proximity snap to street distance should anyway also be limited. Tickmarks that deviate too much do better not participate in the route construction.

After a first rough track map matching, those tickmarks which still cause unexpected track glitches and thus U-turns have to be excluded.

Even after that, the result is not completely foolproof, the user should always check the final result and if necessary fine tune manually.

By the way and over again.

All this is certainly not an easy task to achieve automatically. A manual visual check so is always necessary.

For fairly short routes, the manual design using an underlying track template is still the most optimal and recommended mode.

See example by Plotaroute web (premium) that offers an automatic function and this probably due to the use of the GH (complicated) map matching module.

After the introduction notification there was very soon a first user report of false instruction attachments, followed than by no comment, and a general silence. Significant not ? Tuesday 29 Sep 2020 08:46:44

"a slight squiggle in the original route could lead to unintended, brief, out and back legs"


Highly desirable and necessary trackglitch corrections are best performed by u-turn generation and detections, so at least if the router generates them. Only a (very) few high-performance routers and a single performant application do currently support this !


Want to test ?

Use decent (short) track records.

Roundabout support not (yet) available.

RouteYou web, by free account.

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.


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?

Leave a Comment
Attach a file