Improving Foot/Bike profile to show instructions when turning if streetname doesn't change


Currently we are developing Turn-By-Turn functionality in our app for existing routes (no replanning) based on Graphhopper routing & instructions (you can see it in action in Dutch here). We are noticing missing instructions in some cases when turning, using the Foot/Bike flag encoders.

I haven’t found a similar question/situation on Github/Discuss yet, but if it exists, please correct me.

As these situations differ on other OSM routing engines (i.e. Mapzen/OSRM), which show correct instructions on those parts, we would like to contribute to improving Graphhopper to correctly handle these parts or to find the cause.

Illustration of the problem:

Examples (same issues apply for both foot/bike profiles):


On first glance it seems these issues surface when routing over simple paths that either don’t have a streetname or that have the same streetname before/after turning.


Basically we want to know if this issue is known, what the cause is and what we can do to contribute to a solution.

Are you using the latest master with this change?

1 Like

Oh wow, apparently I haven’t searched hard enough, missed that one. No I wrongly assumed was running the latest master.

Thanks for your quick reply! I will thoroughly test the latest master on our development machine and report back. This PR seems like exactly the fix for these issues.

1 Like

We are kind of running the latest ‘stable’ master on GH Maps. So if there is a commit which is significant we do test this with various other setups first.

That makes a lot of sense.

First results are looking great! Very promising. All of my examples above have correct new instructions.

When testing more and larger routes, I get a lot of Couldn't find the edges for X-X-X exceptions. I saw this Github issue that points to the exception being helpful when debugging the new instructions code?

It seems to me the exception is thrown when GH is unsure if the instruction should be a turn or not. Is there a way for me to contribute or use these exceptions to help improve the new instructions functionality?

1 Like

I think this PR should fix the problems:

Do you have an example where this encounters? (OSM file and GH maps link)

I would prefer a test before merging :slight_smile:

1 Like


Yeah I will compile a couple of cases that can be reproducible with a small OSM export file (if that is what you mean by OSM file?), then post them here.

Hmm, it seems OSM export went down. I could export one example though, do you need more? Then I’ll export more examples on monday.

Using master branch, without the PR fix.

Graphhopper link
OSM file (11,5MB, 7 days retention from now on this file upload website)

.properties settings (don’t know if elevation makes any difference):

### OSMReader ###






Please tell me if it isn’t reproducible for you with these settings.

Perfect, this works for me and that was what I meant, thanks a bunch!

1 Like

Nice! No problem. If I can supply anything else to help, don’t hesitate to ask.

1 Like

Looks like the PR does not fix all cases (see the comment in the PR). Do you have an example with no via point?

Haven’t found any situations of two points (A–>B) that have this issue yet. Most of our routes are based on multiple via points and after finding around 20 examples (both for foot&bike) that have the issue, they all are based on A–>B–>C, so with a via point in them.

Does it help to have more examples of the issue with a via point? I can supply some more examples if you want. I’ll keep testing our routes (both for instruction quality and this error) and will let you know if I find examples without a via point.

Haven’t found any situations of two points (A–>B) that have this issue yet.

Did you try with or without the changes in #1014?

Ok, thanks. I’ll try to fix the via issue.

1 Like

Did you try with or without the changes in #1014?

Yeah those 20 examples I’ve found now are using the PR code.

I recently updated the code in #1014. The issue should be fixed now, let me know if there are any unexpected results.

1 Like

Awesome work, thanks! First results are looking very good. The issue seems to be fixed and instruction quality seems great in early tests.

I will test more thoroughly on larger datasets and routes on Monday and report back here.

I’ve tested a lot of routes and situations on both the Foot & Bike flag-encoders with the latest PR code. I haven’t got any errors yet and results are looking good!

When taking a closer look at the instruction results, I’ve noticed some examples that may have discrepancies, though they might be working as intended because of OSM tagging.

Is this the right place to mention these situations? If not, I’ll make a new topic for them.

Bike - Graphhopper Link - OSM Link - This part seems to omit an instruction on the new code, while showing correct instruction on HEAD version.
Foot - Graphhopper Link - OSM Link - Instruction says ‘keep right’, though visually it seems it should be ‘keep left’. This is the same instruction as on HEAD version, so if it shouldn’t be changed with the new instructions, this case can be ignored.
Bike - Graphhopper Link - OSM Link - When using Bike encoder, the first instruction is ‘keep right’ which could be wrong. Also the ‘turn right’ after the first ‘turn left’ is missing. This route has correct instructions on HEAD and it seems not to occur when using the same route on the Foot encoder.

I’ve noticed a couple of these ‘keep left’ or ‘keep right’ instruction discrepancies. If it is helpful, I can post the rest I’ve found?

1 Like