[Accessibility] Best way to map sidewalks ?

[lejun]

I approve of using HotOSM as it makes it possible to contribute from 
afar using aerial imagery. Contributing this way is limited by imagery 
freshness and surveys would be necessary by people in the area, 
especially regarding fine details such as kerbs height which is a 
necessity for wheelchair users.

What I think would be the quickest way to a functionnal scheme is to 
create a complete network. You’d need the sidewalks, the crossings and 
the kerbs heighs in between. If embraced by the community, only then it 
would be interesting to add informations like sidewalks width and 
kerb-barriers on a large scale to improve routing.

Le 18/01/2021 à 18:52, parker, anson D (adp6j) a écrit :
> Nick & Anat & Pierrick - this was a really helpful thread that got deep in to the details and got me to go re-examine charlottesville's data
> 
> https://opendata.charlottesville.org/datasets/pedestrian-sidewalk-area
> 
> and consider how that would go in to a routing mechanism...
> 
> and from that perspective the data looks awful... lots of broken lines... not useless, but not usable either
> 
> from the perspective of getting that data in to graphs though we could begin using https://tasks.hotosm.org/ and working with that data along with aerials to start cleaning that up and connecting the dots with proper metadata...
> 
> what are the other steps in the pipeline?
> 
> I am also reaching out to several friends who get around in wheelchairs and see whether we could use some tracking tools and something like movingpandas.org to start creating a database of ground-truth routes... something we can fact check against
> 
> thoughts?  ways to simplify or improve process welcome
> 
> 
> 
> ________________________________________
> From: Nick Bolten <nbolten at gmail.com>
> Sent: Sunday, January 17, 2021 4:55 PM
> To: pierrick pratter; Accessibility
> Subject: Re: [Accessibility] Best way to map sidewalks ?
> 
> Hi Perrick! This is Nick from OpenSidewalks. Hopefully I can make some things clearer!
> 
> I want to start out with a very short overview of the motivating data philosophy behind OpenSidewalks. Street maps, designed for cars, have been around for ages and seem to have trained us, as pedestrians, to accept very little information. We functionalize "these streets connect" into, "I can probably walk along it", even though we're often wrong. We put up with that wrongness and work around it, as there is no alternative that provides us with the information we actually want: get me from A to B without making me encounter something I don't want to deal with (a super busy street with no marked crossing or lights, a very steep hill for a wheelchair user, a dark alley in an unfamiliar city). For pedestrians with mobility impairments, including people who use wheelchairs of various types, crutches, canes, prosthetics, etc., this situation is more obvious because things that they don't want to (or can't) traverse pop up much more frequently. A steep hill. A path with too much cross-slope. A path without a bench for resting. A path with a tall raised curb going down to the street. A path that turns into stairs. These highlight the need for information that can be traversed as a graph, just like the street map can be - essentially, the ability to simulate traversal of the path. Along that path, these conditional barriers must be annotated so that algorithms can make decisions that reflect individuals' requirements: perhaps Alex, a manual wheelchair user, doesn't mind raised curbs of 5 centimeters at all, but Jamie, who is new to their wheelchair and has balancing concerns, must avoid them. We therefore need to know the curb height to account for these individuals and actually provide them with a map that reliably gives them correct information.
> 
> Now, OSM has traditionally mapped both street ways and pedestrian ways, but the pedestrian ways that got independently mapped were ones that diverged from the street geometry like paths through parks or hiking trails. Sidewalks, which tend to have geometries similar to their associated streets, were mapped as metadata on streets. This makes sense if your goal is to render sidewalk presence or count how many sidewalks a street has at a given position, but it is extraordinarily awkward for describing the actual traversal path as well as the graph structure itself: where pedestrian paths interface and decisions would get made by an algorithm. There are strategies for somewhat working around this (AccessMap uses 'sidewalkify', an efficient but not the first way to estimate sidewalk location(s) from street centerlines), but they are limited in how much they can ameliorate the problem. 'sidewalkify' can only estimate sidewalk locations, it cannot reliably estimate where crossings should be or what their kerb information should be. For example, AccessMap uses Seattle DOT data for part of its network extrapolation. Sidewalks, in particular, are mapped as attributes of streets (not too dissimilar to what we're discussing in OSM right now) with an offset distance in feet. We can estimate sidewalk locations *very roughly* from this data, but all the rest of the pipeline depends on a fairly sophisticated ETL pipeline that combines together many GIS, graph theoretic, and tabular data munging techniques. In Seattle, estimating the location of a curb ramps along a crossing requires exploiting a relational data schema that associates curb ramps with sidewalks, identifying metadata signifying the direction of sidewalk line continuation to know which street the curb ramp interfaces with, retaining associated street *and* sidewalk information of an extrapolated crossing line, and then doing some guesswork about where to put it along the crossing. This is actually a situation that has *superior* information to the 'sidewalks-as-metadata' schema and it's why we can uniquely identify curb interfaces, but it took the creation of several new and non-trivial algorithms and it's still far from perfect.
> 
> Fundamentally, the information we need to know for a reliable traversal is (1) what is the graph structure, where can pedestrians potentially go? and (2) what potential barriers or assistive infrastructure are encountered along a traversed path? With separate ways, these questions are mostly straightforward to answer: ways describe the geometry of traversal and when they share a node, these can be reinterpreted as a graph node for routing or analysis purposes, and attributes along a path can be added directly to a way as metadata (tags) or if they are very short, as a node along the path (a kerb, for example). With 'sidewalks-as-street-metadata', both of these data become very difficult to describe. A large chunk of the graph structure has been lost, either embedded in tags that have to be interpreted into graph structures or just missing entirely. The geometries are no longer accurate and whatever other map features they pass by become difficult to estimate. And the attributes are a nightmare: every time a sidewalk attribute changes (surface, kerb, presence, etc) on either side of a street, you have to split the street way. In addition, some attributes are just not amenable to street tagging, such as kerb interfaces (I will describe examples later on).
> 
>> Opensidewalk proposal is still in "draft" status since 2016 and has never been voted on
> 
> The OpenSidewalks data schema will be in draft for quite some time as the scale of the problem being tackled is very large. While this thread is just about sidewalks, OpenSidewalks is focused on the holistic mapping of all pedestrian ways as well as attributes of interest for all pedestrians, including people with disabilities.
> 
> Regarding our wiki proposals, we would like to have done more to push them forward, but we've also realized that we need to be strategic in how we move forward with helping to improve OSM data models that are often inadequate for asking basic pedestrian network questions like, "can I use a curb ramp to cross the street here?". It has not been particularly easy to communicate these issues and suggest improvements via the official channels, but we're optimistic that we can all come together to understand the issues and synthesize a data standard that results in better pedestrian data for everyone.
> 
>> and AccessMap.io doesn't seem to use OSM for sidewalk data
> 
> In AccessMap, all of Mount Vernon, WA comes from OpenStreetMap. We're currently building partnerships for wider mapping to finish what we consider to be a minimal pedestrian network (sidewalks, street crossings, curb interfaces) in multiple cities. Through fantastic efforts in San Jose, CA, for example, all of the sidewalks and crossings have been mapped, we just need to get curb interfaces finished to add that to AccessMap (and anyone else's tools).
> 
> Though we're definitely not the only people pushing forward this style of mapping! There are many cities that are nearly to San Jose's level throughout the planet through mostly (or entirely) independent efforts.
> 
>> I have compared the map of seattle and OSM and part of the city are mostly not mapped with sidewalks at all way there not even the crossing nodes, so the routing system seem to use a different DB
> 
> We've been treating Seattle itself as more of a testbed for mapping depth (lots of details) rather than breadth, though I've also personally mapped out about five large neighborhoods here. See Bellevue, WA for a more complete network mapped by multiple volunteers that is nearly ready for integration into services like AccessMap.
> 
>> The only drawback I see from sidewalks as metadata is geometry as parkings lanes have their tags ( https://wiki.openstreetmap.org/wiki/Key:parking:lane ) and kerb height can be added on the crossing node or on the road itself.
> 
> kerb height cannot be added for each separate curb via a crossing node without tortuous (and undocumented/hypothetical) tagging strategies and only in some cases. There are two curbs, one crossing node, and one or two linear features (the street). Let's look at some scenarios.
> 
> (1) One could imagine adding something like kerb:height:right=* and kerb:height:left=* to a crossing node. Aside from being very unintuitive to understand the meaning of these tags while mapping (only veteran and very careful mappers could ever discover this on their own and map it correctly), it depends on the street being a single way at that point. If there are actually two ways in opposite directions meeting at the crossing node, there is no longer any meaning to left or right. A given pedestrian may have more difficulty ascending or descending a raised curb of different heights, so this information is very important for us to include in accessible pedestrian routing. The difficulty of adding this kind of information to a crossing node schema will also continue for any property of the kerb interface: surface type, kerb type, the incline of a kerb ramp if present, etc.
> 
> (2) There may be more than one kerb interface at each side of a given crossing. For example, some curb ramps are placed several meters away from the path that extends directly across a marked crossing. So most pedestrians will likely continue straight up a higher, raised curb while pedestrians that need to use a curb ramp will take a slightly longer path with a much lower curb. Accounting for this in a single node would require some pretty crazy tagging schemas.
> 
> (3) Probably a lot of other scenarios that aren't coming to mind at the moment. By losing the geometry of a path we're forced to use kluges.
> 
> Now, I'll take some blame for this not being obvious. Our website does not go through all of the rationales for our specific choices, and it should, with examples.
> 
>> Routing system already exploit elevation data like Osmand without needing the tags on each way.
> 
> Absolutely, and this is useful. I would say that it is necessary but not sufficient to account for the steepness of pedestrian paths if we want to create accessibility maps. Hope that makes sense.
> 
>> (...) GetThere (...)
> 
> Routing for people with visual impairments is a complex and open problem - an active area of research (so is most pedestrian routing, really). There are not any examples that have "solved" this problem and definitely not by only referencing street information.
> 
>> (...) OpenRouteService (...)
> 
> ORS has made great improvements to their service for accessible pedestrian routing! But it is still limited by the inadequate schemas that have traditionally been mapped in OSM, which is not their fault - they're trying to build a route service that works for an entire continent of OSM data and pedestrian data in OSM is *spotty*. With a first impression, you might think that London is ideally mapped for OSR, but a closer look at the routes for a wheelchair user will have people going up raised curbs or down the middle of cobblestone streets with street traffic because the underlying data is incomplete. For a pedestrian that cannot handle those scenarios, this would be like opening up a car routing application and constantly running into unmapped dead ends. This is also why AccessMap does not service a ton of areas yet: we require that an area be audited for a core set information so that we know both the presence, absence, and type of sidewalks, crossings, and curb interfaces. Typically, OSM is mapped more haphazardly by motivated individuals, so we don't know where, e.g., someone forgot to map a single sidewalk in the middle of a city that's already 85% mapped for sidewalks.
> 
>> This way of mapping as to be thoroughly discussed, I didn't find any up to date talk with a lot a participant that ended with a voted proposal and I feel that it as not been thought in the way the OSM database is built, as sidewalks are part of a road like parkings lanes or even cycleways it is logical and easier to maintain than a whole cities with interconnected lanes.
> 
>> This is why I wanted to have feedback from associations, or even users themselves because I don't see this schema used anywhere else than some cities and our job as contributors is to keep the data as easy as possible ?
> 
> Absolutely, we should keep the schema as simple and maintainable as possible, but we always have to measure that against functional adequacy. Let's try looking at the other scenario: who is making effective use of the street-tagged sidewalk, crossing, and kerb information for accessibility-focused routing? Who has attempted to extend this schema for additional basic information like kerb heights, surfaces, multiple lanes (some street crossings have a pedestrian and bicycle lane), multiple kerb interfaces, and then actually *used* this information in a production application used by any significant number of people? My understanding is that such attempts are limited to small areas for one-off academic projects that shutter after a few years and they never quite bridge that gap. This is not a knock on those projects, because they're doing good work; they're pushing the schema right up to its functional limitations while doing useful studies.
> 
> Hope this makes our position a bit clearer, as well as the rationale behind why we promote the use of separate ways for pedestrian paths.
> 
> Best,
> 
> Nick
> 
> 
> On Sun, Jan 17, 2021 at 8:13 AM pierrick pratter via Accessibility <accessibility at openstreetmap.org<mailto:accessibility at openstreetmap.org>> wrote:
> Opensidewalk proposal is still in "draft" status since 2016 and has never been voted on and AccessMap.io doesn't seem to use OSM for sidewalk data, I have compared the map of seattle and OSM and part of the city are mostly not mapped with sidewalks at all way there not even the crossing nodes, so the routing system seem to use a different DB
> 
> The only drawback I see from sidewalks as metadata is geometry as parkings lanes have their tags ( https://wiki.openstreetmap.org/wiki/Key:parking:lane ) and kerb height can be added on the crossing node or on the road itself.
> 
> Routing system already exploit elevation data like Osmand without needing the tags on each way.
> 
> An app that I tried for visually impaired people is GetThere ( https://play.google.com/store/apps/details?id=com.LewLasher.getthere&hl=en_US&gl=US ), and it seems to base itself on the structure of the street (street-crossings and main street itself) to route it's users.
> 
> For wheelchairs I only found OpenRouteService ( https://maps.openrouteservice.org/ ) that works for Europe only and require to have everything mapped as a separate way, but it is not because OpenRouteService is built this way that the OSM community as to map this way.
> 
> This way of mapping as to be thoroughly discussed, I didn't find any up to date talk with a lot a participant that ended with a voted proposal and I feel that it as not been thought in the way the OSM database is built, as sidewalks are part of a road like parkings lanes or even cycleways it is logical and easier to maintain than a whole cities with interconnected lanes.
> 
> 
> This is why I wanted to have feedback from associations, or even users themselves because I don't see this schema used anywhere else than some cities and our job as contributors is to keep the data as easy as possible ?
> 
> Sent with ProtonMail Secure Email.
> 
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Sunday, January 17, 2021 8:01 AM, lejun <lejun at gmx.fr<mailto:lejun at gmx.fr>> wrote:
> 
>> Le 17/01/2021 à 01:55, Clifford Snow a écrit :
>>
>>> On Sat, Jan 16, 2021 at 10:49 AM pierrick pratter via Accessibility
>>> <accessibility at openstreetmap.org<mailto:accessibility at openstreetmap.org>
>>> mailto:accessibility at openstreetmap.org<mailto:accessibility at openstreetmap.org>> wrote:
>>> I'm confuse on the way to add sidewalk data in OSM, it seems that
>>> there is two distinct way of mapping them as they are complementary
>>> and one should not be wildly used over the other.
>>>
>>>      For me the logical and easier way (and maybe easier for routing
>>>      systems too) is to add the sidewalk tag on the road and if the
>>>      sidewalk differ or is blocked by a obstacle that is not meant to be
>>>      cross, I draw the sidewalk and tag it with footway=sidewalk but it
>>>      is rare as almost all sidewalk in my country (FR) are part of the road.
>>>
>>>      So I wanted to have feedback from day to day users of tools that use
>>>      each kind of mapping and also from developer of those tools, to know
>>>      in the end which way is the best.
>>>
>>>
>>> I started using the sidewalk as an attribute of the road method of
>>> adding sidewalks. When I learned from UW's Taskar Center for Accessible
>>> Technology that routing on sidewalks was difficult when the sidewalk was
>>> an attribute of the road, I switched to mapping sidewalks as separate
>>> objects. Now routers, those specifically built for sidewalks, can
>>> successfully find a suitable route for pedestrians. This is particularly
>>> helpful for those with limited mobility such as those in a wheelchair.
>>> You can learn more at opensidewalks.com<http://opensidewalks.com> http://opensidewalks.com, a
>>> website the university built to explain their strategy including
>>> recommendations for editing in OpenStreetMap. They have a demo router
>>> running at AccessMap.io for Seattle, WA. Seattle is a very hilly city
>>> that can be difficult to walk up hills even for the average person.
>>
>> One massive drawback to using the sidewalk tag on the associated highway
>> is, as stated in the wiki
>> (https://wiki.openstreetmap.org/wiki/Sidewalks), that you miss a lot of
>> potential information between the two such as parking_lane or even the
>> kerb which I consider to be essential to wheelchair users.
>>
>> Moreover, as a french user, a lot of cities change the sidewalk into
>> shared spaces like the « Voie verte » (FR:C115/116) which is a shared
>> space with cyclists and horses. The consensus seems to be a separate way
>> tagged as a path designated for pedestrians, bicycle (and horses).
>>
>> -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>>
>> Lejun - Groupe Local OpenStreetMap Bourgogne-Franche-Comté
>>
>> Accessibility mailing list
>> Accessibility at openstreetmap.org<mailto:Accessibility at openstreetmap.org>
>> https://lists.openstreetmap.org/listinfo/accessibility
>>
>> To unsubscribe from this mailing list send an empty email to accessibility-unsubscribe at openstreetmap.org<mailto:accessibility-unsubscribe at openstreetmap.org>
> 
> 
> 
> _______________________________________________
> Accessibility mailing list
> Accessibility at openstreetmap.org<mailto:Accessibility at openstreetmap.org>
> https://lists.openstreetmap.org/listinfo/accessibility
> 
> To unsubscribe from this mailing list send an empty email to accessibility-unsubscribe at openstreetmap.org<mailto:accessibility-unsubscribe at openstreetmap.org>
> _______________________________________________
> Accessibility mailing list
> Accessibility at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/accessibility
> 
> To unsubscribe from this mailing list send an empty email to accessibility-unsubscribe at openstreetmap.org
> 

-- 
Lejun - Groupe Local OpenStreetMap Bourgogne-Franche-Comté