Re: [Tagging] Help with new tags about wheelchair

[Martin Koppenhoefer]

sent from a phone

> On 8 May 2023, at 10:39, Sebastian Felix Zappe  
> wrote:
> 
> For example, a door width or step count should be tagged on the node that 
> represents the entrance door, not the café PoI node inside the building (or 
> worse, the building polygon)


but this requires to connect the entrance to the poi. There are several ways to 
do it, mapping the shop as polygon and having the entrance as part of its 
outline is one, you could also rely merely on a common address (same 
housenumber on entrance and poi) where this is possible (entrance has its own 
housenumber), or have a relation to connect an entrance to a poi node, but 
while I agree that all of these would add more detail, they also add more 
complexity. My preferred ways would be same housenumber (or more specific 
address component) if possible, or the poi as a polygon solution (which also 
has additional benefits but expects that the mapper is able to estimate the 
extent and shape).

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

Re: [Tagging] Help with new tags about wheelchair

[Sebastian Felix Zappe]

Hi Robin,

Sebastian from Wheelmap here. :)

You're right, wheelchair=* is not enough, and what "accessible" means is 
different for everyone. It's cool you want to tag more things about 
PoIs! Wheelmap is going to display many more tags soon, as well. If we 
keep this organized, we can ensure both OnWheels, Wheelmap, and all the 
other clients stay interoperable.


Have you had a look at the existing accessibility tags in OSM already? 
From what I see, many of your proposed tags exist already:


- entrances: https://wiki.openstreetmap.org/wiki/Key:entrance
- doors: https://wiki.openstreetmap.org/wiki/Key:door
- parking: https://wiki.openstreetmap.org/wiki/Parking
- toilets: https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dtoilets
- elevators: https://wiki.openstreetmap.org/wiki/Tag:highway%3Delevator
- dimensions: https://wiki.openstreetmap.org/wiki/Key:width
- indoor: https://wiki.openstreetmap.org/wiki/Simple_Indoor_Tagging

I think the most important thing is: Ensure that the tags you mentioned 
are not added to *place-of-interest* nodes directly, but to their 
correct "fine-granular" entities in OSM. For example, a door width or 
step count should be tagged on the node that represents the entrance 
door, not the café PoI node inside the building (or worse, the building 
polygon).


Maybe it's best to keep discussions/proposals in the wiki (each 
discussion/proposal near the tag it belongs to) and leave a ping here 
whenever a new discussion happens. From what I see, big proposals with 
many tags at once tend to fail (see 
https://wiki.openstreetmap.org/wiki/Proposal:Healthcare_2.0), small 
proposals seem to work better.


You might also want to have a look at 
https://sozialhelden.github.io/a11yjson/describing-objects/interfaces/ 
from A11yJSON, which is our 'other' data format about physical 
accessibility. It might be a good inspiration source :)


All the best,
Sebastian Felix Zappe




OpenPGP_0xE9F6161AA0F8F0BD.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Help with new tags about wheelchair

[stevea]

On May 7, 2023, at 12:56 PM,   
wrote:
> What is the best way to make it more easy to discuss?

Hi Robin:  I'm one person in North America, about 14 years in OSM.  I helped my 
university and community in wheelchairs in OSM with a fair bit of wheelchair 
mapping / routing guidance.

Awesome, Simon:  important, historical, relevant.  Such coordination could be 
fruitful indeed.

Consider this:  such grouping happens in OSM's syntax (tagging) and its 
documentation, not the list.  Use this list to start a new thread (different 
Subject), worded with something precise and brief, like "Improvements to 
wheelchairs=*"  This could turn into a group of related tags (a syntax 
substructure, if you will, might include a tidy table or two of how the gears 
all fit together nicely) as a Proposal.  The Talk page of the Proposal might 
become a new medium of discussion, further discussion, et cetera.  But here, 
now, as you talk about it, it remains vague.  So, solidify it by pointing to 
something that says what it is as a clear presentation.  By "it" I mean what 
you call "a long list of new tags."  Put "it" into a bite-sized package and we 
chew.  Maybe I missed your pointer / reference to it, I didn't see it here.

I've seen this kind of development before and been a part of it, this happens.  
When it all/largely/mostly works it ends up as a result of a lot of patience, 
clear writing, real community-building and more:  tt takes time.  Not weeks, 
usually months, often years, especially as things evolve.  Some of the 
communication is necessarily many-to-many, some of it will sensibly be 
one-to-one.  This evolves.  It can be good to "gin up" (grassroots digging?) 
community support in organic ways.

> I make an email with all new tag suggestions organized into groups

Consider this:  pivot/segue from here to here (this tagging list, but a 
different thread), then "there" (away from this list altogether).  Lots of 
email not required except the near-term one that it takes to start (and take a 
lead in, as original poster) a new thread (topic, using a fresh Subject) and 
few emails it will take to continue this.  Introduce references, a sketch, 
white paper, etc., rough structure (ideas, concepts, outlines of 
Proposals...").  A Proposal becomes wiki...the community widely nod our heads 
(in all the wherever- and however- domains as we discuss it) and like a rocket 
ship it takes off.  Your new thread "best presents" your ideas (tags).  Go!

There are many ways to do this.  That's only one of them, it has worked and 
still does.  Whatever might be your improvements to and ideas for our data, 
stand it up as well-thought-through and introduce it.  Speaking for myself, I 
like well-formed, bite-sized packages (of such syntax presentations).  As you 
may stand it up and it is liked and heads nod, it gets stronger as a solid data 
structure we may rely upon.  I've seen this before and been a part of this, 
too.  It might be odd to be both a participant in OSM and at the same time "I 
have what might be great ideas" (for tagging wheelchair physical dimensions 
quite well, for example).  This is a peer-reviewed process (irregularly, that 
is with ephemerally-changing individuals) and may be intimidating.  I don't 
know you, though it seems you are both part of the community and have good 
ideas on how to improve OSM (and relevance to the subdomain).  And, we have 
your post here!  Let's see your syntax presentation. I listen.

Accompanying this is at least a kernel of documentation, I don't need to say 
more loudly; your presentation should speak for itself.  Maybe "things work" 
(measuring methodology, like Lidar) on a "wide variety of phones" (now) and 
that might influence how things are tagged...hard to say.

When and as we actually build OSM, OSM is strong.  Tag well.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Help with new tags about wheelchair

[Simon Poole]

Am 07.05.2023 um 21:56 schrieb ro...@onwheelsapp.com:


We have been in contact with Wheelmap. They are using the tag
wheelchair=yes/no, but with On Wheels we have a different approach.
We measure objective data about the entrance and toilet of a building.



Who did you talk to at Wheelmap?

Because that answer is not quite correct, back in 2016 and for a couple 
of years Wheelmap had a version of their Android app that ran on googles 
Tango (Augmented Reality) platform, and with that they were measuring 
entrance widths (both for toilets and entrances in general) and ramp 
inclines (something you don't include in your tag list BTW).


While they never ported that to ARCore, there might still be interest in 
starting collecting more detail again, given that it now seems to work 
passably on a wider range of phones. With other words I would suggest 
that you discuss at least their experience with collecting more details 
with them and coordinate.


Simon



OpenPGP_signature
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Help with new tags about wheelchair

[robin]

Hi everyone,

Thank you allready for all the input. Special thanks to Marc and Jez for
their suggestions and questions. I would like to clear up some things:

We have been in contact with Wheelmap. They are using the tag
wheelchair=yes/no, but with On Wheels we have a different approach.
We measure objective data about the entrance and toilet of a building.
Wheelchair users can set a personal profile in our app to indicate
what the dimension is of their wheelchair and the kerb height they can
cross. This way the user decides for themselves what accessible is.
Just adding a wheelchair=yes/no tag to an entrance or toilet is not enough.
Everyone wheelchair user has different dimensions and possibilities.
Even toilets and parking spaces that are marked as wheelchair accessible are
not accessible for everyone. We also believe that our data about
dimension of entrances, parking places, toilets and elevators could be
interesting for other applications.

We know it is a long list of new tags. What is the best way to make it more
easy to discuss? I make an email with all new tag suggestions organized
into groups (entrance, parking, toilet, elevator, ...) or an email per group
of tag questions. So one for entrance, one for toilet,  ?





Met vriendelijke groeten
 
Robin Julien
Operationeel verantwoordelijke, architect

ro...@onwheelsapp.com  tel: 0497 65 48 50









Message: 2
Date: Thu, 4 May 2023 10:31:56 +0100
From: Jez Nicholson 
To: "Tag discussion, strategy and related tools"

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

Content-Type: text/plain; charset="utf-8"

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

--

Message: 6
Date: Wed, 3 May 2023 10:22:46 +0200
From: Marc_marc 
To: tagging@openstreetmap.org
Subject: Re: [Tagging] Help with new tags about wheelchair
accessibility for On Wheels app
Message-ID: <3d8edb3d-e8f4-2a79-b33f-bf12759ba...@mailo.com>
Content-Type: text/plain; charset=UTF-8; format=flowed

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

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

[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

[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

[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 

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

[robin]

Hi everyone,

 

We are a non-profit organisation from Belgium working around wheelchair
accessibility. We collect accessibility data about buildings and provide
this info to wheelchair users with our free On Wheels app. To this point we
collected around 34 000 locations, mainly in Belgium. We are working on a
new app that will directly view data from OSM and also can add accessibility
data to existing locations. It is not an easy ride, but we believe that
accessibility data should be accessible as open data. We are using existing
tags as much as possible, but there are missing tags that we want to add to
OSM. We would like your input to find the best tags for everyone to use when
adding accessibility data in OSM. We want to add these tags:

 

*   entrance:ramp:wheelchair  (for a ramp at the
entrance)
*   parking:sensor_ID  (for the
ID of a IOT Communithings sensor in a parking place)
*   entrance:kerb:height(for the
height of the kerb at the entrance)
*   entrance:door:width (for the
door width of the entrance)
*   entrance:step_count (for the
number of steps at the entrance)
*   entrance:turn_point  (for free
space to turn at both sides of the entrance)
*   atm:wheelchair  (for
wheelchair accessible yes or no)
*   reception_desk:wheelchair (for wheelchair
accessible yes or no)
*   toilets:wheelchair:(for an
wheelchair accessible toilet)
*   toilets:wheelchair:accessible_by   (to indicate if a
wheelchair toilet is accessible by stairs, lift or groundfloor)
*   toilets:accessible_by(to
indicate if a normal toilet is accessible by stairs, lift or groundfloor)
*   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:handrails   (for the number
of handrails)
*   toilets:wheelchair:door_width   (for the door width
of the toilet)
*   toilets:wheelchair:narrowest_point_from_entrance
(to indicate the narrowest point from the entrance to the toilet)
*   elevator:width   (for
the width of the elevator)
*   elevator:depth   (for
the depth of the elevator)
*   elevator:door:width  (for the
door width of the elevator)
*   wheelchair:description(extra notes
about accessibility, used by Wheelmap)
*   amenity=changing_places   (for a changing
place: https://www.changing-places.org/)
*   changing_table:adult(for a
changing table for adults)
*   changing_table:adjustable_height(if the changing table
has an adjustable height)
*   changing_table:hoist(ceiling
track hoist for people) 

 

 

We know this is lot of new tags, but it is important to collect this data
for wheelchair users. Just adding the tag wheelchair yes or no is not
enough.

 

 

 

Yours sincerely

 

Robin Julien

COO, architect

 

  ro...@onwheelsapp.com
tel: 0497 65 48 50

 



 

 

 

 



-- 
Dit e-mailbericht is met Avast-antivirussoftware gecontroleerd op virussen.
www.avast.com___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging