Filtering out grade of tracks for bicycle routing


this is my 1st post here and I would like to begin by thanking you for this great tool. I use openouteservice for planing bicycle trips and it is almost perfect. The problems often come from missing / incorrect data in osm which I then correct, but sometimes I don’t find a reason based on the osm data.

For example I sometimes I get routed through paths that should not have been considered because of a bad quality, like on the following routing:

The beginning of the Waldstraße coming from Schlierbach is asphalt, grade 1, which is really nice. But after this I get routed through the grade 4 track, even when I select grade 3 as a minimum route grade in Route options>Profile parameters>Restrictions.

Are these restrictions maybe not considered with the “Bike” profile?

The next part of the route is also problematic: after the short asphalt part following the grade 4 track, instead of taking the nice grade 2 track that goes directly to where I want to arrive, I get routed through a path which is in it first part even tagged with “obstacle=vegetation” (which I can confirm for having been there). In this case I have no idea why openrouteservice chooses this small path over the nice track (in addition to this, the path goes over the top of the hill with more altitude difference, but I don’t know if this is considered by the tool).

About this last point, I haven’t found it and don’t know if it is possible, but t would be nice to be able to filter out some parts of routes that exceed a given steepness.

I hope you can help me a bit with this problem and thanks again for the great tool.

Hi @Le_DENKI ,

Please be aware of the profile restrictions for the profile_params.
track_type is for wheelchair only.

The obstacle attribute is not considered at all.
A bad track_type will receive a speed penalty which is considered during routing (see tracktype-speeds)

At the same time it will prefer routes that are a bit longer if it can go faster (eg. 18 on compacted) and make up for the lost distance.

However the more direct route in this case is also faster, so probably some internal weighting is rating the top route as more suitable.

Feel free to open a bug report in the backend repository including thorough description of the problem (or link to this post, but pls provide requests, response and links to the actual osm ways you are talking about)

Best regards