> Even if only three out of four wheelchair users were satisfied with `mountable`, `semi-mountable` and `non-mountable` this would be a step forward, in my opinion.
I would wager that the fraction of wheelchair users covered would be a minority - there's a lot of diversity that tends to get lumped into just 'wheelchair accessible' and it's really not one-size-fits-all in any way. In order for two wheelchair users to have the same requirements and preferences, they'll need to sync up on all of these things: short-burst athleticism, endurance, average speed, age-related compounding factors, manual vs. electric chair, wheel traction, wheel width, wheel radius, chair width, side-to-side stability, comfort level with using streets and driveways, etc. Now think of any two random users: how likely are they to match on all of those categorizations? I'm going on a bit too long, but you get the idea. Most of those needs can be directly handled with just a few neutral, measurable, on-the-ground tags: kerb shape + height + width, footpath width + incline, surface tags, etc. And all users benefit from those tags - bicyclists will also appreciate surface and kerb tags, as will parents using strollers or people hauling luggage. And most of these tags are useful in an additive way: one is good, two is better, etc, etc, and can be queried to figure out where information is missing and turn it into quests like maproulette. Let's consider just one common situation: manual wheelchairs tend to have larger radius wheels than electric wheelchairs do, which, just due to physics, impacts how they handle displacements like curbs. The higher-radius wheels have an easier time of it due to the angle of approach + extra leverage (though the user can become tired doing curb after curb), and there are a lot of curbs right on the cusp of being doable by electric wheelchair users. Even just for this one common situation, we have to ignore wheelchair=yes, and probably a mountable/semi-mountable/unmountable tag, because what's actually dictating access is variation in the curb shape + height. Maybe there's a good middle ground: a kerb height ranking, in lieu of taking out a ruler and/or guessing a true kerb:height value. kerb:height=low/medium/high, with corresponding ranges in cm (0-3, 3-10, 10+). > Besides, I didn't think of these values to be a replacement for kerb:shape, but an addition. Ah, well I initially misunderstood. But I still think it's better to completely drop the idea of overarching 'wheelchair access' tags for pedestrian tagging, due to the concerns above. Wheelchair users need unambiguous information and we already have ambiguous info in wheelchair=yes and access=*. Fundamentally, everyone is trying to answer the question, 'can a wheelchair user traverse this line/point/area?', and while it's tempting to say 'yes' or 'no', the true answer representing the majority of users is, 'it depends', which is why we need tags that reflected neutral, measurable on-the-ground conditions. > However, if we want to make the current scheme more usable, it is necessary to also specify the angle of inclination for sloped kerbs (and maybe kerb ramps too). Compare the following two kerbs, which have the same shape, but a different level of accessibility (...) You're completely right. And while we have the incline=* tag, there's no standard for where or how to apply it to a curb interface. Do we tag the node itself, and what does it mean of kerb=raised has an incline value? If tagging a node with incline=*, how do we figure out the direction of the incline, and how much does it matter? Does a kerb=* node imply that a footway should be split, and the two ways it connects to should (ideally) have separate incline=* tags? I prefer that last option, personally. Plus, it would benefit from adding a separate curb ramp tag for a way: all of them should, ideally, have an incline=* value. Best, Nick On Sun, Jan 7, 2018 at 11:13 AM Selfish Seahorse <selfishseaho...@gmail.com> wrote: > Not, it's not ideal, you are right. It's just an idea to create some > order, because the current kerb scheme isn't ideal either. Even if > only three out of four wheelchair users were satisfied with > `mountable`, `semi-mountable` and `non-mountable` this would be a step > forward, in my opinion. Besides, I didn't think of these values to be > a replacement for kerb:shape, but an addition. > > However, if we want to make the current scheme more usable, it is > necessary to also specify the angle of inclination for sloped kerbs > (and maybe kerb ramps too). Compare the following two kerbs, which > have the same shape, but a different level of accessibility: > > <https://wiki.openstreetmap.org/wiki/File:Sloped_kerb.jpg> > <https://wiki.openstreetmap.org/wiki/File:Kerb-45deg.jpg> > > Regards > > On 7 January 2018 at 19:15, Nick Bolten <nbol...@gmail.com> wrote: > >> * `mountable`: mountable for wheelchairs and vehicles (...) > > > > While this may seem easier to tag on a first pass, it's not ideal, as > it's > > making a broad-brush executive decision about accessibility on behalf of > > others. I'm also not sure how it's different from wheelchair=yes/no > combined > > with access=* tags. Describing neutral on-the-ground conditions is > better, > > both for accessibility and general use by all mappers/data consumers. > > Examples: > > > > - Athletic manual wheelchair users can mount moderate-height raised > curbs. > > - Adventurous manual wheelchair users may want to use driveways as well, > > where it may not be intuitive to always map accessibility, but does make > > sense for a curb interface. > > - Most electric wheelchairs can't handle moderate-height raised curbs. > > - Souped-up electric wheelchairs can handle even fairly high curbs. > > - People with impaired stability may strongly prefer moderate-height > curbs, > > but don't care about the shape. > > - A white cane user may want to know whether to expect a certain curb > shape > > for navigational purposes. > > - What about `semi-mountable version 2`, curbs mountable by souped-up > > electric wheelchairs but not other vehicles? > > > > These users can all be accommodated by curb shape and height tags, and > most > > can be mostly-accommodated just with curb shape. This is also one of the > > reasons very few wheelchair maps exist: if you state 'here's the places > all > > wheelchairs can go' you'll get a lot of very different complaints, both > > about not having enough possible routes ('I don't care about curb ramps, > > just tell me where big displacements and driveways are') and also too > many > > ('I can't handle 8 cm displacements, and this rolled curb kept me from > > making my trip'). > > > > Best, > > > > Nick > > > > On Sun, Jan 7, 2018 at 9:15 AM Selfish Seahorse < > selfishseaho...@gmail.com> > > wrote: > >> > >> On 29 December 2017 at 01:41, Warin <61sundow...@gmail.com> wrote: > >> > kerb:shape=* would be better as it suggests what is to be tagged. > >> > >> Thus, `kerb=*` values could be replaced with: > >> > >> * `mountable`: mountable for wheelchairs and vehicles > >> * `semi-mountable`: not mountable for wheelchairs but mountable for > >> vehicles > >> * `non-mountable`: neither mountable for wheelchairs nor vehicles > >> > >> _______________________________________________ > >> Tagging mailing list > >> Tagging@openstreetmap.org > >> https://lists.openstreetmap.org/listinfo/tagging > > > > > > _______________________________________________ > > Tagging mailing list > > Tagging@openstreetmap.org > > https://lists.openstreetmap.org/listinfo/tagging > > > > _______________________________________________ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging >
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
