OpenStreetMap

OSM keeps its data model intentionally small: nodes store coordinates, ways connect nodes into roads or paths, relations group objects, and tags add meaning. This simplicity is important for crowdsourcing because contributors can inspect, discuss, and correct the map without needing a specialist GIS model. Wheels4Wheels follows the same constraint: we do not create a separate accessibility layer or split streets into tiny telemetry fragments. We map-match e-scooter points, assign them to existing OSM ways, aggregate the signal per way, and then filter proposals by coverage and agreement before review. Instead of modeling every vibration as a new map object, Wheels4Wheels reduces the data to the level OSM already understands: existing ways plus standard smoothness=* tags.

“Tags”, the OSM term for key-value pairs, describe what an OSM object represents. Key and value can be up to 256 characters long. Mappers can choose any key and value they would like to use (the any tags you like rule). Because countless applications use OSM data, certain de facto standards were established. Frequently used tags are documented in the Map Features list on the OSM Wiki, and the data model was intentionally kept flexible to avoid an early determination of future developments. A few examples show how tags read in practice: highway=residential for residential streets, shop=supermarket for a supermarket, and name=Kaiserstraße for an object named “Kaiserstraße”.

OpenStreetMap models roads, streets and paths as ways. Attributes of the streets are usually added as tags. The following tags can be considered as established. Some are present on almost all streets, some are rarely used.

Most of these attributes refer to the carriageway, not the associated sidewalks. Footpaths along streets can be mapped in two ways, and both appear in practice – the choice shapes how routing engines see the sidewalk.

However, several projects that aimed to improve routing for wheelchair users and blind pedestrians preferred to map sidewalks as separate ways. They make it easier to model crossings of the carriageway at intersections because lowered curbs are a requirement for wheelchair users. Adding just tags avoids drawing extra ways and looks simple at first glance – but routing engines cannot determine which side of the road to use unless explicitly modeled.

In contrast, sidewalks mapped as separate ways can be consumed by existing routing applications and are easier for mappers to understand. If attributes of the sidewalk change between two intersections, the way representing the carriageway does not have to be split. This avoids fragmentation of the carriageway.

On the other hand, separate sidewalk ways cannot capture that pedestrians without disabilities can cross the carriageway almost anywhere. Either countless extra crossings across the carriageway would need to be drawn, or routers would return detours to the next crossing when a user requested a route from one side of the road to another. For more than ten years, no consensus has been reached among the OpenStreetMap community. However, many mappers who are against separate ways agree that separate ways are fine if there is a physical separation, such as a handrail, a fence or a strip of grass between the sidewalk and the carriageway and crossing the carriageway is not possible everywhere.

Barriers are obstacles such as bollards, gates, or cycle barriers that block or narrow a path. They are mapped as nodes placed directly on the way, and a small set of tags records what kind of barrier it is and whether it can be passed.

The openrouteservice project is the leading open-source routing engine for OpenStreetMap data, developed by the Heidelberg Institute for Geoinformation Technology. It supports various profiles, including wheelchair routing, with worldwide coverage. The wheelchair profile evaluates a defined set of OSM attributes and classifies each value as included, problematic, or inaccessible.

Unlike openrouteservice, the OpenSidewalks project is a combination of a routing engine and a mapping project within OSM. It is run by the Taskar Center for Accessible Technology (TCAT) at the University of Washington, together with Feet First, a pedestrian advocacy group operating in Washington State and the University of Washington's eScience Institute.

GraphHopper offered a wheelchair profile in the past. Due to limited support for key features (e.g. sidewalk=*), the developers removed it. It had basic support for barriers and excluded cycle barriers from wheelchair routing.

One approach to improving sidewalk accessibility data in OSM is through active contribution by users of e-scooters. Their vehicles are highly sensitive to surface irregularities, allowing riders to sense and report relevant accessibility attributes.

The StreetComplete app is particularly effective for this purpose. It simplifies contributions by asking contextual questions about missing map information. It cannot modify geometries or add new nodes such as curbs, however.

Active contributions improve OSM rapidly but carry risks: inaccurate tagging at scale can overwhelm volunteer mappers. Mapping campaigns should therefore be coordinated with local OSM communities, with trained editors reviewing incoming notes.