Fix bicycle profile: cap speed at 21 km/h and add test coverage for high maxspeed values

[Claude]

The problem statement requested verification that tests cover cases where maxspeeds are set to high values (e.g., 100 km/h) and that resulting speeds remain bikeable, including for forward/backward directional maxspeeds.

Test Coverage Analysis

The existing tests in features/bicycle/maxspeed.feature already provide comprehensive coverage:

• High maxspeeds capped to bikeable speeds (lines 57-63): Tests residential and cycleway highways with maxspeed=100, verifying results stay at safe 15 km/h instead of car speeds
• Forward/backward directional maxspeeds (lines 74-77): Tests all combinations of maxspeed, maxspeed:forward, and maxspeed:backward set to 100 km/h, confirming proper capping in both directions
• Unroutable ways remain unroutable (lines 84-94): Ensures high maxspeed tags don't make inaccessible ways (railways, runways) suddenly routable

Implementation Details

The bicycle profile's vehicle_max_speed = 21 km/h cap (set in profiles/bicycle.lua:43) works through a multi-layer speed calculation:

1. Base speed from highway type (15 km/h for most)
2. Maxspeed tags applied via MIN operation (can only reduce, never increase)
3. Vehicle max speed cap applied (limits to 21 km/h max)

This ensures OSM data containing car-centric high maxspeeds never produces dangerous bicycle routing suggestions.

No code changes needed - all test coverage requirements are already met.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>OSRM bicycle route has huge detour and wrong duration</issue_title>
<issue_description># Issue

L39 has cycleway:both=shoulder and should preferred over the huge detour via K21. Alternatively a route via Sang would be acceptable.

Also the duration is completely wrong. Nobody can ride 15 km in 17 minutes.

Steps to reproduce

https://www.openstreetmap.org/directions?engine=fossgis_osrm_bicycle&route=51.43408%2C6.26925%3B51.40081%2C6.30512#map=13/51.42752/6.30770</issue_description>

<agent_instructions>Investigate the bike profile:

• how speeds could end up unrealistically high?
• is the maxspeed tag factored in?
• devise a plan on how to fix it with options where possible
  </agent_instructions>

Comments on the Issue (you are @claude[agent] in this section)

• Fixes OSRM bicycle route has huge detour and wrong duration #7145

[ThiloteE]

Choosing a maxspeed cap of 21 km/h seems quite arbitrary. According to https://wiki.openstreetmap.org/wiki/Key:maxspeed, legal values differ substantually based on country. Peak real world driving speeds are also heavily influenced by incline. Using my mountainbike, I personally routinely drive 25 km/h on flat ground, but can easily peak 50 km/h downhill at our neighbourhood hill. That road is two km long and maxspeed is legally 100km/h. Obviously, biking there uphill is a lot slower and using an E-Bike, I can only reach about 10 - 15 km/h.
21km/h could potentially be a good average biking speed (if real world measurements confirm), but I don't think it's a good hardcoded value for maxspeed.

[DennisOSRM]

That's good feedback, and you're absolutely right that 21 km/h is a simplification. Real-world bicycle speeds are heavily influenced by incline. As you point out, downhill can easily double or triple flat-ground speeds, while steep climbs can cut them to a fraction.

In the absence of elevation data being factored into routing, a flat-ground average is the best compromise we can make today. The 21 km/h figure is broadly consistent with typical average cycling speeds on mixed terrain, but it is indeed a rough approximation that ignores gradient entirely.

Proper support for a digital elevation model (DEM) during preprocessing is on the backlog. Once that's in place, speed estimates could be adjusted dynamically per segment based on slope, which would address exactly the cases you describe: fast descents, slow climbs, and the significant difference between a regular bike and an e-bike.