Bicycle routing is close to unusable outside built-up areas

[mvglasow]

Steps to reproduce

Enable the bike profile and calculate a route outside of built-up areas. (Some routes in cities also work.) Examples:

• Downtown Vilnius to Česlovo Kudabos gatvė (near VU botanikos sodas, Kairėnai)
• Downtown Vilnius to Trakai Island Castle

Some issues also arise in built-up areas. Example: Milan, from the western end of via Novara to downtown Milan.

Expected result

A somewhat easy-to-follow route along bikeable paths

Actual result

The two routes from Vilnius took me over gravel paths in terrain which was not exactly suitable for bikes, even though better routes were available. In Trakai, the stretch of Gedimino gatvė which is trunk is not considered at all for bike routing; Navit sends bikers all the way around the lake (~ 10 km) for a stretch that is less than 1 km long. (Example: from downtown Trakai to the parking lot near the station). For the Milan use case, instead of sending me straight down via Novara (a primary road), Navit suggests a zigzag course along residential roads.

Version used

Pretty current, with a bike profile tweaked only to consider one-way restrictions. This is a long-standing issue, however.

Further information

I suspect this is mostly the bike profile in Navit. Improvements would be:

• Penalize high-order roads (primary etc.) less heavily, or maybe not at all
• Figure out why trunk is not considered for bike routing: are we setting access flags incorrectly? (highway=trunk does not imply that bikes are forbidden; this could be expressed by motorroad=yes.) Or is the fault with the bike profile?
• If we can use surface information (not sure if we can), penalize unpaved roads (and while we are at it, maybe also cobblestone roads)
• Maye give preference to dedicated bike paths (this would need to be tested)

Height information would also be vital to bike routing, but that is likely a major design change: we would first need height information in the map data, then incorporate that in the cost calculation.

[mvglasow]

Looking at the bike profile, I see what is happening here: street_n_lanes is missing, which is probably an error (judging by the comments, which say trunk is acceptable but with low preference).

Also, path and track_ground get a relatively high score—possibly good for those who want a scenic route even at the expense of rough terrain, but not so for getting from A to B. (I would focus on the latter use case because that is what routing apps do—picking the most scenic route requires a completely different approach to cost calculation, with information which might not even be on the map.)

I see that some of the dirt paths are of type footway, which is mostly a fault of the map data (likely in OSM itself), thus little to do here.

[mvglasow]

I realize preference for cycleway is also tricky, as that might give preference to a cycleway which runs parallel to a primary road to, say, a residential road. Not necessarily what one would want…

[mvglasow]

Another challenge is that for ways where both bikes and pedestrians are allowed, we do not know if they are segregated or not, though that information is relevant for routing (we can presumably go faster if the way is segregated and we do not have to heed the pedestrians).

[mvglasow]

Closing since #850 is merged, which is probably the best we can get with the current data model and cost calculation algorithm