Heading, give route a start direction

[devemux86]

IBRouterService.aidl mentions the heading parameter to give routes a start direction.

However it does not seem to work. For example this simple route on a 2-way street.

When we pass via the Android service the heading=160 (i.e. south), BRouter keeps returning the same route going north to the destination.

Other routers calculate the route correctly, i.e. first going south. The routing heading direction must be enforced. Is it possible?

Originally reported in https://github.com/devemux86/cruiser/discussions/175#discussioncomment-6406441.

[abrensch]

The heading does not really enforce the start-direction, just penalizes the wrong direction.

For the Standard-Model (=bike profiles) that should be twice the "turncost" for 180 deg.

For the Kinematic model (=car) it's added as an extraTme, hardcoded 40 seconds for 180 degree (see https://github.com/abrensch/brouter/blob/master/brouter-core/src/main/java/btools/router/KinematicPath.java )

But in your example the extra cost of going forward is much higher than this 40 seconds.

Please also note that the AIDL-interface has two params, the original one ("direction") made for Locus Maps is only applied for "fast recalculations" because Locus delivers the param also when not mooving and then it's just noise.

The "heading" parameter does the same as "direction" but is always applied.

[devemux86]

@abrensch thanks for the explanation.

I already use the "heading" parameter, but the results are not correct. So users keep complaining that BRouter calculates backward routes.

But in your example the extra cost of going forward is much higher than this 40 seconds.

This is a small example. If you check the reported route above in the first post, start is 14.8 km / 19 min away from first waypoint, but heading is not respected.

In the example heading=160, we cannot expect cars to make u-turn or go backwards, must go south. All other routers that support heading (GraphHopper, OpenRouteService, Valhalla, etc) work correctly.

We need to think about real road conditions (motor vehicles move forward), not just graph mathematics.

A better solution could be a new parameter "forcedHeading" that does what drivers expect on the road? Existing parameters can continue to work as they are now for compatibility.

[abrensch]

I just do not believe that solutions according to "go forward for now and u-turn a bit further ahead where the OSM network allows it." are correct in the majority of cases.

This is because the OSM network is not correct in this respect.

Another related problem is the lane-matching: sometimes I get a backward solution though my 40 seconds would be enough to favour the forward solution. This can happen because the re-routing catched the backward-lane in waypoint matching due to GPS jitter.

So yes I agree we are far from poviding "the most intuitive" soluion.

But no, I don't believe that GraphHopper and friends provide the "correct" solution.

[abrensch]

This is because the OSM network is not correct in this respect.

It's possible o show examples for bad u-tun solutions by triggering them via turn-restrictions:

http://brouter.de/brouter-web/#map=15/50.4627/8.0643/osm-mapnik-german_style&lonlats=8.057876,50.464222;8.057715,50.464771&profile=car-fast

http://brouter.de/brouter-web/#map=14/50.4081/7.7818/osm-mapnik-german_style&lonlats=7.802141,50.419268;7.802246,50.41921&profile=car-fast

[devemux86]

We seem to mean different things. :slightly_smiling_face:

In real life driving, users expect the routes to always guide them to drive forward (regardless the route length).

The above example (with help of a no-go area to force heading 160 south) becomes like this expected route.

A much longer route, but it is the expected result in real life vehicle navigation.

[abrensch]

A much longer route, but it is the expected result in real life vehicle navigation.

For cruiser to outperform G-maps in market share, it should be a bit more economical in terms of mileage :-)

BTW, my (G**gle-based) car navi suggests strange forward solutions u-turning by an extra lap in someones backyard. Quite annoying.

[afischerdev]

We have at the moment penalty only in car profiles (via KinematicPath). I would like to see that for bike and foot as well. My favorite routing app should recalculate this example routing suggestion if I prefer to walk along the lake. The problem I see is the routing restarts to target. What when we use via points? It this still a valid point at re-routing? Sample

[devemux86]

It this still a valid point at re-routing?

At re-routing the heading is much more important, as users are already using their devices to navigate. They cannot stop (eg drive) to correct the wrong routing that sends them backwards.

[afischerdev]

Yes, I think so. But what to do with the via point - drop it or use it? There is no intuitive answer.

[devemux86]

But what to do with the via point - drop it or use it?

What do you mean?

Do you mean to place a via point above the lake? This could work in manual route planning. Example

But adding automatically a via point in front of start to force a forward routing is not enough. Depending the via point location the results can be very different. Example

Extra via points to influence the routing heading can only work in manual route planning, where we can adjust the routes. Not in re-routing during a running navigation where users are moving and cannot plan routes.

[afischerdev]

I mean my second sample, but I see it hasn't a via point, sorry. But when it is a little off the route after re-routing - may be in this small case 'correctMisplacedViaPoints' will do the job, but not always.

[devemux86]

@afischerdev I do not clearly understand what you mean?

The "forced" heading is required for the start point of re-routing, where user is when navigating.

Other routers also offer heading in the via points, but we should start with the basic requirement.

[afischerdev]

@devemux86 Yes, agree, a heading is needed. But re-routing would ends in this result. An now the via point is misplaced.

[devemux86]

If the route can be forced to start forward, then we do not seem to need the extra via point. Example

[afischerdev]

The via point was there before re-routing.

[devemux86]

The via point was there before re-routing.

@afischerdev Thanks, now I understand.

But the via points are not relevant with the start heading. They could be near, they could be far away.

[afischerdev]

So far I haven't found a satisfactory result. But I have an other idea: The use of a nogo point has already been discussed. But this will become a breaking situation when user enters a dead end situation. To avoid this, a weighted NoGo point can be used. Replace &nogos=10.364029,63.383186,27 with &nogos=10.364029,63.383186,27,10000 then an exit will be found. This also work with the first sample.

At the end we have the same situation as before, user hear the 'please u-turn'. But is has a stronger meaning then 'only' bring user back to old route. May be user needs a better advise and a new turntype 'deadend u-turn' is born.

[devemux86]

@afischerdev thanks for looking into this!

It's unfortunate that it can't be solved inside the router, even with a weighted solution.

In any case, your advice with the weighted NoGo is important, thanks! It is always better to avoid failed route calculations on the user side.

[devemux86]

I implemented the routing heading with the no-go area in Cruiser 3.0.30:

• https://github.com/devemux86/cruiser/discussions/191

[afischerdev]

@devemux86 Thanks for let us know about the new feature.

[devemux86]

@afischerdev thanks for your hint about the weighted no-go.

All tests show that it is an important and functional solution.