when there are male and female toilets in separate rooms, it seems clear we can unambiguously tag them with amenity=toilets + male=yes + female=yes + gender_segregated=yes
when there are gender-neutral toilets (i.e. all genders use same room), it also seems clear we can unambiguously tag them with amenity=toilets + unisex=yes + gender_segregated=no
However, what to tag if same toilets amenity have three rooms:
one male only,
one female only,
one gender-neutral?
Obviously we can micromap three different nodes (or areas):
one amenity=toilets + male=yes + female=no
one amenity=toilets + male=no + female=yes
one amenity=toilets + unisex=yes + gender_segregated=no
But what if we wanted[1] to keep it in one OSM element? There seems to be a conflict, because:
amenity=toilets + male=yes + female=yes + unisex=yes + gender_segregated=yes is wrong, because unisex toilet itself is not gender segregated, yet
amenity=toilets + male=yes + female=yes + unisex=yes + gender_segregated=no is also wrong, because female and male toilets are gender segregated
Similar problems can occur in many cases where a single element is used to map several things. If neitheryesnornois appropriate, maybe use gender_segregated=partial?
partial does not really add new information (compared to just leaving out gender_segregated=*). Perhaps it could be documented to have that specific meaning, but in that case better name (telling in itself) would be better choice, IMHO
it has not been used (nor documented), and at least StreetComplete wants to avoid introducing a new tags.
I don’t think it is necessarily wrong. If it said gender_segregated=only then it would be wrong, but =yes just means that there exists a gender segregated facility, not that the whole thing is gender segregated.
gender_segregated=yes/no lets a person know there is an option/no option for a gender-only bathroom, which may be important to that person (and also sometimes legally required).
This edge case can be covered with toilets:description. IMHO unisex is not necessary to use ever.
Another edge case is if the toilet stalls are separated, but the sink is one shared room. This can also just be covered with toilets:description.
Well, the wiki says “add gender_segregated=yes/no, depending on whether or not the feature is gender segregated” (the “feature” being amenity=toilets in our case).
So there is no accepted only value[1], but instead yes was meant to cover it (but it seems that this specific possibility[2] was never considered, thus the ambiguity).
And are “the toilets gender segregated” at that place? Well, some are (male and female) and some aren’t (gender-neutral). Is correct answer yes or no? Or neither?
Allegedly, it is more than 1% of all toilets in some places, so not insignificant.
Well, how would you then tag that case of three toilet rooms mapped on one amenity=toilets node: one male only, one female only, and one gender-neutral? I don’t see a way without using unisex (or micromapping).
BTW, just trying to outline potential issues to promote discussion; not trying to be come out as argumentative or preferring certain solution[3]
the fact that some other – unrelated – tags like diet:vegan have such only values, does not mean the same value can be applied or expected here ↩︎
separate room for males, separate for females, and separate for gender-neutral ↩︎
that’s why I didn’t even put my vote up there yet ↩︎
I would have said that amenity=toilets + male=yes + female=yes + unisex=yes is the best solution, but the wiki states that unisex=yes was previously used as a synonym for male=yes + female=yes.
gender_segregated=yes means that the toilets are separated by gender, which is not the case with a unisex toilet.
I think we need something new for:
“Toilets available only for gender A”=yes
“Toilets available only for gender B”=yes
“Toilets available only for gender C”=yes
…
“Toilets available for all”=yes
However, based on the existing data, I consider this an unlikely scenario. Therefore, I would say: at present, this can only be achieved through separate mapping.
With the disclaimer that I think the (male|female|unisex) paradigm has other issues, but ignoring that…
I think this is closest to ideal; however, because of this ambiguity until now,
is closest to reality. So, the question is really “What is the best way forward” - which I think is both that completely unambiguous mapping via separate elements for each bathroom is best, andamenity=toilets + male=yes + female=yes + unisex=yes + gender_segregated=yesif they are all being represented by a single object is the proper way going forward and should be documented as such on the Wiki.
Reading the wiki article in question, it looks like the only situation where this would apply is if unisex=yes is tagged on its own with no other clarifying tags. (The bugs in both iD and JOSM would have removed male=yes and female=yes from the affected objects.) Therefore, unisex=yes + male=yes + female=yes still seems to unambiguously indicate separate unisex toilets (particularly if combined with gender_segregated=yes).
toilets:position = seated;urinal probably doesn’t fully apply to the gender_segregated=yes + female=yes toilet we’re describing on this same object. Is this a problem, like unisex=yes + gender_segregated=yes on the same object supposedly is?
How does wheelchair=yes interact with the gender segregation tags on the same object? Do we get to invent more tags to resolve ambiguity?
I would probably just map the three-in-one case with a single OSM object with amenity=toilets + male=yes + female=yes + unisex=yes.
But if you wanted to be more precise, then how about: amenity=toilets + male=yes + female=yes + unisex=yes + gender_segregated=yes;no on the ground that there are both segregated and non-segregated options available?
The most common setup I’ve seen in my USA childhood for a three way split is a left/right/center decision point, where straight on is the “family bathroom” which is where the diaper changing table gets put, and has plenty of room for multiple people to navigate around each other.
I’d say it if there is one room that is female only and one room that is male only, then gender_segregated=yes applies. And if there is one room that is gender-neutral then unisex=yes applies. It would be a contradictory combination applied to a single room, but applied to a POI node representing an unspecified number of rooms the logical conclusion is that there must be at least three separate rooms. So this should be clear enough to communicate the situation and distinguish it from these two other situations:
gender_segregated=yes + unisex=no - There is a male only space. There is a female only space. There is not a shared unisex space.
gender_segregated=no + unisex=yes - There is neither a male only or a female only space. There is a shared unisex space.
This all makes sense for large public bathrooms/restrooms/toilets containing multiple individual stalls and a shared space for hand washing.
Where the meaning may get muddled is that sometimes public toilets are not shared spaces at all but rather a set of completely separate single occupancy, lockable rooms. Sometimes in this model all the rooms are labelled as gender neutral so it would seem that gender_segregated=no + unisex=yes would apply. But this situation is different than if there were one large gender neutral room shared by everyone. Each single occupancy room offers complete privacy for the person using it, so they will not be sharing space concurrently with another gender despite none of the rooms being designated as male or female. Some way to tag this difference would be good.
