[Tagging] Feature Proposal - RFC - Baby changing table

Paul Allen pla16021 at gmail.com
Mon Apr 22 12:20:23 UTC 2019

On Mon, 22 Apr 2019 at 00:50, marc marc <marc_marc_irc at hotmail.com> wrote:

> if the goal is to talk about accessibility, then use the wheelchair tag.

That just says if you can get a wheelchair into the toilet.

but if by measuring the height of the table, you think you have done
> what it's need to inform accessibility, you are wrong, this detail is
> almost anecdotal in accessibility.

No more anecdotal than anything else anybody maps.

> for all the others, no need to have a meter in your pocket,
> it's wheelchair=no, no need to fill heigh=1 or 1.05 or .95 except for 3D

And how about those with achondroplasia?

To be honest, I doubt many mappers would bother mapping the height and it's
probably not all that useful in most situations.  But the fact that
somebody here
suggested it means it is likely that somebody will decide to map the
height, in which
case let's decide how to do it now.

>     same thing for the description key, I can't imagine when it's useful
> to
> >     describe the table with words so I find it not very useful to
> promote it

Security through obscurity doesn't work.  As for promoting it or not, it
depends very much on
what editors offer in their presets.

the question is "can we expect to have changing tables on a regular
basis that are different from what we can expect with other tags,
> which would justify encouraging people to put a description ?

Actually, no.  It's can we expect it on an irregular basis.  Because
description is only rarely
necessary for anything.

access=* don't said anything about public view.
> changing tables in a private area does not mean that your child
> is protected from a public view (I know a changing table in
> the private part of the maternity just in front of a windows
> with a public corridor)
> a changing table in a public toilet can be in a room that
> is respectful of privacy.
> if you want to inform this kind of info, it's probably better
> to make another proposal for another key in stead of promoting
> to hijack the access key to talk about public view when using
> the feature.

I already suggested that in private mail  to Valor for other reasons.  The
developers of
some editors don't like re-using keys with a subset of values and remove
such usage from
presets.  If offering the full list of values doesn't make sense they
either have to hard-code the
exceptions or refuse to implement it in a preset, and these days it's
usually refusal.  And, as
you've pointed out, not only does the syntax differ (only a subset of
values make sense) so does
the semantics.  So changing_table:access would be better.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20190422/6da3eecd/attachment.html>

More information about the Tagging mailing list