I think it would be helpful if you could give an example?

CT uses OpenStreetMap data, something that we can all edit. If CT is refusing point blank to go a particular way that will be due to the underlying data saying that it shouldn't be done.

You should check that you have the gravel option highlighted as that's one reason that CT won't go a particular way.

You can also 'force' CT to go a particular way by adding a viapoint (1) as close as possible to the 'forbidden' track and another as close as possible at the end (2). Then click on Viapoint 1 and select direct to 2 and CT will draw a line directly. It will affect climbing data and probably distance but you'll have a complete route for the likes of a gps unit. 

Thanks. Here is what I ran into yesterday: https://cycle.travel/map/journey/554287

Cycle.travel refuses to route on the trail that is between via points 20-22. If you switch the layer to CyclOSM you see it is shaded in orange, so a MTB route.

This is only one of several examples for just this one route. In the past cycle.travel would just refuse to route where it considered there was no right of way or bikes shouldn't be there. This seemed to have been fixed with the gravel routing option, but now it appears to be back.

Sadly I cannot force cycle.travel to route even by dropping points where I need to go since often cycle.travel refuses to drop points where I click if it does not want to route there. Which makes me think it's a deliberate choice.

It’s because the track in question is marked with sac_scale=mountain_hiking in OpenStreetMap. To be honest this looks like bad mapping to me – something shouldn’t be marked with tracktype=grade2 and sac_scale=mountain_hiking at the same time, they can’t both be true. But I’ll take a look at making c.t more forgiving in this case.

As a general rule, cycle.travel is a planner not a plotter - if you want to put a route you already know on a map, rather than using c.t's routing "brain" to choose a route between two points, then it's probably not the best site for that. I'd usually recommend RideWithGPS or Plotaroute in these cases.

Thanks for checking Richard, I appreciate it.

My preferred behaviour would be the following:

1. I like cycle.travel's routing a lot. So that should behave the way it currently does.

2. However, sometimes I like to overrule it. That should also be possible. I don't see any benefit from making it impossible for a user to go somewhere.

cycle.travel won’t ever route you anywhere that it considers impassable. If it allowed impassable sections – say, with a penalty of a 100x worse score than a standard cycleway – then the standard routing could potentially send people down a 1m impassable path to shortcut a 101m cycleway. (There are also technical issues with applying very big penalties which I won’t go into!)

The challenge is working out what’s impassable and what isn’t. In this case it’s getting it wrong, not helped by some confusing OSM tagging. I’ll have a play with its tag parsing here, and perhaps also fix this bit of data in OSM!

Thanks a lot Richard! I don't see where 2. (user can overrule routing) conflicts with keeping 1. (cycle.travel's present routing algorithm).

The reality is that OSM data in some parts of the world will always be deficient (in particular for gravel riding), and I have found myself stuck many times having to move off cycle.travel when all I would have needed is an option to letting my drag a route to where I knew I could ride but cycle.travel did not want me to.

Maybe like the RouteYou (osrm) router offers it? The "osm shortest" profile fits exactly between standard routing and the manual mode. The advantage is that this way you still follow a known osm path. Know what you are doing, but with the necessary (pre)knowledge it can indeed be very useful.

help.routeyou.com/en/topic/view/25/routing-options#shortest-osm

“I don't see where 2. (user can overrule routing) conflicts with keeping 1. (cycle.travel's present routing algorithm).”

The user can of course overrule routing by drawing a straight line on the graph using the ‘Go direct’ feature.

To be able to follow impassable ways, those ways have to be added to the routing graph. If they’re in the routing graph, then sometimes c.t will route along them without the user expressly requesting it – that’s how the algorithm works. There is no way in the current algorithm to be able to say “this is a way that should only be selected if there’s a via point on it”. 

That makes sense, thanks for letting us peek under the hood.

The workaround does not quite work in the example below, as cycle.travel does not allow me to place via points to then via a direct line without relying on the routing. Otherwise I would just have rebuilt (a coarse version of) the trail I was meaning to follow.

If cycle.travel could be more foregiving as to where it allows via points for direct line connections I think this issue would be solved.

@Willy: Thanks for that as well. brouter offers that, too, but I really like cycle.travel so I was hoping to have a solution that allows me to do it all in one piece of software, namely this one.

Absolutely – I’d very much like it to be more forgiving in that case. Unfortunately it’s a particularly gnarly bit of the routing engine code and so far it has resisted all attempts at me poking it into submission ;)