Yes, there are many applications (mirror) consuming OSM data for assistive navigation. There are also applications using OSM data to power “headless” navigation in wearable devices. However, none have the brand recognition of Apple Maps and Google Maps, which people with disabilities have gone through great lengths to cope with, even though these applications aren’t optimized for their needs.
Well-designed assistive navigation applications are very different than mainstream navigation applications. For example, Nearby Explorer was an OSM-based navigation application (and POI editor) for visually impaired pedestrians that was developed by the American Printing House for the Blind (APH), a major nonprofit Braille publisher in the U.S. The UX was much more explicit about the user’s surroundings than in a conventional application. APH’s indoor mapping team demonstrated how to use the application at State of the Map U.S. 2019. As proof that people used it, you can read reviews of the application by and for blind people in AccessWorld and at AppleVis, an iOS blind user community. Last year, it was discontinued in favor of a commercial application that unfortunately doesn’t appear to use OSM.
Openrouteservice has a wheelchair routing profile with lots of fine-tuning options, but it’s somewhat obscure outside the OSM community. Wheelchair users especially rely on public transportation, so probably many are using popular transit planning applications like Citymapper, Moovit, and Transit. Public transportation agencies have deployed their own OpenTripPlanner instances in some metropolitan areas, most notably TriMet in Portland, Oregon. These multimodal routers use GTFS feeds for the bus and rail connections and OSM data for sidewalks and other wheelchair-accessible paths, ideally leading from the bus stop to the doorstep.
Apart from navigation and trip planning, transportation analysts and planners also use OSM data to plan improvements to a city’s pedestrian network. Pedestrian and cycling advocates similarly use OSM to propose safety improvements. Everything including roads, sidewalks, curbs, and POIs can be relevant to this kind of analysis. In my metropolitan area, the public transportation agency wanted to help us get sidewalks, bicycle lanes, and POIs into OSM so they could more easily evaluate options for bus routes and bus stop locations. Each city that the agency serves already had all this information, but it was siloed in many incompatible datasets, whereas OSM could federate these datasets together in a single database.
This is just scratching the surface, but hopefully it gives you an idea of the breadth of possibilities with accessibility-focused data in OSM.
@Minh_Nguyen: That’s really an excellent overview of accessibility initiatives, I really learned something new here.
Still, I sometimes do wonder the same thing as @Emilius123. I’d like to see more examples of people using OSM for accessibility, not applications using OSM for accessibility. That would give me confidence that these applications are actually meeting people’s needs and that people are using them every day, not just for a study or experiment.
If you’re looking for a testimonial from an end user, we should acknowledge that these are still early days for OSM in assistive technology, despite the many nascent efforts. Let’s start with the assumption that we aren’t needing the needs of people with disabilities, then solicit their stories about mobility in their lives, regardless of whether OSM is a part of it yet, to better understand the requirements. If you don’t know of anyone in your in-person social circles who can shed light, online forums like r/wheelchairs, r/Blind, and AppleVis could help.
From the limited interactions I’ve had so far locally, my impression is that the pedestrian router is only a part of the story. When Code for San José started working on mapping sidewalks several years ago, we were guided by a desire to improve pedestrian routing in a notoriously unwalkable, pedestrian-unfriendly environment. One of our volunteers was very excited about the potential for OSM to improve his mobility as a blind person. However, for him, it wasn’t just about using an OSM-powered navigation application directly.
He relies on the the local paratransit service to get around, because the local government has determined that bus and light rail services don’t meet his needs. (Paratransit service is designed for people with physical, visual, or cognitive disabilities. Buses make many accommodations for physical disabilities, but the routes don’t serve every neighborhood.) He calls a government hotline a day in advance to schedule and pay for a trip, then the next day they send someone in a minivan to pick him up within a half-hour window and take him to his destination. It’s less convenient than a taxi or private ride-sharing service, but it can be more affordable and the only option for people with specialized mobility needs.
He was satisfied with the paratransit service except for one thing: the driver’s navigation application frequently locates the pickup point imprecisely, presumably because of messy address data. He struggles to describe his location to the driver without being able to make eye contact. If the driver can’t find him standing at the curb within a few minutes, they could report him as a no-show. A pattern of no-shows could get him suspended from riding paratransit.
To be sure, he cares about the sidewalks and crosswalks. But it’s also important to him that OSM facilitate a credible alternative to the proprietary navigation solutions that were indirectly disadvantaging him and those with similar needs. Credibility has been an issue for OSM here in Google’s backyard. Despite our superior coverage of pedestrian infrastructure for wheelchair routing, the local public transportation agency (bus, light rail, and paratransit) couldn’t depend on OSM and Pelias for geocoding and ultimately abandoned its OpenTripPlanner router in favor of Google Maps.
After the sidewalk import, we’ve focused on improving coverage of addresses and POIs. A well-rounded map can be superior to a superficially accessibility-focused one if it’s adopted by the mobility services that people with disabilities depend on.
Of course, this is just one perspective and one use case in one locality. To get more perspectives, perhaps rephrasing the initial question can be a start: “What do you need to get around?”
In the DACH (Germany, Austria, Switzerland) region, there is Routago, a router aimed at visually impaired pedestrians. Though the software itself is proprietary, it uses openstreetmap data for navigation. They started as a university spin-off. Looking at the homepage now, seems they got some funding and features creep, now it talks of wheelchair and more, though Public transport is sorely missing.
The router uses sidewalks (those mapped as attributes) and highway crossings (those mapped as nodes), in order to suggest safe trips. It uses surface information too and can do plaza-navigation over pedestrian areas. Additionally they use the device camera for object recognition; so do not rely on GPS alone, something certainly just as much needed as in autonomous driving.
PS: The blind can get by with google-maps navigation quite fine. Some might even do so out of desire to state, that they are in no way less capable of roaming. Some may prefer the less chatty instructions. Getting back at the question: Yes, there are users for accessibility.
The University of Washington’s Taskar Center for Accessible Technology is working toward that goal. Currently they have AccessMap.io which allows people with limited mobility to manage Seattle’s steep hills. I just read a comment from Seattle visitor that found Access map helpful. Unfortunately I don’t know how well the tool is being used. But I believe it’s a good start.
I’m not quite sure I’m following this. Surely, people will always use some sort of application that uses OSM data? (at least I’ve never found any human memorizing .osm.bz2 XML dump and using that directly without any app ).
But I do have samo small experience with few blind friends who were using OSM POI data (like bus stops, pharmacies, etc.) in GPX format downloaded from (alas, nowadays defunct) POI Export. By the way, does anybody knows of working tool similar to it (here is one of the still working instances, but with obsolete data, if you care to see how it worked)?
Then they choose area and POI type they were interested in, and POIExport would give them .gpx file with that OSM data. Then they converted it to appropriate format via simple gpx2dotwalker online web tool I’ve written for them, and imported resulting file into an Dotwalker app, to use in help with navigation. They were happy with the result, but the biggest issue they quoted were low GPS precision in the city. (10m might not seem like a big deal for seeing person, but is much bigger issue for the blind).
Disclaimer: the sample of size of blind persons in example above was only two, and the last discussion I’ve had with them on the OSM subject was more than 5 years ago. We did chat about dual-band GPS smartphones more recently (and how much that might help with GPS precision).
“Citation needed”? At laest in the circles I’m familiar with, blind people are not using Google Maps, perhaps there is a reason for that. AFAIR, they were using Loadstone in the times past, and have afterwards moved to Dotwalker (on Android; I’m not sure what they use on iPhones).
People always use an application, but not all applications are used by people.
Some applications or data sets end up not getting used (much) because they fail to meet the needs of the intended target audience. I feel this is a particular risk in an accessibility context where many of the developers creating such applications, and many of the mappers adding accessibility information to OSM, are not themselves part of the target audience. Of course, this can be avoided with proper research and communications (as you did by basing your tool directly on your friends’ requirements).
This is why I’m interested in practical examples. Otherwise, I might map some stuff that I think is helpful for other people, but actually isn’t.
That was, what she said to me, when I asked her, which aid she uses on the phone in her hand. Later I did toy around with gm, it certainly has its warts, for anybody pedestrian, not just the blind: E.g. it routes along primary highways without sidewalks nor verges.
I want to thank folks for this discussion so far. It has motivated me to keep seeking out more real-world perspectives on how OSM can be useful for accessibility. I’m sure we’ve only scratched the surface.
Nothing compares to software created by people scratching their own itch. Back in my days triaging bug reports for a major vendor of programming software, I was very impressed at the skill with which blind people have managed to use this software, which was never designed with screen readers in mind, to create quite sophisticated applications, primarily but not exclusively for other blind users. I thought I was adept at keyboard navigation until I saw the screen recordings they sent in.
I’ve been trying to encourage some developers from the accessibility community to get more involved with the OSM community, since they’re already using OSM data in their applications. In the meantime, I’ll share some highlights from recent conversations I’ve had with local accessibility advocates, as food for thought.
One person who uses a wheelchair actually didn’t seem very impressed that we have some coverage of curb cuts. To them, at this point, curb cuts are infrastructure for the general population, so of course we would have curb cuts, right? They aren’t against collecting this information by any means, but it isn’t a game-changer for them. They’re much more excited about the possibility of collecting entrance doors on field surveys, noting their locations and dimensions. As it happens, this same information would also be a game-changer for other OSM users, such as delivery services.
I heard feedback that a binary wheelchair key is too simplistic, even ignoring the nuances about where to begin and end these tags. After all, a nominally ADA-compliant clothing store can still be difficult to navigate in a wheelchair, whereas a non-compliant store may have well-trained staff able to help a wheelchair user get through the narrow doorway of a fitting room. This gets into subjective criteria that would be difficult or undesirable to model in OSM, but I suppose we should view wheelchair=yes as a “necessary but not sufficient” indicator, requiring data consumers to integrate with an external resource for more reliable information.
A blind developer who worked on Audiom told me he envisions a navigation application providing guidance instructions for navigating two-dimensionally along a sidewalk. In other words, even sidewalks as ways are insufficient; he wants sidewalk polygons! When I participated in the San José sidewalk import, we discarded the city’s polygon information in favor of straight-skeleton linear features, out of concern that even those simplistic ways would be too controversial within the OSM community. I have a feeling we’ll revisit that decision someday.
Even though that granular level of positioning would be quite challenging with the current generation of mobile devices, the developer did have some ideas about how micromapped sidewalks would be practically useful today. OSM could collect information about the kind of surface that borders the sidewalk – grass, dirt, a wall – so that an application could tell the user what to expect when shorelining. Sidewalk areas would make it easier to determine whether a tree, bench, or signpost could pose an obstacle when traversing a narrow sidewalk.
Finally, the point is well taken that not every person with mobility needs has the same preferences. We shouldn’t even treat accessibility as a binary cutoff between able-bodied and disabled. Walking around downtown San José with my parents, we often approach an intersection and wait there even if we already have a walk signal. We’re waiting for the next walk interval to start so they have the whole interval to cross the intersection at a more relaxed pace. Eventually I’d like to map crosswalk durations, not so much so that a router can micromanage our daily walks, but rather as evidence to encourage the authorities to more fairly balance the needs of motorists and pedestrians.
I guess that would be country specific. In Croatia for example, even many cycleways (where one should take them for granted!) don’t have curbs, much less at all sidewalks. (and that is not the worst of it, we often have lighting poles, cafe seating, trash containers, illegally parked cars and bus stop shelters etc. in the middle of cycleways </rant>). In more organized countries/cities though, I can see that sidewalks and even curbs could be taken for granted…
That makes sense. StreetComplete wheelchair quests do ask about if wheelchair users can use that amenity/shop, and I’ve marked places with too small door (e.g. one person rotating door) as wheelchair=no . But still, maybe the explanation text there might be expanded to reiterate that “wheelchair accessible” doesn’t mean only “no steps”, but also “sufficient width”.
Perhaps, those polygons might’ve been conflated as center highway=footway lines, but with width=* tag specified? That would retain most of the data (assuming sidewalks with regular and constant size), without breaking all kinds of routing and other stuff (as marking them as polygons would).
Bigger issue seems to me that for polygon sidewalks to be usable imply (both at mapper side and at user side) something much more precise than GPS, due to its errors. Supposedly, Bluetooth beacons work quite a bit better (only 2-6m error), but are usually used only inside (likely it would be hugely impractical to plant and service them over whole city!). But that is still quite imprecise. And some kind of smart tactile_paving that communicates with the phone is probably still in the Sci-Fi realm (current “smart” tactile pavings seems to be oriented toward seeing but deaf persons).
Hm, maybe in some distant feature, when we have AI drones buzzing above our heads automatically re-mapping things on a hourly basis. (We don’t even have majority of sidewalks mapped at all down here, much leass sub-meter precision trees, benches etc!). Even more important, there are a lot of obstacles that appear and disappear from sidewalks all the time (trash and recycling containers, illegally parked cars, cafe chairs…). I don’t think I remember seeing one street on two different days when semi-static obstacles were placed in same order at same places…
Although I envision that much sooner we’ll have AI on our phones that could detect static and moving objects in front of the blind pedestrian (Tesla “Full Self Drive”-style) and navigate them that way (osim OSM-alike maps only for coarse/strategic planning to destination, and visual input for second-to-second tactical movement), or even Neuralink-alike tech linking camera output directly to the brain. Still, probably at least a decade or two away, and then there is period between working prototypes and mass-production…
Hehe, I’m just passing along some of the ideas I heard but don’t want to oversell them. The idea is more along the lines of a navigation application alerting the user that the sidewalk will have lots of obstacles in the block ahead, but not to do so in real time. Keeping the sidewalks clear is a challenge around here too. Illegally parked cars are one thing, but balancing the needs of pedestrians versus a homeless encampment is much less straightforward.
It’s important to remember that assistive technology is attempting to improve upon a very basic status quo. Even if these details don’t end up being very practical for real-time, step-by-step pedestrian navigation, there’s still the analysis use case that could inform policy decisions.
Accessibility isn’t all about wheelchairs and blind people. I’ve got relatives who use OSM for navigation because it shows more benches than anything else – when walking is a chore, knowing the next spot where you can sit down is very useful.
Absolutely, it’s not just about wheelchairs but also useful along with benches are step counts which is something I am only aware of existing in OSM.
In terms of accessibility of footpaths we also map whether there are stiles or gates, again important information for many and something only available from OSM.
Part of the accessibility data is used in the navigation software for the blind. We (OSMP) actively cooperate with the creators of this program
They use all the data, including the road grid, sidewalks and POI. In Poland, we have a program for marking public transport stops, so that it allows for integration with numbers used by transport companies and clearly indicates a specific point in OSM
If you want to know more, please ask specifically.