[Tagging] Feature Proposal - Voting Open - toilets, toilets:disposal, pitlatrine

Andrew Chadwick (lists) a.t.chadwick+lists at gmail.com
Wed Jul 24 15:03:24 UTC 2013


On 24/07/13 14:14, Ronnie Soak wrote:
> While I can see your intention here, that is the most counter-intuitive
> way to tag this I've ever seen.
> You would tag a PUBLIC toilet with access=PRIVATE just because you have
> to ask for a key first?

Let's agree that permissive is probably more useful.  However it does
not carry any implicit "you must inquire" meaning, rather an "unless the
owner says no".

Perhaps a third axis is needed for this particular nuance. For a value,
maybe indicate what to ask for:

  access:request={permission|yes|key|code|...}

I'm not sure. It's more detail than my baked brain would be capable of
after a long summer day's mapping. Provided it doesn't mess with the
access tagging, it's probably OK. Hey,

   <access-key>=request           ; "no, though they'll listen"
   request={key|code|permission}  ; specifics of what to ask for

might be OK too, as a less restrictive "private" or "no" indicating what
to ask for.

Attempting to crowbar access=<new-stuff> in via a refinement of the
toilet tagging seems a bit of an abuse of the procedure some people seem
to love around here.  It should be proposed directly, in its own right,
since it affects such an important key.

[Either that or faffing with voting doesn't matter in the first place
and you should just use what you see fit and document what works]

> There is a subtle difference between enquiring for permission to
> enter/use and to inquire for the key/code/token.
> We won't tag access=private at all, because we only want public toilets
> to be in the database.

We tag private parking, so why not private outhouses if they're a useful
landmark to the public?

> So maybe we mean the same thing after all. The access restriction has
> nothing to do with inquiring for a code.
> I still think its more helpful to tell that you have to ask the staff
> instead of just saying it is locked with a code.

Fair enough.  I think it's best for this proposal to drop the additions
to the access scheme.  Those could be done later, and in the right way.

> I see your concerns about using the access key here. I'm fine with
> access=* having a different meaning depending on the main tag. We have
> that for other tags as well (type=* is probably the best example). But
> if others also see this problem, we better might move it to
> toilet::access to avoid confusion. Not all the access=* values make
> sense anyway. (access=hgv anyone?)

There's no such tag, but I get your drift. horse=no would be fairly
silly too.  I guess the correct access-key to use is "foot" then, not
"access"... (/old discussion)

type=* is horrendous garbage data that should be replaced on sight,
unless it's on a relation.  service=* is pretty nasty as well, but an
acceptable refinement for service roads.  We should do better than these
in new tagging for the sake of our data.  Namespaces are one honking
great idea - let's do more of those.

"According to the main tag" - sure, but how does a machine know which
one is the main tag?  I don't think it should be expected to.  Tags
should mean the same thing in all contexts to be of maximal use, and we
ought to make efforts to avoid or correct erroneous situations where
they don't.

-- 
Andrew Chadwick (although practicality beats purity)



More information about the Tagging mailing list