Allow selecting multiple genders for shop=hairdresser

[mnalis]

Description

Currently, for shop=hairdresser, iD allows selecting only one of the gender values male=*, female=* and unisex=*, i.e. UI control is radio-button.

That however presents a problem when users try to edit objects that have more than one value set - most commonly combination of male + female tags, especially due to unisex=* ambiguity/controversy documented on its wiki page and related iD issues (like related #895 and openstreetmap/iD#7427).

Request: It would be preferable if iD allowed entering all three gender keys (male, female, unisex) via checkboxes instead of radiobuttons

This is how most other popular editors do it (screenshots of JOSM and Vespucci attached). Current iD handling of that situation is very subtle, and unless user has display of raw tags displayed and uses that instead of user-friendly presets, is likely to result in unintended modification / retagging / data loss on edits. (see iD picture, in which iD would_ silently remove all gender tags except one that was selected via radio button_ if it were clicked on, regardless of their previous combinations/values)

Screenshots

[westnordost]

So both the original meaning of the tag and the meaning of "unisex" used by the common native speaker for restrooms is a restroom without segregation by sex. So unisex=yes implies that the restroom can be used both by men and women, i.e. it is not segregated by sex. The logical fallacy made in the design of this select field in iD has been that the reverse does not apply: If a restroom can be used both by men and women, it does not necessarily mean that it is a unisex restroom.

So, the implication above is for data consumers to make, not for editor software. i.e. data consumers wanting to find all restrooms that can be used by women will want to filter for unisex=yes or female=yes.

If I remember correctly, the current UI decision was rationalized by previous iD maintainers saying that ideally, there would be one amenity=toilet node for every sex when it is a segregated restroom. But this conflicts with reality, de-facto, this is not how restrooms are mapped in most cases.

[1ec5]

If I remember correctly, the current UI decision was rationalized by previous iD maintainers saying that ideally, there would be one amenity=toilet node for every sex when it is a segregated restroom. But this conflicts with reality, de-facto, this is not how restrooms are mapped in most cases.

There’s something to be said for this approach, but there’s nothing in the UI to guide the user to this realization, unlike with, say, sidewalks, in which the path of least resistance is currently to map a separate way. Not every native English speaker has a correct understanding of the term “unisex”, let alone non-native speakers.

But if I’m reading this ticket correctly, it’s actually about shop=hairdresser rather than amenity=toilets. Apparently the same gender field has been reused for both presets, as well as for amenity=shower and amenity=dressing_room. For some of these presets, there’s only one possible interpretation of the “Unisex” option, and it isn’t the one that would require each gender’s facility to be mapped separately. I’ve never heard of a “unisex hairdresser”; I think one that serves both men and women would just be a hairdresser for men and women.

[mnalis]

• for the topic of toilets; see the related issues iD template can't tag toilets for multiple genders? #895 and “When you gotta go, you gotta go”: A proposal for tagging preset for gender neutral toilets iD#7427 (where I agree that the same checkbox solution could be applied).
• this issue is primarily (quite related, but still somewhat different, as noted by @1ec5) for shop=hairdresser, outlining the issue that users do currently map multiple of those tags (male/female/unisex) at the same time, and that iD current UI is conductive to unsuspectingly damaging such tagging (while noting that other popular editors employ checkboxes to avoid such issue, so iD could employ that tactics too).
• whether such multi-key tagging is the best way to tag what hairstyles/services are offered, or if some other method would be preferable (like single-key unisex=yes or for=female would be better etc.) was intentionally beyond the scope of this issue (which is, again, primarily to protect against the damage to existing tagging methods).

[JesseWeinstein]

This might be better opened on the https://github.com/openstreetmap/id-tagging-schema repo, as the (one-line) change is to solve it is: https://github.com/openstreetmap/id-tagging-schema/blob/main/data/fields/gender.json#L2 "type" field from "radio" to "semiCombo".

[westnordost]

_{FYI an issue can be transferred within the same organization using this link on the right, let's leave it up to the maintainer whether or not it should be transferred to the other repo}

[mnalis]

Thanks for the hint @JesseWeinstein , but are you sure just changing that type from radio to semiCombo would work? Do you know of existing tagging that works in that way? (i.e.with multiple keys, instead of multiple values for one key separated by semicolons)

I've tried looking, but it seems that all occurrences I found that use semiCombo are one key + multiple values. (and here we have multiple keys male=*/female=*/unisex=* instead), which ends up looking/working like this (e.g. beauty.json:

And that doesn't seem like it would accomplish what we need for shop=hairdresser?

[bhousel]

I've tried looking, but it seems that all occurrences I found that use semiCombo are one key + multiple values. (and here we have multiple keys male=*/female=*/unisex=* instead), which ends up looking/working like this

yes! openstreetmap/iD#3954 is the issue that everyone here needs to read. Switching from a radio to a semiCombo won't fix the problem.

The accepted tagging for gendered things does not work like other multi valued tags in OSM.

Solution is either - need to wait for better tags to be proposed (which was where openstreetmap/iD#3954 left things), or replace the existing radiobutton gender field with a bunch of gender checkbox fields, or develop a new kind of special field that can manage all the different tags.

[mnalis]

Thanks @bhousel! That is how it seemed to me too, that one would need 3 separate checkboxes (male, female, unisex) which are tri-state (undef, yes, no). So it would look something like those tags:

Of course, it would look nicer if those 3 separate checkboxes could be grouped somehow together, but that would be just visual fluff (i.e. functionality would remain the same; but it would use less screen and look nicer). However, I wasn't able to find a tagging that works that way, and you confirm that such nicer layout not exist yet, so one would currently be fixed on using existing checkbox functionality like in screenshot above.

As an aside, disadvantage of UI like for recycling_type=container (mentioned in openstreetmap/iD#3954 (comment)) is that it does not distinguish between unsurveyed (not tagged) case (e.g. missing male=* tag), and explicitly tagged no case (e.g. male=no). Which works fine for recycling containers (because their wiki explicitly declares that non mentioned tag defaults to no) but does not really work for tags where it is not explicitly implied (like male, fuel:*, payment:* etc) and where in fact explicit female=no is even more important than explicit female=yes (not to mention untagged/unknown value when tag is missing altogether)

[tyrasd]

Fixed by switching the field to the manyCombo type

Currently, this does not display mapped no values (e.g. female=yes + male=no would be displayed the same as female=yes), nor does it allow to explicitly map no states in the UI. But this was also not possible before using the radio-button field.

I do plan to add support mapping of no values in iD in multiCombo/manyCombo fields, as this would also be useful in other scenarios.

[bhousel]

Fixed by switching the field to the manyCombo type

Hey that is great! I did not know about manyCombo.