Status: in development

Navigation for vehicles that are neither bicycles nor cars: wider than a bike, slower uphill, faster downhill, and stopped by obstacles no existing router models.


Why this tool

Every routing engine assumes you are one of three things: a car, a pedestrian, or a bicycle. An intermediate vehicle is none of them. Thats how your GPS send you on a path with fense designed to make cyclist slow down and dismount their bicycle but your velomobile don’t have the maneuvrability necessary.

Width. Bicycle routing sends you down paths with anti-motorcycle gates, bollard spacings, chicanes, and barriers. A bicycle fits. A vehicle 80–120 cm wide does not, and discovers this at the gate, several kilometres into a route, with no alternative. There is no width parameter to set, because for a bicycle the question does not arise.

Slope asymmetry. Bicycle routers treat gradient roughly symmetrically and assume broadly consistent effort. For some vehicle, this is not symmetric: it is speed-capped on the flat and uphill by regulation and by available power, but not capped downhill, where low drag and mass work in its favour. A steeper, longer route can genuinely be faster than a flatter, shorter one, which no bicycle router will ever suggest.

Effort model. With pedal-by-wire, the relationship between gradient, speed, and rider effort is a configurable parameter rather than a fixed physical fact. A router that does not know the assistance configuration cannot estimate travel time.

Together these mean the fastest and the possible route for this vehicle differ systematically from both the bike route and the car route. Getting this wrong is not an inconvenience: a rider blocked by a gate or sent up a hill the vehicle cannot climb at a reasonable speed learns that the vehicle does not work, which is exactly the adoption failure Chapter 3 is about.


Why it is worth publishing on its own

Like the shape optimiser, this is useful to other people now. Every intermediate vehicle in Europe faces the same gates and the same hills, and as far as we are aware no one has a router for them. It also produces something the category badly lacks: evidence about where these vehicles can and cannot physically go, which is infrastructure-policy data as much as it is a navigation feature.


Open questions

  • Where barrier width is untagged, is it better to assume passable or blocked?
  • Should routing feed corrections back into OpenStreetMap, and how?
  • How much does the optimal route actually differ from a bicycle route in practice — is this tool solving a real problem or a theoretical one?

Mapping and routing people, we’d love to hear from you.