Mapping Platforms
Why accessible navigation depends on the data layer, routing logic, and what map apps expose to users.
Three Levels
When we talk about maps, there are three things we need to differentiate: the information level, the routing level, and the representation level. All three matter for accessible navigation in cities. But the information level is the foundation. Without a detailed and parameter-rich database, updated regularly, routing and pathfinding will not reflect the actual situation in cities.
Information
Available data for a geographical location
Routing
How pathfinding can move through an area
Representation
What users actually see and benefit from
As a result, user-facing apps can lead people to dead ends, impassable ways, stairs, high curbs, or pathways with surfaces that are technically mapped as roads but are not usable in a wheelchair. The gap is rarely the routing algorithm itself – it is the missing or unused data underneath it.
Wheels4Wheels Focus
Wheels4Wheels focuses on the information level. The goal is to enrich the crowdsourced database OpenStreetMap with wheelchair-relevant parameters: surface quality, smoothness, curb information, incline, width, and similar details that define whether a path is actually usable.
Wheels4Wheels contributes at the foundational level so pathfinding can be improved, and user-facing apps and services can pick this information up. It is not a new navigation app and not a new way to navigate – the project improves the data layer that routing services and map apps depend on.
| Database / Data Source | Model | Who Contributes | Accessibility Parameters | Fit for Wheels4Wheels |
|---|---|---|---|---|
| OpenStreetMap | Open, crowdsourced | Anyone, with community review | Surface, smoothness, curbs, incline, width, wheelchair tags | Strongest fit |
| Google Maps | Closed/proprietary | Provider-controlled, with limited user edits | Some accessibility features exist, but routing parameters are not publicly documented | Not a direct contribution path |
| Apple Maps | Closed/proprietary | Provider-controlled, with limited user edits | Accessibility guides and place data exist; routing parameters are opaque | Possible partner path |
| HERE/TomTom | Closed/commercial | Provider-controlled | Depends on provider and contract | Possible in theory |
Why OpenStreetMap
OpenStreetMap is the obvious go-to for Wheels4Wheels because it is open, editable, regularly updated by communities, and already supports the kind of detailed parameters wheelchair routing needs. The idea itself is not limited to OSM. Any database could adopt the same approach. Even a closed database could decide to collect and use these parameters. OSM is simply the most practical place to start.
Routing Level
Once the information exists, routing services decide whether they actually use it. Some routing engines are already very feature-rich. They can use parameters like surface, smoothness, curbs, incline, width, and steps. The openrouteservice API exposes wheelchair routing restrictions for surface, smoothness, sloped curbs, incline, and width. GraphHopper can use OSM parameters through custom routing models, although it no longer ships a maintained wheelchair profile, so accessibility routing has to be configured per deployment. Valhalla and OsmAnd also seem to make partial use of some of these parameters.
This is where Wheels4Wheels data starts to become useful for actual routing. If the database has smoothness=*, but the routing service ignores it, the user will not benefit from that parameter. Today, the bottleneck is coverage of these parameters, not algorithm quality.
| Service/Engine | Smoothness/Surface | Curbs | Incline/Width | Notes |
|---|---|---|---|---|
| openrouteservice | Strong | Strong | Strong | Best documented wheelchair routing fit |
| GraphHopper | Strong via custom models | Not clearly documented | Strong via custom models / slope data | Good builder path |
| OsmAnd | Partial | Partial evidence | Partial evidence | Needs app-level wheelchair UX verification |
| Valhalla | Partial/improving | Curb support not documented | Some slope/elevation support | Wheelchair type exists, but not a full accessibility story |
| Organic Maps | Compressed into broad internal surface buckets | Curb routing not documented | Elevation profile/info | User-facing control found: avoid unpaved |
Organic Maps
Organic Maps is the clearest mainstream-ish open-source example that already offers an "avoid unpaved" option. That is a thoughtful step. It is based on OSM and uses its own custom bidirectional A* offline routing algorithm.
The interesting detail is that Organic Maps already ingests OSM surface=* and smoothness=*, but compresses them into four broad internal surface buckets: paved_good, paved_bad, unpaved_good, and unpaved_bad. Routing uses those buckets as speed or weight factors, but pedestrian routing barely penalizes surface quality today.
So "minimal surface level" is a realistic feature direction. A first version could expose something close to "avoid bad or unpaved surfaces" using existing Organic Maps data. A proper "minimum smoothness: excellent/good/intermediate/bad" setting would need deeper generator changes because raw OSM smoothness is currently compressed and partially lost.
"Avoid crossing curbs" is the bigger lift. We did not find curb classifications in the shipped Organic Maps routing path. That would need OSM tag ingestion, map format changes, routing metadata, graph penalties, UI, and probably a dedicated wheelchair or accessibility routing mode.
Representation Level
The representation level is what users actually see, and here we run into another problem. Pathfinding services can be very feature-rich and customizable. You can pick how you want to move, so that the algorithm leads you around curbs, avoids pathways with very rough surfaces, or avoids paths that are too narrow or too steep.
But this kind of granularity can be overwhelming for regular map users. Major software providers like Apple, Google, and Microsoft prefer to simplify map apps to the bare minimum. That makes sense for most users, but it is not ideal from the perspective of wheelchair users or other people with specific needs for navigation around the city.
| App | Accessibility Route Parameters | What Users Can Control | Notes |
|---|---|---|---|
| Google Maps | Partial | Mostly standard route modes | High reach, low parameter transparency |
| Apple Maps | Partial | Mostly standard route modes; accessibility guides and place info | Interesting partnership target |
| Organic Maps | Partial surface handling internally | Avoid tolls, unpaved roads, motorways, ferries; elevation profiles | Open-source and already exposes avoid unpaved |
| OsmAnd | Partial/advanced | Many profile and routing settings | Powerful, but can be complex |
| Waze | Not documented | Traffic-oriented route controls | Strong UX, not accessibility-parameter focused |
The product caveat matters: OSM curb and smoothness coverage is uneven. Any user-facing control should communicate "prefer or avoid where data exists", not guarantee accessibility. The problem is that "simple" often means the app hides the parameters that actually matter.
Next Steps
Wheels4Wheels calls on map contributors and developers of mainstream map apps. Including even basic parameterization in search and navigation would significantly improve the quality of life for millions of people. Every internal routing parameter doesn't need to be exposed to every user. A few simple options could already help a lot.
- Minimal Surface Quality: Route only over surfaces that meet a chosen quality
- Avoid Curbs: Prefer crossings with lowered or flush curbs
- Maximum Incline: Cap how steep any part of the route may be
- Prefer Mapped Areas: Favor streets that already carry accessibility data