Re: [Tagging] Help with new tags about wheelchair accessibility for On Wheels app

2023-05-04 Thread Jez Nicholson
Hi Robin,

Are you in communication with WheelApp? Obviously they don't have an
exclusive on wheelchair mapping, but they will have a lot of experience
with OSM accessibility tagging and might be able to help. There may be a
niche Discord channel or something about it.

- Jez

On Wed, 3 May 2023, 09:46 stevea,  wrote:

> Marc_marc, je suis sérieusement impressionné par vos efforts. Merci
> beaucoup!
> Marc_marc, I am seriously impressed with your efforts, many thanks!
>
> > On May 3, 2023, at 1:22 AM, Marc_marc  wrote:
> >
> > Hello,
> >
> > Le 02.05.23 à 17:34, ro...@onwheelsapp.com a écrit :
> >> We want to add these tags:
> 
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Help with new tags about wheelchair accessibility for On Wheels app

2023-05-03 Thread stevea
Marc_marc, je suis sérieusement impressionné par vos efforts. Merci beaucoup!
Marc_marc, I am seriously impressed with your efforts, many thanks!

> On May 3, 2023, at 1:22 AM, Marc_marc  wrote:
> 
> Hello,
> 
> Le 02.05.23 à 17:34, ro...@onwheelsapp.com a écrit :
>> We want to add these tags:



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Help with new tags about wheelchair accessibility for On Wheels app

2023-05-03 Thread Marc_marc

Hello,

Le 02.05.23 à 17:34, ro...@onwheelsapp.com a écrit :

We want to add these tags:


I find the list too big to digest in one go, so I'll note a few tags 
that seem clearly ok

and some tags that clearly don't seem ok
the others, between the 2, deserve in my opinion to be treated
out of this mass to avoid to avoid having too long discussions
on too many tags in a single subject, which may make it indigestible


  * entrance:ramp:wheelchair      (for a ramp at the
entrance)


I find this tag too specific: the ramp can often be used by old people, 
parents with a baby carriage, a person with difficulty walking or even 
by a person with no difficulty
there is the entrance:ramp tag which combined with wheelchair describes 
in my opinion the accessibility well without having to describe the same 
object with at least 4 different tags



  * parking:sensor_ID          (for the
ID of a IOT Communithings sensor in a parking place)


if it's the ref of something, use ref:*, maybe ref:parking:sensor_ID
or ref:sensor_ID on the amenity=parking
it would be very useful to make a documentation page on what it is,
how to get it, how a contributor who is not a wheelchair user can
detect it, so that there can be other users than those of your app


  * entrance:kerb:height    (for the
height of the kerb at the entrance)


ok (in meter or add unit for ex 5 cm)


  * entrance:door:width         (for the
door width of the entrance)


why not entrance:width ? (entrance without door exist,
for ex when the door itself is not at the building outer
but after an covered area
sometimes it's not a door but a bay, overspecific tag
seems uninteresting to me for the datause


  * entrance:step_count         (for the
number of steps at the entrance)


ok (i'm using it myself :) with entrance:step:height


  * entrance:turn_point          (for free
space to turn at both sides of the entrance)


if the space is not enought, isn't it better to put entrance:wheelchair=no?


  * atm:wheelchair          (for
wheelchair accessible yes or no)


ok but I prefer to create an object amenity=atm + wheelchair=*


  * reception_desk:wheelchair     (for wheelchair
accessible yes or no)


ok


  * toilets:wheelchair


no need to ask, it's an in use tag :)


  * toilets:wheelchair:accessible_by   (to indicate if a
wheelchair toilet is accessible by stairs, lift or groundfloor)


groundfloor -> level=0
I don't really understand the need to describe the pathway and above
all I fear that it will end up adding accessible_by everywhere (how 
accessible is the parking ? how accessible is the shop ? ) which on 
their own don't mean anything (toilets on the ground floor can be 
wheelchair=no, accessible_by=stairs can be wheelchair=yes if the 
staircase has a motorized wheelchair platform.



  * toilets:accessible_by    (to
indicate if a normal toilet is accessible by stairs, lift or
groundfloor)


same as before


  * toilets:wheelchair:space_side    (for the free space
on the side of the toilet)
  * toilets:wheelchair:space_front  (for the free space
in front of the toilet)


toilets:wheelchair is not sufficient ?
when does a user need to know all these details?
I would have thought that what interests him is to know if in
the end it is accessible or not or is the goal to make a detailed 
inventory of ok and not ok points?



  * toilets:wheelchair:handrails   (for the number
of handrails)


are you talking about a handrail like on the stairs
or a bar located in the toilet allowing you to lean on
to lift yourself between the chair and the toilet bowl?
I fear a confusion of terms when the toilet has a staircase
to get there. another term seems more appropriate to me


  * toilets:wheelchair:door_width   (for the door width
of the toilet)


toilets:wheelchair:door:width but as before, i don't
see the usecase

  * toilets:wheelchair:narrowest_point_from_entrance  
(to indicate the narrowest point from the entrance

to the toilet)


osm is a geospatial database, adding tags describing
the positioning between objects doesn't seem like a good
idea to me (in the past, some have added tags to describe
the nearest bus stop to a park, the nearest address to
a bike station,
it's potentially endless and without real added value,
even if it's indoor, nothing prevents you from doing a highway=path 
indoor=yes connecting the object to its door, while waiting

for an indoor mappinng


  * elevator:width   (for
the width of the elevator)
  * elevator:depth   (for
the depth of