“When you gotta go, you gotta go”: A proposal for tagging preset for gender neutral toilets

[amandasaurus]

I'd like to bring up the topic of gendered toilets, how they're tagged in OSM, and humbly suggest iD support the following tagging scheme, which I'm willing to offer to help implement.

There is a a tagging scheme in use for gender neutral toilets, which has for 4 mutually exclusive options for an amenity=toilets:

• Male & Female, separated: female=yes,male=yes,unisex=no
• All genders together: unisex=yes (with no male or female tags)
• Male only: male=yes,female=no,unisex=no
• Female only: female=yes,male=no,unisex=no

This supports the tagging of “gender neutral toilets” (as well single gender, and gender segregated toilets). A good UI for this would be a 4-option radio button. AFAIK iD (& JOSM) cannot support this tagging scheme as a preset (right?).

But this is something I'd like to see in the world, and I'm not a great javascript programmer, but I'm willing to try to implement this feature. I think we should promote this tagging scheme.

But before I spend time on this, I must ask advice. Is this a feature that (if implemented) you'd merge into iD? Is this feature request “well formed”? Have I forgotten anything? Is there some hidden cases which will make this impossible/very hard?

This feature might be used be other tagging schemes, but I don't know of any right now. (Clearly these scheme can be used as toilet:unisex=.../etc for amenity=restaurant/bar/pub/...).

To get specific, in order to implemented this, I suggest creating a new preset type of field 'multiKeyRadio', and this gender option would be stored like this:

{
  'type': 'multiKeyRadio',
  'label': 'Gender',
  'placeholder': 'Unknown/Other',
  'strings'

  'options': [
    {'id': 'male', tags: {'male': 'yes', 'female': 'no', 'unisex': 'no' } }.
    {'id': 'female': tags: {'male': 'no', 'female': 'yes', 'unisex': 'no' } },
    {'id': 'gender_segreated', tags: {'male': 'yes', 'female': 'yes', 'unisex': 'no' } },
    {'id': 'gender_neutral': tags: {'unisex': 'yes' }, 'removeKeys': ['male', 'female'] }
  ]
}

The important part is options, each gets a separate list entry. Each has an id (for it's id code), tags to mean "set these keys to these values", and removeKeys (default []), a list of keys to remove/unset.

When an OSM object is selected, if the tags set set to one option that radio button will be selected. If another combination of tags, then no option will be selected in the radio list. (e.g. if there is male=yes,female=no only).

So what do yous think? Should I try to start working on a PR for this? What feedback do yous have?

If someone else is skilled and able to do this, then that's great 🙂 But I'm willing to try to hack together some JS, if I'm sure there aren't any major flaws.

Related iD issues: #3954 (big issue with lots of comments) #2422 #5221 #6569 #7165

See also:

• OSM Wiki on unisex tag
• OSM Wiki on tagging gender neutral toilets
• A quarterly project was held to improve this data
• StreetComplete devs talk about this topic
• OpenStreetMap RefugeRestrooms/refugerestrooms#298
• Help OpenStreetMap make it easy to mark/find safe & accessible restrooms RefugeRestrooms/refugerestrooms#169
• LibreJS compatability  RefugeRestrooms/refugerestrooms#80

[todrobbins]

I'm glad to see you persisting on this topic @rory! Thanks for putting in the time and effort!

[bhousel]

AFAIK iD (& JOSM) cannot support this tagging scheme as a preset (right?).

Yes, #3954 goes into more detail about this. I'd also like to see more better tagging for gender neutral restrooms.

Given that neither iD nor JOSM can support the existing male/female/unisex tag scheme easily - don't you think that this might be a good reason to rethink the tagging instead of pushing forward with implementing a new UI control? I commented on #3954 with suggestions on how namespacing can help.

If you really do want a control, I'd prefer to just make a special toilet radio button control that sets the necessary tags, rather than a generalized "multiKeyRadio". We have implemented a few other special controls for things like Cycleway and Structure radio buttons, which can set a handful of tags at once, so it's a thing we do sometimes.

[amandasaurus]

I didn't know about the possibility of a special control. I'll look into that. JOSM can't support it (now) because I wanted to start with the larger editor, id. This male/female/unisex has bajillions of uses. To try to add a new tagging scheme just because the code doesn't exist now sounds like tagging for the preset system. 🙂 And doing it backwards

…

On 13 March 2020 17:14:44 CET, Bryan Housel ***@***.***> wrote: > AFAIK iD (& JOSM) cannot support this tagging scheme as a preset (right?). Yes, #3954 goes into more detail about this. I'd also like to see more better tagging for gender neutral restrooms. Given that neither iD nor JOSM can support the existing `male`/`female`/`unisex` tag scheme easily - don't you think that this might be a good reason to rethink the tagging instead of pushing forward with implementing a new UI control? I commented on #3954 with suggestions on how namespacing can help. If you really do want a control, I'd prefer to just make a special toilet radio button control that sets the necessary tags, rather than a generalized "multiKeyRadio". We have implemented a few other special controls for things like Cycleway and Structure radio buttons, which can set a handful of tags at once, so it's a thing we do sometimes. -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #7427 (comment)

-- Sent from my Android device with K-9 Mail. Please excuse my brevity.

[Elefant-aus-Wuppertal]

What is about the tag gender_segregated=yes/no? It is less used, yes, but it can solve the problem that unisex=yes/no wasn't clear in the past whether to use as a shortcut for both genders (just as payment:cash as shortcut for coins and notes) or to say that there is (no) gender segregation.

[amandasaurus]

What is about the tag gender_segregated=yes/no?

That also has the disadvantage of being nearly entirely unused, You could try to map this detail yourself to give it a boost?

[Elefant-aus-Wuppertal]

Yes I could. But please think of the tag traffic_signals=signal, which also was used nearly only in Helsinki before iD made it to the standard value for a highway=traffic_signals-node. It was the editor itself which gave this tag a boost. The same for many other tags. The thing is whether people assume the tag to be useful, because in iD the osm-wiki seems to have "not so much to say" anymore, but I know, the numbers of actual usages of a tag have...

[Elefant-aus-Wuppertal]

As the meaning of unisex=yes is not so much clear, male=yes/no and female=yes/no can be used just to say whether one of these genders has access at all (just like it is used for already). gender_segregated=no would say then, that it is a gender neutral toilet. For adding the tag gender_segregated, there have to be the tags male=yes and female=yes. It's just like the example that there has to be the tag internet_access=yes/wlan, for adding the tag internet_access:fee=yes/no.

[ZeLonewolf]

This is an important topic and highlights the need to use the proposal process to gain community consensus on the preferred tagging scheme. We should not be using the iD editor as a back-door way of avoiding that process.

[Elefant-aus-Wuppertal]

Well, yes, when we have someone who wants to go on with this process, I'd like it very much.

[tyrasd]

With #9656, iD is able to edit all of the mentioned possibilities from the original post, although in a slightly different way: by manually selecting/deselecting the individual options. While arguably being a little bit overkill and potentially overly complex for the toilets use case, this solution has the benefit of also being applicable to other tags with yes/no options (e.g. recycling.*=yes/no, payment:*=yes/no, etc.).