The answer Anyone (which customers visit this hairdresser?) causes an Osmose error

[gitmuti]

The answer Anyone (which customers visit this hairdresser?) causes the Osmose error

Suspicious tag combination

Female=yes together with male=yes

Example node id 3835420173

How to Reproduce
Answer the question
which customers visit this hairdresser?
With
Anyone

Expected Behavior
No osmose error

Perhaps unisex=yes should be tagged instead?

Versions affected
SC v53.0

[Helium314]

See discussion in #4833 and #4829 for reasoning why unisex is not used.

Also keep in mind that osmose shows issues, which are not necessarily errors!

[gitmuti]

Thanks. Understood.
I don't get involved in gender issues.
As a result, my expectation is that there will be no osmose error shown.
I cannot judge where the issue should be resolved (in SC or in Osmose).

[westnordost]

in osmose

[mnalis]

Note that iD was recently fixed to tag male+female too instead of problematic unisex: openstreetmap/id-tagging-schema#894 (comment), so hopefully that should become less of a problem over time.

Hopefully osmose will follow (especially if someone like @gitmuti writes them an issue). And as always, use common sense, as it's wiki says:

Warning 1: Do not map for Osmose, keepright, etc. Only fix real errors which you understand and know how to improve correctly!!!
Yes, Osmose has some false positives, like any other validator. Systematic issues should be reported

[gitmuti]

Thanks to @mnalis for the info that iD plans to allow no values in multiCombo/manyCombo fields.

This would make female=no possible, for example.

Also, if I understand correctly, unisex for toilets is not the same as male + female.

But for hairdressers, unisex is equal to male + female.

I have thought about everything.

1. Have you ever thought of a situation where someone for a hairdressing salon has tagged e.g. male=no, which does not correspond to reality (any more), for whatever reason, e.g. by mistake, by the passage of time or by malice? The owner of the hairdressing salon notices this and tries to claim damages for loss of turnover and profit because certain customer groups, in this example male=no, have been inadvertently excluded.

2. The specification of unisex in the wiki is as follows_

' unisex=yes always means a gender-neutral facility. Gender segregated facilities (e.g. toilets) should be tagged female=yes + male=yes. Usage of the unisex=yes tag for gender segregated features contradicts with the general meaning of the term "unisex". '

Source: https://wiki.openstreetmap.org/wiki/Key:unisex

Because of the definition "unisex=yes always means a gender-neutral facility"
and if at the same time StreetComplete automatically converts Anyone to male&female,
then a hairdresser could possibly claim damages because non-binary people are implicitly excluded.

My understanding is that the current implementation in StreetComplete is not compatible with the specification in the wiki.

For me, the use of unisex in StreetComplete would be OK.
I interpret and understand Anyone=Unisex in all use cases (toilet, hairdresser, ...).
Only I would disagree with the sentence from the wiki "The use of the unisex=yes tag for gender-segregated features contradicts the general meaning of the term "unisex", because there can be unisex hairdressers with and without gender-segregated premises.

3. In addition, some of my general ideas are as follows:

• Use the KISS principle = Keep It Simple and Stupid.
• It should be self-explanatory.
• There should be one central point of term specification for all applications, and in my opinion that is the Wiki.
• The implementation should not be in conflict with the specification (here: in the wiki).
• The semantics of keys/tags should be the same everywhere (in all objects).

Therefore I find the following aspects problematic

1. The current implementation in StreetComplete IMHO does not match the specification in the wiki, regardless of what is specified and whether the specification is applicable or should be changed. IMHO the specification is leading, it is the golden source.

2. unisex has different meanings depending on the object (toilet, hairdresser), i.e. a semantic change.

3. The different meanings of unisex depending on the object are not self-explanatory.

4. If in StreetComplete Anyone is selected, it is not converted to unisex in the background, but automatically to male&female.
   This is a) a hidden functionality
   and b) the content in the StreetComplete application does not match the content in the database.

5. With the current implementation, there is a possible risk that in case of an incorrect tagging, there could be a starting point for damage claims; but how high the probability and the amount of the possible damage value is, I don't know.

Conclusions, suggestions and my personal takeaway:

• I don't think the whole issue in Wiki, iD and StreetComplete is mature yet. Well meant is not always well done.
• My intuitive understanding is that you should be able to click in StreetComplete as follows:
  Anyone -> unisex
  male -> male=yes
  female -> female=yes
  male and female can be clicked at the same time.
• I suggest to show an explanatory text for this question in StreetComplete, explaining the functionality and the automatic transformation, when you click on Anyone.
• I suggest not enabling this question by default in StreetComplete, because I think it is an expert question due to the complexity, including the automatic transformation.
• Personally, I will deactivate this question in StreetComplete for the time being, because the risk of usage is too great for me.
• I suggest you contact the people who feel responsible for the Wiki, iD and Osmose and coordinate; I will not do that.

No offence!

Thanks a lot for all your work!