OSM way has bicycle=yes yet graphhopper routing adds ~7km detour ...due to surface=gravel?

[uk-jf]

I’m considering a 50 metre long route that’s entirely contained within a way that has the bicycle=yes tag: https://www.openstreetmap.org/way/32405217/history

When using graphhopper with vehicle=walk or vehicle=hike the route is direct and as expected:
https://graphhopper.com/maps/?point=53.432102%2C-2.288552&point=53.431795%2C-2.287999&locale=en-GB&vehicle=foot&weighting=fastest&elevation=true&turn_costs=false&use_miles=false&layer=Omniscale

For some reason graphhopper will not route cycling along this way, instead offering routes of 8.56km, 6.48km and 7.99km for vehicle types of bike, mtb and racingbike respectively.

For reference, graphhopper correctly returns no route for any motorised mode, which is accurate as the way is a motor-free bridleway (and part of the UK’s National Cycle Network).

I’m familiar with OSM and its tagging options, so have amended the way’s surface to compacted but this has not yet propagated or made a difference, so it’s currently possible to see all of the above routes by changing the mode.

I’m keen to understand why graphhopper would suggest such a long detour rather than the direct option, so is anyone able to confirm how graphopper considers surface=gravel for cycle routing?

[ratrun]

Seems to be this issue: https://github.com/graphhopper/graphhopper/issues/504.

[Sam_Crawford]

From glancing over the code, I concur that it’s due to the highway=bridleway tag. I think the issue is caused by there being no highway speed set for bridleway in the code, so it exits the getAccess method early on: https://github.com/graphhopper/graphhopper/blob/2b06bd28083c11746ba63ee0dd60622832391ae8/core/src/main/java/com/graphhopper/routing/util/BikeCommonFlagEncoder.java#L242