Proposal talk:Gender

This is the talk page for discussing improvements to the Proposal:Gender page and its related topics.
Please sign and date your posts by typing four tildes ~~~~ at end of your messages. Put new text under old text. Click here to start a new topic. New to OpenStreetMap? Take a look at the Beginners' guide. Respect your fellow mappers. Be gentle, constructive, and assume good faith.

Key names

Resolved: Proposal has been changed. Something B (talk) 16:21, 17 December 2022 (UTC)

It is possible replace gender:access:female=*, gender:access:male=*, gender:access:any=*, gender:target:female=*, gender:target:male=* with access:female=*, access:male=*, access:mixed_gender=*, target:female=*, target:male=* respectively? Something B (talk) 14:10, 13 October 2022 (UTC)

Relation to existing gender keys/values

Resolved: Proposal has been changed. Something B (talk) 16:21, 17 December 2022 (UTC)

I do not yet get the relation to existing keys and values like female=* of amenity=toilets.

1. Was a different naming chosen by intention?
2. Shall these be replaced by key "gender"?

--Schoschi (talk) 23:39, 27 September 2022 (UTC)

Yes it is. Something B (talk) 23:53, 27 September 2022 (UTC)

If that is the intention, it would be good to explicitly state in the proposal that it deprecates the existing keys. --Tordanik 15:31, 28 September 2022 (UTC)

Mappers won't mind? female=*, male=* and unisex=* is widely used. Something B (talk) 15:45, 28 September 2022 (UTC)

If there are good reasons and they are clearly communicated, I don't see a problem because we already did deprecate taggings that were heavily used – altough the transition often needs years, it happens. At the moment, in the proposal, I do only see a clear value add by deprecating & replacing unisex=* by gender=*, so this shall IMHO be mentioned in sections propsal and/or pages affected. For female=* and male=*, I don't see more benefit than reducing the amount of keys and avoiding two tagging schemes for the same thing, which is neither desired nor uncommon in OSM world. Hence, suggesting gender=* as preferred might get more acceptance than replacing, but I'm pro replacing. --Schoschi (talk) 22:29, 28 September 2022 (UTC)

How shall it be extended to further genders?

Resolved: Now, the propsal allows listing several values and explicitly suggests the alternative to create one OSM object for each gender, which in combination allows to solve this issue (one object gender=A;B and second object gender=C). --Schoschi (talk) 22:29, 28 September 2022 (UTC)

In some cultures, there are not only 2 genders, thus "segregated" does hit it's limit. How can the current approach be extended to tell "gender A and B allowed but not C"? --Schoschi (talk) 23:42, 27 September 2022 (UTC)

Possibly, but I don't know specific examples. Something B (talk) 23:50, 27 September 2022 (UTC)

https://en.wikipedia.org/wiki/Third_gender#Modern_societies_without_legal_recognition and https://en.wikipedia.org/wiki/Non-binary_gender#Legal_recognition list legal genfers beyond male/female. I would appreciate that a newly introduced gender key is able to encompass these, at the one hand because OSM shall be applicable world-wide, at the other hand to avoid changing the tagging and need to re-tag in forseeable future. --Schoschi (talk) 09:34, 28 September 2022 (UTC)

The proposed tagging scheme can easily accommodate other values for gender=*. The only case where it would break is if in a society with 3 or more genders there are places where certain genders are allowed (more than 1 though) and others not. For example, a place that allows genders A and B, but not gender C. I'm not an expert in this matter, but I expect that these cases are so extremely rare that they can be neglected. --Martianfreeloader (talk) 16:47, 28 September 2022 (UTC)

I'm no expert on this matter, too, and also expect such cases to be rare. Moreover, current state of proposal allows a clean solution. --Schoschi (talk) 22:29, 28 September 2022 (UTC)

@Something B: I advise to explicitly mention this in the proposal. In the Tagging section, an additional bullet point could say:

• Other genders can be added as needed by introducing new values for gender=*. To avoid conflicts, please introduce the new key in the discussion page prior to adding it.

Accordingly, add a line in the table saying something similar. --Martianfreeloader (talk) 09:51, 2 October 2022 (UTC)

Avoid binary language

Resolved: The proposal now does not any more mention "both" or the like. --Schoschi (talk) 22:29, 28 September 2022 (UTC)

I like the proposal, but please avoid binary language wherever possible. both can easily be replaced by all, any, unisex, mixed, depending on the context. As these words do neither imply nor deny gender binarity, hopefully all sides can be happy with them. ---Martianfreeloader (talk) 07:54, 28 September 2022 (UTC)

This proposal does not contain gender=both. Something B (talk) 09:36, 28 September 2022 (UTC)

It contains "both genders" :-) --Schoschi (talk) 09:39, 28 September 2022 (UTC)

Separate mapping of segregated facilities

Resolved: The proposal now explicitly mentions seperate OSM objects are OK. --Schoschi (talk) 22:29, 28 September 2022 (UTC)

You mention an example of "Gender segregated toilets" that assumes these are mapped as a single element. However, with increasing level of detail (e.g. in floor plans/indoor mapping), these are often mapped as separate elements. I assume that would still be ok with your proposal, i.e. gender=female could be used on the female-only section of a gender-segregated facility? --Tordanik 15:28, 28 September 2022 (UTC)

Yes, of course! Something B (talk) 15:30, 28 September 2022 (UTC)

Suggestion to improve the tagging scheme

Resolved: The proposal now explicitly distinguishes between any and unisex. --Schoschi (talk) 22:29, 28 September 2022 (UTC)

I think for situations where it is known that there is no gender-segregation, gender=unisex would be clearer to understand than gender=any. Furthermore, this would free the gender=any tag for places with access for all genders but where the mapper does not know whether there is a segregation. I propose to slightly modify the tagging scheme to this:

Access	Segregation	Tagging
All genders	unknown	gender=any
All genders	yes	gender=segregated (or create separate OSM objects for each gender)
All genders	no	gender=unisex
All genders	yes and no	gender=segregated + unisex=yes
Males only	--	gender=male
Females only	--	gender=female

Some places have both gendered facilities and unisex facilities. For these cases gender=segregated + unisex=yes could be used as shown in the table. This would imply to give the unisex=* key a clear definition. The wiki page would need to be re-written accordingly; which probably doesn't hurt as it is currently lacking a clear defintion.

--Martianfreeloader (talk) 16:41, 28 September 2022 (UTC)

Thanks! Something B (talk) 21:45, 28 September 2022 (UTC)

Can we get rid of male/female keys if accepted?

Resolved: resolved above

I would hope so. I seems to me that the tagging scheme gets accepted, all situations can be caught using only one key ({Key|gender}}); in some cases with an additional unisex=* (see my suggestion above). We could thus get rid of gender-specific keys like male=*, female=* and any other potential future gender-specific keys. In my opinion, this is a big advantage. --Martianfreeloader (talk) 16:52, 28 September 2022 (UTC)

Does it make sense to merge this into talk topic "Relation to existing gender keys/values" or is is clearly different? :-) --Schoschi (talk) 22:29, 28 September 2022 (UTC)

Yes, certainly. Sorry. :-) --Martianfreeloader (talk) 09:22, 2 October 2022 (UTC)

Definition

Resolved: adopted in proposal

Problem

I like the proposal, but I the definition sounds inaccurate to me. I'm not a native English speaker, so help me if I'm wrong!

To me, gender designation of the facility would mean that the facility has a gender. Clearly, something else is meant.

--Martianfreeloader (talk) 09:41, 2 October 2022 (UTC)

Considerations

When trying to find a clear and concise definition, we should bear in mind that the proposed key actually defines 2 different things at a time:

1. Which genders have access?
2. Are genders separated?

--Martianfreeloader (talk) 09:41, 2 October 2022 (UTC)

Solution

As a starting point, I suggest:

Definition: Gender access and gender segregation

--Martianfreeloader (talk) 09:41, 2 October 2022 (UTC)

Lists

Resolved: Proposal has been changed. Something B (talk) 16:21, 17 December 2022 (UTC)

I suggest to explicitly state in the proposal that lists are allowed.

• In the Tagging section say "Colon-separated lists can be used as appropriate."
• In the Examples section, show examples of lists:
  • gender=segregated;unisex: All genders allowed. Both segregated and unisex facilities exist.
  • gender=unisex;female: All genders allowed. Segregated facilities for females exist. Males (and other genders) allowed but not segregated.

--Martianfreeloader (talk) 09:58, 2 October 2022 (UTC)

I oppose this. Semi-colon multivalue is a retrogradation from separate k= male=* and female=*. This is less structured and organized. Other possibilities eg *=only (or *:others=no) and *=separate are lost. Talk:Key:gender segregated has suggestion for gender_segregated=by_identity. If having more gender option is a problem, you can prefix gender:*=*.
Using the syntax to mean there are additional dedicated facilities conflicts with the usual meaning of all are allowed.
--- Kovposch (talk) 10:38, 2 October 2022 (UTC)

"Using the syntax to mean there are additional dedicated facilities conflicts with the usual meaning of all are allowed.". Do you mean in the case of gender=unisex;female? If so, then I disagree. gender=unisex means all genders are allowed. gender=female means females are allowed and segregated. I don't see a conflict. --Martianfreeloader (talk) 11:11, 2 October 2022 (UTC)

Concerning "retrogradation from separate k= male=* and female=*": Can you name an example situation which the proposed tagging scheme can't cover? --Martianfreeloader (talk) 11:11, 2 October 2022 (UTC)

I also oppose multivalue lists. It's not that the scheme isn't flexible enough, but that it is confusing and will be misinterpreted by mappers and consumers. I think it's a lot clearer to tag each separately. So for the two examples from above perhaps something like

• Both gender-segregated and gender-neutral facilities: gender:segregated=yes and gender:any=yes
• Segregated facilities for females only: gender:female=designated and gender:any=yes

This less open to misinterpretation and follows patterns established for tagging other features. Ellehan (talk) 23:20, 7 October 2022 (UTC)

See Talk:Proposed_features/Gender#Gender_namespace -- Ellehan (talk) 23:55, 7 October 2022 (UTC)

@Something B: I wouldn't immediately change the proposal each time somebody throws in some comment. Replacing gender=male by male=yes and thereby reviving all the gender-specific-keys doesn't make any sense to me. It make the proposal inconsistent. And the whole point of the proposal was to get rid of female=*, male=*, unisex=*, wasn't it? Just because somebody drops a comment doesn't always mean their opinion should be adopted unquestioned. :-) --Martianfreeloader (talk) 17:51, 8 October 2022 (UTC)

@Ellehan: the point of the proposal is to get rid of an evergrowing, undocumented, unapproved numbers of keys. Instead, a finite number of keys (namely 1: gender) should be used. Common values are female, male, segregated, mixed, any. If a need for other genders emerges in the future, these can simply be added as values of the gender key, not as new keys. --Martianfreeloader (talk) 17:54, 8 October 2022 (UTC)

@Martianfreeloader IMHO, separate keys is not a problem. But one key(gender=*) is also fine. I am willing to change proposal back to previous version. Something B (talk) 18:06, 8 October 2022 (UTC)

I don't agree with claims that multiple values are confusing or not flexible. Values may be interpreted as binary flags. Presense is "true", absence is "false". For example, female-only section either present, or not present. Third varint is impossible. Something B (talk) 09:45, 20 October 2022 (UTC)

I propose:

• For segregated facilities, use gender:segregated=yes
• For female/male only facilities, gender:segregated=female/male
• For unisex/mixed facilities, gender:any=yes
• For combined facilities, gender:any=yes & gender:segregated=yes/female/male
• For gender-targeted services (not access), provide:for=female/male (it is allows drop female=* and male=*.

Only two keys for access. Opinions? Something B (talk) 00:54, 9 October 2022 (UTC)

I think this looks Great! I'd suggest modification: use (and explicitly mention) pre-existing tag provided_for=female/male instead of provide:for=female/male. --Ellehan (talk) 22:32, 9 October 2022 (UTC)

There's also a page for provided_for:*=* (a key prefix rather than the key itself) with several gender-related and non-gender-related subkeys. It's meant to replace the social_facility:for=* and community_centre:for=* keys, which fits into "gender-targeted services", but it definitely goes against the goal of reducing the number of keys. Should we also propose to deprecate provided_for:*=* (and probably social_facility:for=* and community_centre:for=*) in favor of provided_for=*? Either way it's probably a good idea to mention in the "Features/pages affected" section. --Ellehan (talk) 02:24, 10 October 2022 (UTC)

The obsolescence of these keys is not the purpose of this proposal. But this idea sounds good. Something B (talk) 08:45, 10 October 2022 (UTC)

@Something B: is there a reason you changed all of the tags in the proposal to provided_for:*=*? I thought we'd agreed above to use gender:segregated=yes/male/female and gender:any=yes/no for access and use provided_for=male/female/etc (or something along those lines) for services. --Ellehan (talk) 01:45, 11 October 2022 (UTC)

I changed proposal back. Something B (talk) 09:27, 11 October 2022 (UTC)

Combination with privacy=*

Resolved: Out of scope. Something B (talk) 14:19, 19 December 2022 (UTC)

I think it should be mentioned somewhere that gender=segregated or gender=unisex do not make a statement about segregation of individuals. This is tagged using privacy=* (if approved). The privacy=* tag might also be listed in a useful combination box of the final wiki page if the proposal gets approved. --Martianfreeloader (talk) 10:12, 3 October 2022 (UTC)

Sex/gender distinction

Resolved: For purposes of this proposal, it is the same. Something B (talk) 16:14, 23 May 2023 (UTC)

I have always been puzzled by the widespread use of unisex in instances where actually "gender-neutral" or "all-gender" is meant. To my understanding, it blurs the distinction between gender and sex. Am I wrong? If not, should we perhaps replace gender=unisex by gender=mixed? --Martianfreeloader (talk) 09:32, 4 October 2022 (UTC)

Single person feature (as on example photo) may be "mixed"? If answer is "yes", You can make changes to the proposal. Something B (talk) 22:51, 4 October 2022 (UTC)

I think yes. But I'm not sure if other mappers agree, so I've asked them on the mailing list. --Martianfreeloader (talk) 11:18, 5 October 2022 (UTC)

Gender and sex are categories in their own right. I'd prefer, if these are not treated as synonyms. In my area, when the sauna is open for both women and men (by sex), it is called mixed, not unisex. Still I'd have no problems to get, what sex=unisex meant in a sauna timetable, because it is in use for toilets. Otherwise, I now the term Unisex only from garments. I have not the least idea, what any of this has to to with gender. --Hungerburg (talk) 22:45, 6 October 2022 (UTC)

I fully agree. Let's use mixed. I would not use neutral (as is currently the case in the proposal), because neutral means something different. --Martianfreeloader (talk) 08:35, 7 October 2022 (UTC)

I'm a native english speaker, and I'm puzzled by your puzzlement. 🤣 Let me assure you (and other non-native speakers) that in English, “unisex” means “all genders together” / “mixed genders” / “gender neutral”. 🙂 Amᵃᵖanda (talk) 18:03, 10 October 2022 (UTC)

I'm also a native English speaker and I've had to look up "unisex" many times because I find it confusing 😅 --Ellehan (talk) 23:56, 11 October 2022 (UTC)

Sex or gender?

Resolved: Exact policy is very difficult to map. Something B (talk) 16:14, 23 May 2023 (UTC)

(as the above section does not actually address this, here is new one...) Does this proposal take into account actual differences of sex vs. gender ? Or should this be sex:*=* instead? (i.e. how does it takes into account transgender/non-binary/... people and similar issues mentioned in that link? IOW, "I identify as...." vs. "my physical sexual primary/secondary characteristics"?

E.g. if it is gender:segregated=female, is it acceptable for someone with a penis and a mustache to walk in and use the facilities? I forsee many cultural differences and possible cuplrits here; and how those should be handled should be decided and clearly documented before we decide to throw effort into replacing one lacking tagging scheme for another lacking tagging scheme. --mnalis (talk) 11:13, 10 October 2022 (UTC)

Typically segregation based on anatomical sex, but exact policis may differ. This proposal is about presence or absence segregation, not about exact policy, because it is very difficult to map. Something B (talk) 11:31, 10 October 2022 (UTC)

It is possible to replace gender:segregated=yes/female/male and gender:any=yes for single_sex=yes/female/male and mixed_sex=yes, respectively. Opinions? Something B (talk) 12:02, 10 October 2022 (UTC)

I don't think sex vs. gender is a relevant distinction here. Many places which segregate (or not) treat sex and gender the same, either by law, their custom, or their policies. I'm not aware of any place which would actually make this distinction. Amᵃᵖanda (talk) 17:58, 10 October 2022 (UTC)

I think it's best to stick with gender=male/female/any and gender:*=* and not invoke sex at all to avoid litigating differences between the two concepts. Both are typically culturally-defined and it's exceedingly rare to actually go into detail beyond male/female in a way that can be observed by a mapper on the ground. gender:segregated=* and gender:any=* are clear enough to map based solely on the typical signage, while not being so specific that they're confusing. --Ellehan (talk) 01:39, 11 October 2022 (UTC)

Gender of the object vs. gender of the visitor

Resolved: Added a section of the gender wikipage.

In some rare cases, mappers may be tempted to tag the gender of the object, for example in cases of statues or sculptures of people (example) or deities (example). This will create conflicts with tagging access restriction by gender of the visitors. Does it make sense to address this in the proposal? A solution like statue:gender=* could be conceived. --Martianfreeloader (talk) 09:43, 4 October 2022 (UTC)

It is make sense for actual documentation (Key:gender)). Something B (talk) 23:04, 4 October 2022 (UTC)

Done. --Martianfreeloader (talk) 11:34, 5 October 2022 (UTC)

Alternative tagging

Resolved: Proposal has been changed. Something B (talk) 16:21, 17 December 2022 (UTC)

• provided_for:female=yes, provided_for:male=yes - services provided for females or males respectively, no segregation or access restrictions;
• provided_for:female=separate or provided_for:male=separate - single sex space;
• provided_for:female=separate and provided_for:male=separate - sex segregated facility;
• provided_for:all_genders=yes - mixed gender, gender neutral facility
• provided_for:all_genders=yes and provided_for:female=separate and provided_for:male=separate - both segregated and mixed sections, rooms, etc;
• provided_for:female=separate and provided_for:all_genders=yes - mixed gender with female-only section. Opinions? Something B (talk) 14:09, 10 October 2022 (UTC)

I think it's best to stick with gender=*, gender:segregated=*, and gender:any=* for access and provided_for=* for services. It's clearer, it's closer to the existing system of male=* and female=*, and IMO it's simpler. I also think it's best to avoid creating new keys if possible (through the use of provided_for:*=* subkeys), since that makes mapping more complicated and it creates additional work for data consumers. --Ellehan (talk) 01:58, 11 October 2022 (UTC)

Differentiating between access and services using gender=* and provided_for=* might be confusing to mappers and cause unmaintainable mistakes. For access restrictions we have the intuitve access=*.

The wording "provided for" seems awkward to me. A shop=hairdresser is not provided to anybody unless the shop is offered for new ownership. servicing:=* would make more sense to me. But since this tag under discussion is designed around genders, I think it is most intuitve to use gender=*, or gender_serviced=* if one feels strongly about the service aspect.

What is the use of "separate" or "segregated" tags? I would argue that those POIs would best be separate OSM elements as they are physically separated in the first place, e.g by acccess paths, different entrances, walls, etc. I suggest keeping things simple and ituitive and using

* gender(_serviced):all=yes - if all genders are welcome, if an POI cannot be tagged with "yes", then genders that are welcome must be explicitely defined.

* gender(_serviced):divers=no/only/yes

* gender(_serviced):female=no/only/yes

* gender(_serviced):male=no/only/yes

* gender(_serviced):trans_female_to_male=no/only/yes

* gender(_serviced):trans_male_to_female=no/only/yes

* gender(_serviced):*=no/only/yes - any other gender relevant for a particular POI

on separate OSM elements where an actual segragation is present.

--Freetz (talk) 03:57, 11 October 2022 (UTC)

gender(_serviced)=* might be overly restritive though. A hairdresser specializing in male haircuts would wrongly be tagged gender_serviced:male=only if they gave a male-style haircut to other genders - which they usally would do. shop=hairdresser + gender_serviced:all=yes + hairdresser:masculine_style=only probably would be correct for most hairdressers focussing on male haircuts.

--Freetz (talk) 04:49, 11 October 2022 (UTC)

provided_for=* are about target group, gender:segregated=* about restrictions. access=* is simply irrelevant. Something B (talk) 10:17, 11 October 2022 (UTC)

Why do you think access=* is irrelevant to tag gender access (restrictions)? What would be wrong with access:gender:male=no etc.? It would be easy to understand what this tag describes with little room for misunderstanding.

--Freetz (talk) 02:08, 12 October 2022 (UTC)

Also this scheme mandates usage separate elements for segregated sections - it is makes mapping more complicated in simple cases. provided_for=* and gender:segregated=* may be used together, but is unnecessary. If semantics of provided_for=* are confusing, it may be replaced with service_for=*. Something B (talk) 10:39, 11 October 2022 (UTC)

The scheme with service_for:female=yes/separate, service_for:male=yes/separate or service_for:any_gender=yes still working, but it requires more keys than gender:segregated=yes/female/male. In other hand, it is more flexible, e.g leisure=sauna & service_for:female=yes;separate@(Mo) - mixed sauna generally, "damensauna" on Mondays. Something B (talk) 13:09, 11 October 2022 (UTC)

leisure=sauna & service_for:female=yes;separate@(Mo) for a female-only "damensauna" seems illogical to me. This would need to be service_for:female=only@(Mo) as there is nothing what the "damensauna" is separated from, it even is in the same location in this case where other genders meet on other days. A single service/provided_for:*=separate generally makes little sense to me, and I feel like it is being adhered too much on the word separation/segregation even where it doesn't really apply.

In the case of a "damensauna", restricting the service to females rather than the access sounds odd to me. Clearly the access to the sauna is restricted. (Further, a sauna isn't really a service nor offering a service, it is a location.)

--Freetz (talk) 02:40, 12 October 2022 (UTC)

Is there a reason to create the tag service_for=* rather than to approve the existing provided_for=*? --Ellehan (talk) 00:33, 12 October 2022 (UTC)

"Provided for" makes little sense to me. A service might be provided for someone, but a shop etc? Sounds awkward to me.

But more importantly: what is the reason for avoiding the terminology "gender" in the name of the tag that is supposed to describe "Gender access and gender segregation."?
If "gender" is the scope of this tag, I think it should be in its name. If not, it get's too confusing to map and to process data. provided_for=* already lists a bunch of different, non-gender subkeys, and it is unclear why this wouldn't be used for e.g. dogs or employees. A tag with a not clearly limited and intuitively recognizable scope will become a nightmare to use eventually.

--Freetz (talk) 01:54, 12 October 2022 (UTC)

“gender(_serviced):trans_female_to_male=no/only/yes” (etc.) is very bad wording. Don't do it like that. Plus, I'm confident there are nearly zero places which need this cis/trans separation in tagging. Amᵃᵖanda (talk) 16:27, 11 October 2022 (UTC)

It would be helpful if you explained what exactly and perhaps "why" this is bad wording in your opinion. Not being able to acknowledge particular rules in OSM for non-cis genders, where they exist on the ground, seems not very inclusive to me. I believe OSM should be neutral and map what's on the ground without personal ideologies. If there is a amenity=nightclub or a healthcare amenity that is only open for trans-identifying humans it should be possible to rightfully tag it as such. Also, it should be possible to tag amenity=bar that posts on the door that trans people are not welcome. This is very useful information.

It would not stay in business very long --Trigpoint (talk) 14:13, 19 December 2022 (UTC)

Of course, non-cis tags, as well as cis tags, should only be used where rules are explicitly stated on the ground. A binary toilet with signs for females and males should not include any other tags than gender:female=yes+gender:male=yes as nothing is posted about other genders.

--Freetz (talk) 03:07, 12 October 2022 (UTC)

(i) “trans_male_to_female” is unclear. When people say “trans male” they mean someone who was assigned female at birth, and is (now) male, and is transgender. People might say “female to male (transgender)” for people like that. What does “trans male to female” mean?

(ii) A trans man is a man. So gender:male=no applies to this person too. This tagging scheme results in a trans man being included in 2 categories.

(I suspect the author intended “male” only applied to cis males. To imply that trans men aren't “real” men (and instead are some different “female-to-male trans person”) is (i) false and (ii) promotes the idea that trans people's genders aren't real.

(iii) I'm pretty sure it's _very_ rare to get places that only allow trans people in, this would hardly be used.

Amᵃᵖanda (talk) 13:00, 12 October 2022 (UTC)

(i) MtF and FtM are well established terminologies, even within the TG community. I don't see what could be unclear; instead of just crititzing, coming up with a better suggestion would be more productive.

(ii) Your personal bias and expectation is grounds for your suspicion, or even accusation :( Nowhere did I write that. Nowhere did I make any judgement about gender. I'm suggesting to map what is on the ground. It is not a problem relevant to OSM that a transman might fall into both male and trans categories. If a restroom is designated to "women", to "♀", or to an inconified femine person, that would simply be "female" in this context with no tag for transwomen. Like in the real world, there is no statement about what is defined as "female" and what not. That's what I mean by "any other gender relevant for a particular POI". Mapping what's on the ground, not personal opinions.

(iii) Yes, it will not be the most used tag on OSM. There might not be any such place on your radar in your neighborhood, but such places do exist elsewhere. Are you suggesting to suppress them?

--Freetz (talk) 15:14, 12 October 2022 (UTC)

yes, “FtM” and “trans male” are common terms (and not exactly the same) (likewise “MtF” & “trans female”). “trans male to female” is not common. If you read the first 2 words, it means a trans male (“FtM”) person, if you read the last 3 words, it means the oppositeⁱˢʰ, a trans female (“MtF”) person! TBH you seem to not know a lot about this topic, so I think you should leave this aspect to the people who know a lot. Amᵃᵖanda (talk) 15:52, 12 October 2022 (UTC)

Thanks for the explanation of your interpretion, I see what you say. I neither meant trans-male to female nor trans male-to-female. I had "transgender (FtM)" and "transgender (MtF)" in mind, but parentheses don't do well in OSM tag names, AFAIK.

--Freetz (talk) 05:27, 13 October 2022 (UTC)

typo in meaning of `gender:segregated=yes`?

Resolved: Not actual anymore. Something B (talk) 14:23, 19 December 2022 (UTC)

It's probably a typo, but the current version says “gender:segregated=yes - any gender without segregation. For example, unisex toilet(s)” and “gender:segregated=yes - segregated by sex facility” Amᵃᵖanda (talk) 17:14, 10 October 2022 (UTC)

gender:segregated=* and/or gender:any=*?

Resolved: Not applicable anymore. Something B (talk) 14:25, 19 December 2022 (UTC)

I'm unclear what happens if something is tagged gender:segregated=* and gender:any=*. e.g. what if something is tagged gender:any=yes,gender:segregated=no? I think the meaning of some of these combinations should be defined. Amᵃᵖanda (talk) 18:22, 10 October 2022 (UTC)

gender:segregated=yes & gender:any=yes - defined.

gender:any=* & gender:segregated=no - the same as gender:any=*. Something B (talk) 18:55, 10 October 2022 (UTC)

Clarify different tags for access versus service provision

Resolved: Proposal has been changed. Something B (talk) 16:21, 17 December 2022 (UTC)

This has been discussed elsewhere on this page, but I wanted to make a separate topic for clarity. We are currently proposing to tag gender-based access restrictions with gender=* or gender:segregated/any=* and services provided based on gender with provided_for=*. This is a reasonable distinction in my opinion, because gendered services don't necessarily have restricted access. For example, a shop that sells shoes to men would still allow women, though a restroom for men does not.

I'd like to suggest adding subsections to the proposal as follows

Gender-based access restrictions

Primarily for facilities with access restrictions like toilets, showers, dressing rooms, etc.

• gender:segregated=* etc.

The current proposal any_gender=yes & gender_use=female_only;male_only;mixed - All genders allowed. Both segregated and mixed facilities exist is confusing. To me, only excludes other use, and this schemes seems not intuitively understandable as separated use. gender:use=separated/shared (default)/separated_or_shared (if need be).

--Freetz (talk) 16:44, 16 October 2022 (UTC)

Gender-based services

Primarily for services that may not have access restrictions, such as hairdressers, doctors, social services, clothing stores, etc.

• provided_for=* etc.

--Ellehan (talk) 00:52, 12 October 2022 (UTC)

I suggest using access:gender:all/female/male/etc=yes/no/only(/unknown) for gender-based access restrictions and gender:all/etc=yes/no/only(/unknown) for gender-implied services and products. --Freetz (talk) 03:24, 12 October 2022 (UTC)

I think that access:gender:all=* and gender:all=* may be confused, because "access" prefix is optional, see Conditional restrictions. service_for:all=yes for service without access restrictions, or service_for:all=separate/alone is more clear. But this scheme requires more keys. Something B (talk) 13:58, 12 October 2022 (UTC)

Good point with optional. Yet what speaks against including "gender" in the tag name in some way? "service for" is too generic, to unspecific and too unclear what the scope is, IMO.

--Freetz (talk) 15:30, 12 October 2022 (UTC)

Maybe gender:for:female=yes/only for services or goods, and gender:access:female=yes/alone/only for access? Something B (talk) 15:39, 12 October 2022 (UTC)

I like this much better! So how about the following scheme and conventions?

* gender:access:all=yes if a place is not desginated (and not restricted) for any specific gender or if designated for all genders; implies gender:use=shared; cannot be combined with any other gender:access:*=* since any gender:access:*=yes list would somewhat define/interpret what "all genders" means.

* gender:access:all=no is invalid

* gender:access:female=yes + gender:access:male=yes + gender:use=shared, if a shared-use place is explicitely designated binary for females and males. (Place does not acknowledge other genders, so it does not qualify for gender:access:all=yes)

* gender:access:female=yes + gender:access:male=yes + gender:use=separated, where separate spaces for both females and males exist

* gender:access:*=no may only be used where access is explicitely disallowed on the ground, no interpretation by the mapper

* gender:access:*=only, if only designated for one specific gender; cannot be combined with any other gender:access:*=yes/only; cannot be combined with gender:use=*

* gender:use=separated requires at least two gender:access:*=yes tags; cannot be combined with gender:access:all=yes; cannot be combined with gender:access:*=only

* gender:use=shared requires at least two gender:access:*=yes tags, or gender:access:all=yes (however this is superfluous since shared use is already implied)

I'm still struggling a little with gender:for:*=*, since gender:for:*=only could easily be mistaken as an access restriction, or exclusion from service.
Any alternatives to "for"? gender:intent:*=yes? Probably without "only" or "no"?

--Freetz (talk) 03:49, 13 October 2022 (UTC)

This scheme requires more keys. As alternative, gender:access:female=only - female only, gender:access:male=only - male only, gender:access:female=separate & gender:male=separate - segregated, gender:access:female=separate & gender:access:any=yes mixed with female-only section, gender:access:any=yes - mixed Something B (talk) 09:08, 13 October 2022 (UTC)

gender:use=separated/shared is an alternative to the already proposed {{tag|gender:segregated}|no/yes}, just nicer wording. gender:access:*=separate sounds like there are separated ways to get into the POI, it is not directly implying to me that there are seperate use areas in the place.

--Freetz (talk) 14:36, 13 October 2022 (UTC)

Proposal has been changed. Current version contains female=separate and male=separate. Something B (talk) 14:54, 13 October 2022 (UTC)

So far, I like the format gender:access:*=*, gender:intent:*=* and gender:use=* best.

(i) I think the namespace "gender" should be part of all tags in this context, it also highlights that this is a new tagging scheme.

(ii) I think gender:intent:*=* is better than gender:target:*=*. While the clothes in a female boutique may be made for females, I think it is wrong to say in general that the target group of the shop (i.e. the customers) are females. Hm, let's use gender:scope:*=* instead.

(iii) Yes, gender:use=* is an addtional tag. What's wrong with that though? Something in the form of access=separate not only adds the potential misunderstanding that access and not use is separated, it also implies more complicated parsing. If a data consumer is not interested in gender separation, they can simply ignore gender:use=*, whereas in the case of gender:access:*=separate, they always have to check for "separate" and interpret "separate" as "yes". To save tags, one could define that gender:use=shared is the default unless specified different.

(iv) I don't like mixed_gender. It's not very clear to me whether this refers to a single person with non-binary anatomy or to multiple individuals of different genders. I would much more prefer "all", or "any".

--Freetz (talk) 05:01, 14 October 2022 (UTC)

Clothes shops

Resolved: Out of scope. Something B (talk) 14:11, 19 December 2022 (UTC)

A clothes shop may specialise in clothes accepted for male or female, but that is never an access tag. --Trigpoint (talk) 13:48, 19 December 2022 (UTC)

For clothes shops clothes:for=* exist. Something B (talk) 14:11, 19 December 2022 (UTC)

Also see Key:for Something B (talk) 10:51, 3 January 2023 (UTC)

Do we really need to differentiate access from service (scope)?
(i) A boy is allowed in a female restroom with his mother, so gender:access:female=only is technically wrong.
(ii) For a shop=clothes, there is no need for gender:scope:female=only because clothes=women exists.
(ii) If a particular physician accepts only females as patients, what is the relevance whether access or service is female-only?
What are realistic and relevant uses of access vs scope?
--Freetz (talk) 05:22, 14 October 2022 (UTC)

(i) For small children rules may be relaxed.

(ii) clothes=underwear & for_gender:female=yes?

(iii) If men can entry - service. Something B (talk) 22:29, 14 October 2022 (UTC)

(i) Using conditionals?

(ii) Traditionally, that would be clothes=women;underwear. There is also clothes:for=* already, which makes a little more sense to me than for_gender=* since it is explicitly clear what the context of the gender is. But I still prefer clothes=men;underwear.

(iii) I mean, what difference does it make if a physician restricts access or service? Is any m/f couple going to search on OSM for a physician that only accepts women for patients but where she can bring her male partner? Or is any non-female person looking a waiting room in a female-only practice where they can warm up in the winter? Is female delivery person denied access to a male-only dentist? What are the scenarios where difference between access and service is relevant to OSM (and is verifiable on the ground)? And easy to understand for mappers to ensure good quality?

(iv) We don't tag age restrictions for access (not even for "service" or sales) in liquor stores as this is implied by local laws. Why would we need to tag gender:access=* on a toilet?

Is there anything we miss, if we only have something like for_gender:*=* (let's optimize the wording later) for POIs that are gender-specific in use (toilets, public baths, etc, ), and leaving the kinds of products and services to special tags of the respective POI where gender is any aspect, as in clothes=men for example?

Maybe it's not clear to me yet what problem this proposal is supposed to solve. Gender-separated use, the terminology of unisex, access restrictions, service limitations and product descriptions?

--Freetz (talk) 18:19, 15 October 2022 (UTC)

"What are the scenarios where difference between access and service is relevant to OSM (and is verifiable on the ground)? And easy to understand for mappers to ensure good quality?" Toilets, for example. Gender-segregated beaches also exists. Something B (talk) 10:49, 3 January 2023 (UTC)

(i) exact rules may be undefined, therefore not mappable

(ii) clothes=women;underwear literally says "clothes for women and underwear sells there" - it may include a plain clothes for women or underwear for men.

(iii) typically restrictions on entry applies only toilets and changing rooms, but it exists. AFAIK, in North Carolina (US state) special law against usage toilets for opposite sex (but I am not read statute and not knowing details). Even without law, objections from other customers may arise.

(iv) min_age=* exist. But usage of this tag is mapper`s choice, anyway.

Gender-based access restrictions may be dropped from proposal. They exists in this world, but I agree that difference between "access" and "usage" may be irrelevant. Something B (talk) 19:28, 15 October 2022 (UTC)

(ii) I think is it the convention to interpret clothes=women;underwear as a female underwear store. Now whether this means the store sells any other female clothes, that I'm not sure about (I tend to say no, and that's how I map), but there's definetly no room for male clothing in this tag value to me.

--Freetz (talk) 17:17, 16 October 2022 (UTC)

Confusing example with vertical bar

Resolved: Proposal has been changed. Something B (talk) 16:21, 17 December 2022 (UTC)

"Gender segregated toilets: amenity=toilets & female=yes & male=yes & gender_layout=female|male"

it is confusing; should "gender_layout=female|male" really be used as a literal key/value (with vertical bar in the middle?!) ?? As it is example, it should only show tags exactly as they would be used in real world example (e.g. "gender_layout=female"). Please do not use BNF or any other syntax in examples, only literal raw key=tag values

It is literal values. Inspired by maxspeed:lanes=*. Something B (talk) 19:53, 15 October 2022 (UTC)

Syntax with the vertical bar has been dropped from the proposal. Something B (talk) 20:17, 15 October 2022 (UTC)

Features / Pages affected

Resolved: Out of scope. Something B (talk) 16:14, 23 May 2023 (UTC)

The list of affected features/pages could possibly be extended. After a little thought, this came to my mind (maybe or probably there are other cases):

• amenity=place_of_worship
• amenity=brothel / amenity=love_hotel / amenity=stripclub / amenity=swingerclub
• shop=erotic (e.g. shops for women only – and perhaps a special case (?): sometimes male customers are only allowed to accompany a woman)

Goodidea (talk) 00:25, 14 October 2022 (UTC)

Unless a brothel etc is purely homosexual, access is always implied for different genders - perhaps in different roles...

I think restrictions in the form of "gender A only allowed with gender B" should not be the scope of this tagging scheme but are a peculiarity of specific amenities that are better tagged with tags specific to those amenities, if needed.

--Freetz (talk) 04:20, 14 October 2022 (UTC)

Only male+female allowed

Resolved: Out of scope. Something B (talk) 16:21, 17 December 2022 (UTC)

How to tag a Christian kindergarten that doesn't recognize the existence of nonbinary kids and probably would reject an application for one?

Gender: Children perceive themselves as boys or girls, we take into account the different world views of girls and boys.

--Wulf4096 (talk) 12:56, 16 October 2022 (UTC)

I don't know. Maybe description=This kindergarten doesn't recognize the existence of nonbinary kids. Or female=yes & male=yes, but it is less obvious. Something B (talk) 13:22, 16 October 2022 (UTC)

That sadly also makes this a lot harder to display on maps. :/ Also, description probably isn't a good place for this either, as it isn't really a description of the kindergarten. MTRNord (talk) 14:00, 16 October 2022 (UTC)

The proposal page is very binary as it still does not explicitely enable the recongnition of non-binary genders as may be required in some countries. That's why I still think a gender namespace is needed. Is this very example it would be for_gender:divers=no + for_gender:female=yes + for_gender:male=yes, or better gender:for:*=* as this aligns better with gender:use=separated/shared (which I still prefer over any alternative proposed meanwhile). Wheather enby, non_binary, or x would be a better and more internally understood than divers, is up for discussion.

The description=This kindergarten doesn't recognize the existence of nonbinary kids sounds judgemental to me, should not be used, IMO. I don't think gender designation of schools etc need to be graphically displayed on generic maps (it isn't currently). This is a very special information about an amentiy that should be left for a dedicated data consumer to interpret in a way that suits their particular users.

Now whether gender designation of a kindergarten, or a school for that matter, is important data in OSM, could be questioned. Neither amenity=kindergarten nor amenity=school lists gender designation on the wiki pages so far. In particular kindergartens, but also schools, are pretty much private clubs where only members have access anyways, nobody can just go play in a kindergarten or join a class in a school without being enrolled. Those membership policies can change and may be better left to the website of the amenity?

--Freetz (talk) 16:35, 16 October 2022 (UTC)

I think that unusual polices is not suitable for mapping. Maybe link to website is the best way. I don't know places that designated for nonbinary people, typically they use "binary" toilets, or gender neutral, if available. Something B (talk) 19:10, 16 October 2022 (UTC)

First voting (closed)

Resolved: Proposal has been changed. Something B (talk) 16:47, 17 December 2022 (UTC)

• I approve this proposal. -- Something B (talk) 22:12, 19 October 2022 (UTC)

Proposers should not approve (or disapprove) their own proposals. --Freetz (talk) 03:15, 21 October 2022 (UTC)

Voting for own proposals is perfectly acceptable. See Talk:Proposal process -- Something B (talk) 14:32, 21 October 2022 (UTC)

• I oppose this proposal. There is a substantial change between https://wiki.openstreetmap.org/w/index.php?title=Proposed_features/Gender&type=revision&diff=2423104&oldid=2419357 within the last week. male=yes and female=yes should not be (re-)defined to them only. It may be unspecified, unknown, unaware, or not investigated yet. Simply use male=only and female=only if this is certain. gender_use=* is quite disorganized and confusing. It creates it own set of problems while attempting to solve unisex=yes.--- Kovposch (talk) 05:37, 20 October 2022 (UTC)
• I oppose this proposal. I preferred the original version of the proposal. This is now needlessly complex for certain common situations. For example, it now requires 3 tags instead of 1 for a segregated facility with male and female sections. --Tordanik 07:46, 20 October 2022 (UTC)

Post 1st voting

Resolved: Proposal has been changed. Something B (talk) 16:21, 17 December 2022 (UTC)

The current revised proposal still (again) has unintiutive wording for for gender separation than cannot be understood without explanation. It seems like gender:use=separated/shared is not apprecitated to tag gender separation.
How about gender_space:female/male/neutral=no/unknown/yes? or gender_spacing=female;male;neutral?
-- Freetz (talk) 03:52, 21 October 2022 (UTC)

gender_spacing=* is good idea. Something B (talk) 07:52, 21 October 2022 (UTC)

I don't understand gender_spacing=*. --- Kovposch (talk) 11:27, 21 October 2022 (UTC)

Kovposch , You can suggest alternative? Something B (talk) 13:23, 21 October 2022 (UTC)

gender_zoning=*. --Freetz (talk) 15:02, 21 October 2022 (UTC)

I will admit this is difficult to comment on. I want to wait for more clarifications first.
If gender is convoluted, how about fixing unisex=* itself instead first? Eg unisex=neutral to clarify unisex=yes.
--- Kovposch (talk) 11:12, 22 October 2022 (UTC)

Resolved

There is again binary wording used and wording that implies access restrictions. I suggest:

Designation	Tagging	Explanation
All (or no) genders	gender_zoning=neutral	POI is designated for use by all (or no specific) genders, no separate zones exist for any gender
Female + Male	gender_zoning=female;male	POI is designated for female and male use in separated zones (or separate OSM objects for each zone)
All genders with additional female and male zones	gender_zoning=female;male;neutral	POI is designated for use by all genders, a gender neutral zone as well as separated zones for females and males exist (or separate OSM objects for each zone)
Female	gender_zoning=female	POI is designated for use by females, no other gender designation exists
Male	gender_zoning=male	POI is designated for use by males, no other gender designation exists

-- Freetz (talk) 15:35, 21 October 2022 (UTC)

I do not like any access wording and much more prefer designation. As pointed out already, little children usually go to the same restroom as their accompanying parent. Also, a caregiver might accompany a person of a different gender to their designated toilet. Why not using designation?
gender_zoning=* makes no sense for shop=hairdresser. I suggest to add hairstyle=children/female/male to hairdressers that specialize in certain styles (no connection to customer's gender, similar to clothes=*) and hairstyle=universal for hairdressers that offer stylings of any type.

-- Freetz (talk) 19:59, 21 October 2022 (UTC)

Thanks! -- Something B (talk) 23:13, 21 October 2022 (UTC)

Thank you! I like the latest revision. Want to try another voting?

-- Freetz (talk) 03:54, 22 October 2022 (UTC)

It will take some time (maybe week) for other contributors to comment proposal. Something B (talk) 08:00, 22 October 2022 (UTC)

Sorry I don't understand what's the problem with gender=*? --- Kovposch (talk) 10:10, 22 October 2022 (UTC)

Just gender=* has no context and it is not clear what it describes.

-- Freetz (talk) 10:29, 22 October 2022 (UTC)

How big is this problem though? You can use hairstyle:gender=* etc for other situations. If adopting those arguments, hairstyle=female will still have gender-related issues, which should instead be feminine or long/short etc. --- Kovposch (talk) 10:54, 22 October 2022 (UTC)

Similar to what I mentioned earlier, continuing to use semi-colon multivalue prevents using *=separate for "separate OSM objects". It is ambiguous whether the object represents a single or multiple genders in those cases. --- Kovposch (talk) 10:49, 22 October 2022 (UTC)

If sections are mapped separately, every section is separate "object" in OSM sense, and gender_zoning=female/male is perfectly suitable for it. If sections not mapped separately, but segregation exists, gender_zoning=female;male may be used. Something B (talk) 11:13, 22 October 2022 (UTC)

This new gender_zoning=* seems more reasonable to me that previous proposal. However, here are few issues I see (in subsections for easier commenting):

Remove (or clearly document) targeted_for=*

Resolved

I'm completely baffled by that targeted_for=* in there. What is its use? How does targeted_for=female differs from gender_zoning=female? Can one exist without other? Its completely unclear and undocumented. Either delete that additional tag (preferable), or provide additional clear and detailed explanations what exactly targeted_for=* does, how it differs from gender_zoning=*, and give several examples with various explanations how would they could/should be combined together (and/or when they should not be combined but only one chosen). --mnalis (talk) 17:33, 22 October 2022 (UTC)

Zones for disabled persons

Resolved

how do disabled persons (i.e. wheelchair=yes fit in there? Disabled persons could be both male and female, yet they often have their own zoning. --mnalis (talk) 17:33, 22 October 2022 (UTC)

Zones for children

Resolved

what about child=yes mentioned at amenity=toilets wiki (e.g. when they have their own zones adapted to lower heights, or when their adapted-size-and-height toilets are intermixed with other toilets in the same zone)? Please give examples how to map. --mnalis (talk) 17:33, 22 October 2022 (UTC)

Document If we defer to other tags

Note that it is quite OK that this proposal does not specify extra tagging for disabled persons, children etc. if you think it is preferable. But it should nonetheless be documented that this was considered, and to what tag to defer (i.e. when doing the more extensive example section, do put an example which uses other tag if we prefer that). Main thing is to go for redundant clarity (description & example), to avoid pitfalls of previous tagging attempts. --mnalis (talk) 17:33, 22 October 2022 (UTC)

Micromapped zones?

example for gender_zoning=female;male et al says "POI is designated for female and male use in separated zones (or separate OSM objects for each zone)". Do we really need/want additional tagging on area if more specific micromapping is already mapped as well (i.e. "separate OSM objects for each zone") as seems to be implied in that wording)? And if we do, we should document how to do it and give examples. (See for example amenity=school examples to see how it should be documented) --mnalis (talk) 17:33, 22 October 2022 (UTC)

More time for discussion

absolutely please allow ample time to discuss the proposal before going to vote again!! We already have male=*/female=*/unixsex=* as well as gender=* and gender_segregated=* (luckily not very heavily used as of yet), and we absolutely do not need the new tag(s) for the same thing to still have any chance of confusion or less then perfect clarity! Minimum is two weeks as this is basically new proposal, but (given the situation so far) I'd go for at least a month after announcing changed version on tagging mailing list and Talk pages of other tags used for similar purpose (mentioned above). Or at least a week after a comments on how to improve the tagging / outlining unclear things stop dropping in! --mnalis (talk) 17:33, 22 October 2022 (UTC)

Second voting (closed)

Moved from proposal page.

Resolved: Proposal has been changed. Something B (talk) 16:21, 17 December 2022 (UTC)

• I approve this proposal. -- Something B (talk) 12:17, 4 November 2022 (UTC)
• I oppose this proposal. to solve the (auto.proclamed) unclear usage of unisex, create new value for the unisex key, no need to create a new key on the same subject and which will obviously cause inconsistencies when only one of the 2 keys is changed Marc marc (talk) 12:32, 4 November 2022 (UTC)
• I oppose this proposal. If unisex is unclear it should be clarified instead of adding another key that just adds to the confusion. --Lonvia (talk) 13:09, 4 November 2022 (UTC)
• I have comments but abstain from voting on this proposal. I don't see a reply to my unisex=neutral etc suggestion. gender_zoning=* is still awkward. --- Kovposch (talk) 13:40, 4 November 2022 (UTC)
• I oppose this proposal. - It is unclear whether the proposed tags could also apply to other types of facilities like educational institutions, religious places and other places where genders may be separated. The proposal does not specify what would or should happen to places that currently have the existing tags for gender separation. I have also never heard anyone talk about "gender zoning," so I think this term is too unintuitive for many mappers. The way targeted_for=* is phrased, it could easily be misinterpreted or reinterpreted as a tag for any type of target group and become something like community_centre:for=* or social_facility:for=*, which should also be taken into consideration. All in all I think the proposal has been set to "voting" prematurely. --501ghost (talk) 14:15, 4 November 2022 (UTC)
• I oppose this proposal. One person did not find clear the definition of unisex and made a proposal and got one supporter for the first vote, him/herself and made a second vote. Got his/her approval again. Are you aware of the expression "The ridiculous does not kill"? --Nospam2005 (talk) 19:54, 4 November 2022 (UTC)

I don't see anything ridiculous here. The proposal just contained flaws that were not obvious to me, and the feedback only came when the voting was started. If you disagree with the proposal, write about it in detail. -- Something B (talk) 21:54, 4 November 2022 (UTC)

You're right, I should have said that I agreed with @Marc marc: and @Lonvia:, it was implicit. @Mnalis: mentioned "we absolutely do not need the new tag(s) for the same thing to still have any chance of confusion or less then perfect clarity" well before vote start. --Nospam2005 (talk) 22:16, 4 November 2022 (UTC)

OK, previous versions failed, but what about the current one? Controversial things like gender_zoning were dropped and the unisex=neutral tag was added. "Rationale" section also been clarified. It is better? -- Something B (talk) 22:28, 4 November 2022 (UTC)

In general, starting a vote before the questions mentioned in the discussion are solved (with a real solution or an objection) is contra-productive. @Mnalis: mentioned the - at least - non intuitive `targeted_for`. You didn't answer and are changing to the even worse hairdresser:for. male/female/unisex works and is IMHO sufficient. If you want to target the audience, it's not specific to hairdressers, don't create a namespace when not needed. The rationale isn't rational: you pretend that unisex could mean for male and female but separately but nothing in the wiki suggests that unisex could mean something else than the British term unisex. So you create a problem on your own. The best way to solve this is as suggested by @Lonvia: If unisex is unclear it should be clarified instead of adding another key that just adds to the confusion. The discussion shows the proposal is creating confusion, not reducing it as you expect. --Nospam2005 (talk) 23:00, 4 November 2022 (UTC)

See Key:unisex. "There is some disagreement about whether unisex=yes means gender neutral, or is a shorthand for male=yes + female=yes" -- Something B (talk) 23:20, 4 November 2022 (UTC)

See https://wiki.openstreetmap.org/w/index.php?title=Key:unisex&oldid=1709655 : the ambiguity has been created. It was not ambiguous. --Nospam2005 (talk) 11:45, 5 November 2022 (UTC)

See https://josm.openstreetmap.de/ticket/15536 -- Something B (talk) 11:57, 5 November 2022 (UTC)

Micromapping

Resolved: Micromapping allowed by this proposal. Something B (talk) 16:21, 17 December 2022 (UTC)

Pretty much non sense: you have 3 (or more) separate rooms and tag them all together. You can apply this non sense for almost every single feature in OSM. A normal restaurant is accessible to the public. Some rooms are probably private. Would you propose to tag the entrance with access=private;yes. You wouldn't, would you? Would you tag a mall shop=hairdresser;clothes, etc because inside the mall there is at least a hairdresser, shops to buy clothes, etc.  ? So yes the initial meaning has been altered and non-sense have be made possible. Again, please take into account what @Mnalis: said in "Micromapped zones?". --Nospam2005 (talk) 21:31, 5 November 2022 (UTC)

Do you suggest marking each section separately? Proposal explicitly allows it. Or do you want only this way to be allowed? I absolutely agree that more detailed mapping is preferred, but still, I don't think it's a good idea to make it a requirement. For malls there is shop=mall for the mall as a whole, but why can't a toilet with separate rooms be marked as a whole? -- Something B (talk) 21:52, 5 November 2022 (UTC)

Sure: micro-mapping is the solution. Toilets can be mapped as a whole as long as they are the same (add capacity=*, and that's it). If they don't share the same information you want to map, map them separately. If you have one building with two parts, one lower than the other, you can map it as a whole, then you will give as height the height of the highest part, let's say height=12. If you want to say that a part is 8 m and the other 12, you would not tag height=8;12 but create building parts, one with height=8, the other with height=12. --Nospam2005 (talk) 22:10, 5 November 2022 (UTC)

For clarity. Do you suggest drop female=separate and male=separate and change proposal accordingly? -- Something B (talk) 22:18, 5 November 2022 (UTC)

I would simply restrict the proposal to a) wiki clarification and b) suggestion to restore and update the validator accordingly. It implies dropping female=separate and male=separate. So: unisex means unisex i.e. gender neutral (allowed for men and women), it does not mean female=yes and male=yes and other possible meanings are deprecated. N.B.: I've nothing against female=separate and male=separate to tag a gender separated, non-unisex, toilet as amenity=toilets except that female=yes on the left and male=yes on the right is more simple and more descriptive. Simple proposals are in general more successful. Then you can still make other proposals to add separate as possible value. --Nospam2005 (talk) 22:56, 5 November 2022 (UTC)

I think tagging individual sections as female=only and male=only instead of female=yes and male=yes is more explicit and obvious. -- Something B (talk) 23:11, 5 November 2022 (UTC)

Indeed but raw values can be hidden by presets and yes/no are the only supported values according to the wiki. You would need to deprecate yes in favor of only with no semantic change so with no real added value. Saying that yes means only is better for data consumers. IMHO, only if a proposal introduces separate, changing yes into only would be worth. --Nospam2005 (talk) 23:32, 5 November 2022 (UTC)

I think redefining the value of a tag that is widely used can be more confusing than introducing a new one. The value yes can simply mean "available", without further specification. The wiki doesn't mention the value only, but that's what it's supposed to do - reach a consensus and change the wiki accordingly. Regarding presets, full-fledged editors provide the ability to edit tags directly. -- Something B (talk) 23:55, 5 November 2022 (UTC)

KISS: restore clarity

Resolved: Done. Something B (talk) 16:14, 23 May 2023 (UTC)

In 2018 the page has been dramatically changed from the normal definition of unisex=gender neutral to something unclear => come back to the 2018 definition.

The JOSM validator had been deactivated accordingly. Restore it but with a better hint: if the place in gender neutral, tag with unisex=yes, if some parts are not gender neutral, tag them accordingly. --Nospam2005 (talk) 21:56, 5 November 2022 (UTC)

I cannot change the wiki if there is disagreement. Technically I can make changes to the wiki, but anyone can roll back my changes with the comment "Please don't touch this page until there is consensus" and be right. But the adoption of the proposal will allow to consolidate the rule: unisex=yes is "gender neutral" . -- Something B (talk) 22:11, 5 November 2022 (UTC)

"Resolved" without explanation?

Resolved: Explanations has been added. Something B (talk) 16:21, 17 December 2022 (UTC)

When marking some concern as "Resolved", please also add a short description how exactly was it resolved, as it is often unclear. @Something B:

Also, please provide changeset comments when editing wiki, it helps a lot when trying to find who changed what and why in history.

--mnalis (talk) 06:38, 18 November 2022 (UTC)

no values aren't mentioned.

Resolved: Done. Something B (talk) 16:33, 17 December 2022 (UTC)

I really like the current schema. AIUI the case of a no is not mentioned. (e.g. male=no, unisex=no). I think it would be good for data consumers & contributors to know/decide what =no values mean. Do you think this should be added to the proposal? I think it's easy to do Amᵃᵖanda (talk) 20:32, 23 November 2022 (UTC)

I think that male=no and female=no is unnecessary, because female=only and male=only clearly indicates single gender areas. unisex=no may be implicit if female=* or male=* present. Something B (talk) 22:29, 23 November 2022 (UTC)

I think it's good to document these combos :) Amᵃᵖanda (talk) 13:52, 30 November 2022 (UTC)