Proposal talk:Tag:amenity=toilets

Why shouldn't this be used for toilets not open to the public, they could easily be marked as such with the access tag? In Norway, f.ex. we have "summer farms" all over the mountains, these are on open access areas, usually with hiking trails through them, and will usually have pit latrines meant for the "farmers". So they are very much relevant to map, and they will often be open to the public if you are really needy so to speak, but they are private and not meant for the public.--Guttorm Flatabø (talk) 11:25, 15 July 2013 (UTC)

That's "access= permissive", already part of both existing use and the proposal. But do note a 'permissive' arrangement like the one above only keeps working as long as use is infrequent enough if hundreds of tourists visited each of the summer farm toilets, access would likely no longer be tollerated. Brycenesbitt (talk) 00:29, 20 July 2013 (UTC)

Private / public

It's worth documenting explicitly that "public" toilets means they are intended for use by the public. It does not imply that they are operated by a public body.

Some people might want to find a toilet, some people might want to find a cafe with a toilet. At present the "toilets=yes" tag is ambiguous ("this entity has a toilet", or "this entity has a toilet available to the public"). Despite what the wiki says the most common use in the UK is to indicate an amenity with toilets (almost always amenity=pub,toilets=yes). The implication is that the contributors intended usage is "I am looking for a pub with toilets" not "I am looking for a toilet".

With the increasing use of Community toilet schemes by local government (formal agreements that a private business will make their toilets available to the public) it would be useful to have something more explicit to indicate that a toilet associated with a different facility is intended to be available for public use: e.g. "toilet=public" rather than "toilet=yes".

Within the UK there are variations between the degree of public access to non-public toilets. All of the following are normally provided for customer use, but a degree of public access might be expected / accepted / tolerated in different circumstances: a public library / a museum / a railway station / a car park / a public house / a tea shop. I'm sure that a coding system could be devised to deal with the nuances. It probably doesn't matter what scheme is designed, because the chances of getting sufficient accurate coverage to make it useful to anybody is likely to be close to zero.

Meanwhile, for tagging documentation purposes, I'd suggest using "toilets=yes" to imply that there are toilets in the facility, which are not explicitly provided for use of the public. Leaving it up to users or application providers (not data contributors) to interpret the cultural differences between "toilet=yes" in a railway station and "toilet=yes" in a tea shop.

Please reconsider description of "toilets=yes"

To me it seems perfectly reasonable to discourage use of "toilets=yes" to record toilets that are only available to staff. The point when members of staff turn to OSM to find a toilet in their own workplace is probably some way off.

However, toilets that are available to customers are another matter, because a plausible application for OSM data is for users who want to find a particular amenity which has toilets available. "I fancy a cup of tea, but I need a toilet as well". or "I want to find a toilet pretty quickly, and I'm prepared to buy a coffee if necessary".

Adding "toilets=yes" is an intuitive way of recording cases like this. To date this is how contributors have used the tag in the UK (I only have access to a full dump for the UK, and taginfo doesn't seem to collect this data for the rest of the world). If this is how contributors do things intuitively then there is a lot to be said for going with the flow, because confusion about the meaning of "toilets=yes" will make the data ambiguous and unusable. There will be no reliable way of providing users with a list of public toilets because there will be no reliable way of identifying public toilets within another premises.

In principle the proposal to use "toilets=no" would address this issue, but in practice it involves handling a number of undocumented assumptions about where toilets might normally be expected, which seems fraught with difficulties.

A much simpler approach would be to document "toilets=yes" as meaning that toilets are available to the public, without describing the circumstances in which they can be used (by customers, or the general public). Contributors who do not know exactly what the expectations are, or who are unfamiliar with more advanced tagging schemes can still add useful data. The introduction of "toilets=public" to indicate that they are definitely available to the general public, would be an equivalent (functionally) to "amenity=toilets" and a simple way of tagging "Community toilets" that are explicitly marked for public access.

If there needs to be a way of tagging the nuances between different levels of access, then "access=*" (with appropriate namespaces) seems a perfectly reasonable way of doing this for the more adept contributors.

Documentation of the "toilets" attribute would then read something like :

"There is no standard way in OSM of tagging toilets that are only available to staff. Different amenities have different expectations about the circumstances in which members of the public can use their toilet facilities. Add "toilets=public" where the toilets are explicitly made available to the general public, and "toilets=yes" for cases where there may be some restrictions. Where the restrictions are known, then "toilets:access=*" can be used to describe these restrictions explicitly"

--Peter Reed (talk) 09:03, 21 July 2013 (UTC)

Why different schemes for toilets:position and male/female/unisex ?

I was wondering why the toilets:position tag is designed to be a ;-separated list while the male/female/unisex tags are yes/no? For each of these tags, toilets can have one or more valid values. I'm not arguing for either one of those solutions, I merely question if the difference in tagging is needed at this point. --Chaos99 (talk) 06:28, 24 July 2013 (UTC)

The male/female/unisex bit is asking for trouble. What would it mean if someone tagged "male=yes,unisex=yes"? What would it mean if "male=no,unisex=yes"? "female=yes,male=yes,unisex=no"? This is either not thought out well, or not documented well. --Frederik Ramm (talk) 07:16, 24 July 2013 (UTC)

I don't have any troubles with the meaning. I would tag "male=yes,unisex=yes" on toilets that have at least one door marked "male only" and at least one "unisex". "male=no,unisex=yes": No designated male and at least one designated unisex toilet. No information given on designated female toilets. "female=yes,male=yes,unisex=no": At least one male, one female and definitely no unisex toilet. I don't see a problem here, except that with a yes/no tag, more options will lead to tag-bloat (disabled=*, parent_and_child=*). If you accept the disadvantages that come with ;-separated lists, a toilet:designation (which may interfere with the wheelchair=* tag) or a toilet:gender (which maybe to narrow-focused) might be more intuitive. --Chaos99 (talk) 09:05, 24 July 2013 (UTC)

The male/female/unisex is drawn from the existing tagging and documentation, and was not changed as part of this proposal. Brycenesbitt (talk) 06:06, 7 August 2013 (UTC)