> 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+).
That's actually very similar to mountable/semi-mountable/non-mountable or wheelchair=yes/limited/no and would lead to the same problems you described further above. If we want to prevent putting wheelchair users in categories, I think it's better to give the actual heights. On 7 January 2018 at 21:38, Nick Bolten <nbol...@gmail.com> wrote: >> 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 > _______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
