Proposal talk:Privacy

Key is too general and values too vague

It doesn't make sense to define privacy=* just for showers when there are many other features that can have different levels of privacy as well, e.g. toilets or changing rooms.

And I think that it would be better to have self-descriptive tags, e.g:

• privacy=stalls ... if you have your own cubicle with a door or curtain
• privacy=partitions ... if there are only partition walls (but no doors or curtains)

instead of privacy=yes & privacy=semi which are much less clear (and require a look into the documentation to discern their meaning).

--Push-f (talk) 15:47, 24 September 2022 (UTC)

Thanks! Something B (talk) 16:01, 24 September 2022 (UTC)

You're welcome. A couple more thoughts:

• I think that all of these privacy levels can occur both indoor as well as outdoor (with indoor=yes or outdoor=yes). If so that should be noted in the proposal.
• Communal rooms can probably also occur outdoors if the roof is missing ... in which case "commmunal_room" does not quite fit because rooms usually have a roof. While this could be addressed by changing the value to something like "communal_area", that might be even more confusing... I am not sure what to do about this.
• Describing privacy=partitions as semi-private might be confusing ... aren't communal rooms semi-private as well (because they offer some privacy over privacy=no)?

--Push-f (talk) 05:32, 25 September 2022 (UTC)

privacy=* looks too "subjective", and may be misused for other purposes. Better tag the division, and door or curtain. This is more specific.
There is transparent=* I picked up on. Useful for door:material=glass.
--- Kovposch (talk) 08:17, 25 September 2022 (UTC)

privacy=* basically isn't used - > misusing unlikely to be occur. In contrast, transparent is very "abstract" in this context (IMHO). Something B (talk) 08:25, 25 September 2022 (UTC)

There was someone who asked about how to tag privacy policies and info of man_made=surveillance before. It's funnily not that unlikely.
This concept is a general one that can be used in eg amenity=internet_cafe and libraries or study rooms as well. (also 1 nursing_room:privacy=lock instance 710875293 710875293 although for alternatives locked=* and lockable is not the same) But "privacy" there is not always useful. Eg I want to play or study with others, then this usually desirable "privacy" is not what I'm looking for.
Separating allows divisions and curtains or doors to separately tagged. Right now you are mixing doors and curtains into privacy=stalls and privacy=partitions --- Doors and curtains provides different extent of privacy as well.
What about when there is a partition block on the table, but no walls extending out covering your chair and body? As in  Carrel desk.
Another common difference is stall partitions with gaps on top and bottom (making feet and shadow visible) vs full height floor-to-ceiling walls enclosing as an individual "room".
--- Kovposch (talk) 07:48, 26 September 2022 (UTC)

If the stalls have skimpy curtains, this may be tagged as privacy=partitions. Something B (talk) 10:54, 26 September 2022 (UTC)

P. S. Proposed values are not subjective, see photo examples. Something B (talk) 08:30, 25 September 2022 (UTC)

Thanks for the proposal, it'll be a useful addition. I agree privacy=* should be proposed as a generic tag which can apply equality to a range of primary tags. We should include baby_feeding=* as one combination.

I agree with the current values, slight tweaks below.

• privacy=stalls - individual booths, stalls or rooms with doors or curtains. Personal privacy is available.
• privacy=partitions - partition walls present but no doors or curtains. Some degree of personal privacy is available.
• privacy=communal_area - communal room or area without partition walls. Privacy from general passer byers, but no privacy from other customers using the facility.
• privacy=no – the amenities are just out in the open without visual cover from bypassers.

We should additionally recommend the unisex=* tag as privacy=communal_area with unisex=no means you only share the space with your own gender but unisex=yes means you share the space with any gender. If you're happy I can make tweaks directly to the proposal page, otherwise I'll leave up to you. --Aharvey (talk) 04:10, 26 September 2022 (UTC)

Thanks! You can make tweaks directly. Something B (talk) 08:06, 26 September 2022 (UTC)

female/male/unisex over-defined?

It seems that only one of the female=*, male=*, unisex=* keys can be yes at the same time. If so, then maybe one gender=* with values male/female/unisex would be sufficient? --Martianfreeloader (talk) 14:41, 26 September 2022 (UTC)

female=yes and male=yes may be used together and indicates gender segregated facility, if sections are not mapped separately. gender=* seems be interesting, but it is out of scope of this proposal. Something B (talk) 15:00, 26 September 2022 (UTC)

To reflect your work on the gender proposal I'd modify the privacy proposal to do without the female=*, male=*, unisex=* tags. Instead, I suggest to introduce privacy:female=*, privacy:male=*, privacy:unisex=* for multi-gender objects where privacy differs between genders. --Martianfreeloader (talk) 10:18, 3 October 2022 (UTC)

@Something B: I've seen you've modified the proposal after my comment, but it still contains this section:

It is additionally recommended to tag privacy=communal_area or privacy=partitions with

*female=yes and/or male=yes and/or gender=female/male/segregated means you only share the space with your own gender; or

*unisex=yes and/or gender=unisex means you share the space with any gender.

Isn't this obsolete with the new gender proposal? --Martianfreeloader (talk) 09:53, 4 October 2022 (UTC)

Until the "gender" proposal get approval, it isn't obsolete, because female=*, male=* and unisex=* is actual tagging. Something B (talk) 22:38, 4 October 2022 (UTC)

Ok, granted. But I'd at least add a note that these keys might get obsolete once the gender proposal is approved. --Martianfreeloader (talk) 11:57, 5 October 2022 (UTC)