Wheelchair Route Scoring from Crowdsourced Footpath Accessibility Audits

The problem: nobody maps the barriers

For a wheelchair user in Lahore, Karachi or Delhi, a 500 metre trip can be impossible: a footpath that ends in a 30 centimetre kerb with no ramp, a ramp blocked by a parked motorbike, broken paving, a building entrance with three steps. Older people and parents with prams face the same barriers. Navigation apps route around traffic, not around steps.

Universities, municipalities and disability organisations want to fix these problems but rarely have the data to prioritise. Volunteers are often willing to help. What is missing is a well-designed audit process and a data pipeline that turns scattered observations into a reliable network and useful routes.

What already exists and the gap

• Wheelmap, run by the German non-profit Sozialhelden, crowdsources whether places are wheelchair accessible, using OpenStreetMap. It rates destinations, not the paths between them.
• AccessMap, from the University of Washington's Taskar Center, offers accessible pedestrian routing for some US cities based on sidewalk data.
• OpenStreetMap supports tags for kerb height, surface, incline and wheelchair access, which are rarely filled in for South Asian streets.

The gap is a practical audit and data pipeline for South Asian streets and campuses, with quality checks and routing designed around the barriers that actually exist there.

Inspiration

Saha and colleagues' paper "Project Sidewalk: A Web-based Crowdsourcing Tool for Collecting Sidewalk Accessibility Data At Scale" (CHI 2019) showed how volunteers labelling street-level imagery could map curb ramps, obstacles and surface problems across a whole city, with careful attention to label quality. Your project adapts the idea for places where street-level imagery is sparse, combining on-the-ground audits with open map data.

What you build

• Volunteers walk the area with a phone form, recording footpath segments, ramps, kerbs and obstacles with photos and GPS.
• The pipeline snaps audits to the footpath network, merges duplicates, checks agreement between auditors and flags suspicious records.
• The router finds the best route for a chosen profile, avoiding steps and steep kerbs, and explains its choice.
• The disability office or municipality sees which buildings are unreachable without steps and which repairs would open up the most routes.

The technically interesting part

• Building a footpath network. OpenStreetMap in South Asian cities often maps roads but not footpaths. Derive pedestrian links, add crossings and correct them from audits, and measure how much the network changes.
• Data quality. Volunteers disagree. Have a sample of segments audited twice, measure agreement, and use it to decide which fields are reliable.
• Route scoring. Model each segment's cost per profile: a step may be impassable for a manual wheelchair and a mild cost for an older walker. Make profiles editable by users.
• Repair prioritisation. For each barrier, compute how many origin and destination pairs become reachable if it were fixed. This turns audits into an investment list.
• Temporary obstacles. Market stalls, parked motorbikes and construction come and go. Record whether a barrier is permanent or temporary, with a date, and let temporary barriers expire unless re-confirmed, so routes do not go stale.
• Contributing back. Translate clean audit results into OpenStreetMap tags following community guidelines, so others benefit.

How to evaluate it

• Audit agreement: inter-rater agreement per field on double-audited segments.
• Route validity: wheelchair users or volunteers test a set of suggested routes and report whether each was actually passable.
• Coverage: share of the study area's footpath network audited.
• Usefulness: whether the repair priority list matches the judgement of the campus disability office or a disability organisation.

Suggested plan

• Weeks 1 to 3: meet wheelchair users and a disability organisation, design the audit form, choose the study area.
• Weeks 4 to 7: audits, footpath network from OpenStreetMap, data cleaning.
• Weeks 8 to 10: quality checks, route scoring, repair prioritisation.
• Weeks 11 to 13: web map and route explanations.
• Weeks 14 to 16: route testing with users, report and demo. A second semester could extend to a larger district.

Path to a product

Universities, malls, hospitals and municipalities increasingly face accessibility expectations from regulators, donors and the public. An audit service with a data platform and a public map is a practical business, and the open data contributed back to OpenStreetMap has lasting value. The project combines geospatial data engineering, data quality and user research.

Scope warning

Start with one campus or a few city blocks; a whole city is far too large. Design with disabled people, not for them, and pay or credit participants fairly. Do not publish photos showing people's faces or vehicle number plates. Agree in advance with the campus or municipality how the findings will be shared.

Learn what you need on Sefism

• Data engineering roadmap: pipelines and data quality checks.
• SQL and databases roadmap: the database foundations under PostGIS.
• PostgreSQL Documentation: spatial queries and indexes with PostGIS.
• Python for Data Analysis, 3rd Edition: cleaning and merging audit records.
• From Data to Viz: presenting accessibility clearly on a map.

Get help with this idea

The hard parts are reliable audits and routes that people can actually travel. Tauseef can help you design the audit protocol, the quality checks and a route test with real users. If you are new here, create a free account first.

• Discuss this idea with a mentor
• Send a query to Tauseef
• Book a 1:1 session