Modify

Opened 10 months ago

Closed 5 months ago

#23067 closed defect (fixed)

Bad validation around hairdresser

Reported by: berlin-lion Owned by: team
Priority: normal Milestone: 23.12
Component: Core validator Version:
Keywords: template_report Cc: Klumbumbus

Description

I believe that the validation on hairdresser with the suggested fix to replace female=yes and male=yes to unisex=yes is misleading, as the wiki (tag:shop=hairdresser) states:

Note that unisex=yes/no has conflicting meanings as documented on it's wiki. Also, its absence might mean "yes, it is available for everybody", or might mean "gender-related details are not mapped yet". So instead of using unisex=*, please use explicit combination of female=* + male=* for clarity.

I found #15536 which looks related.
My suggestion would be to remove the validation. One could argue that it could be replaced by an opposite validation, notifying about uses of unisex on [shop=hairdresser], however this decision is best made by more experienced people.
I hope that this is the correct place to raise an issue, I noticed the validation first on Osmose.
Also, the StreetComplete quest for hairdresser customers seems to remove the unisex tag in favor of using both female and male.

What steps will reproduce the problem?

  1. Run validation on any node with [shop=hairdresser][female=yes][male=yes]

What is the expected result?

I'd expect no validation error

What happens instead?

Will yield suspicious tag combination – use unisex=yes instead

Please provide any additional information below. Attach a screenshot if possible.

Relative:URL: ^/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2023-07-06 21:00:41 +0200 (Thu, 06 Jul 2023)
Revision:18772
Build-Date:2023-07-07 01:30:58
URL:https://josm.openstreetmap.de/svn/trunk

Identification: JOSM/1.5 (18772 en) Linux Mint 21.1
Memory Usage: 281 MB / 1958 MB (67 MB allocated, but free)
Java version: 11.0.19+7-post-Ubuntu-0ubuntu122.04.1, Ubuntu, OpenJDK 64-Bit Server VM
Look and Feel: javax.swing.plaf.metal.MetalLookAndFeel
Screen: :0.0 3440×1440 (scaling 1.00×1.00)
Maximum Screen Size: 3440×1440
Best cursor sizes: 16×16→16×16, 32×32→32×32
Environment variable LANG: en_US.UTF-8
System property file.encoding: UTF-8
System property sun.jnu.encoding: UTF-8
Locale info: en_US
Numbers with default locale: 1234567890 -> 1234567890
Desktop environment: X-Cinnamon
Java package: openjdk-11-jre:amd64-11.0.19+7~us1-0ubuntu1~22.04.1
WebStart package: icedtea-netx:all-1.8.4-1build1
libcommons-logging-java: libcommons-logging-java:all-1.2-2
fonts-noto: fonts-noto:-
VM arguments: [--patch-module=java.desktop=/usr/share/icedtea-web/javaws.jar:, --add-reads=java.base=ALL-UNNAMED,java.desktop, --add-reads=java.desktop=ALL-UNNAMED,java.naming, --add-reads=java.naming=ALL-UNNAMED,java.desktop, --add-exports=java.desktop/sun.awt=ALL-UNNAMED,java.desktop, --add-exports=java.desktop/javax.jnlp=ALL-UNNAMED,java.desktop, --add-exports=java.base/com.sun.net.ssl.internal.ssl=ALL-UNNAMED,java.desktop, --add-exports=java.base/sun.net.www.protocol.jar=ALL-UNNAMED,java.desktop, --add-exports=java.base/sun.security.action=ALL-UNNAMED,java.desktop, --add-exports=java.base/sun.security.provider=ALL-UNNAMED,java.desktop, --add-exports=java.base/sun.security.util=ALL-UNNAMED,java.desktop, --add-exports=java.base/sun.security.validator=ALL-UNNAMED,java.desktop, --add-exports=java.base/sun.security.x509=ALL-UNNAMED,java.desktop, --add-exports=java.base/jdk.internal.util.jar=ALL-UNNAMED,java.desktop, --add-exports=java.base/sun.net.www.protocol.http=ALL-UNNAMED,java.desktop, --add-exports=java.desktop/sun.awt.X11=ALL-UNNAMED,java.desktop, --add-exports=java.desktop/sun.applet=ALL-UNNAMED,java.desktop, --add-exports=java.desktop/sun.applet=ALL-UNNAMED,jdk.jsobject, --add-exports=java.naming/com.sun.jndi.toolkit.url=ALL-UNNAMED,java.desktop, -Dicedtea-web.bin.name=javaws, -Dicedtea-web.bin.location=/usr/share/icedtea-web/bin/javaws.sh, -Djava.security.manager, -Djava.security.policy=/etc/icedtea-web/javaws.policy]
Dataset consistency test: No problems found

Last errors/warnings:
- 00108.501 E: org.openstreetmap.josm.io.OsmApiException: ResponseCode=400, Error Header=<You requested too many nodes (limit is 50000). Either request a smaller area, or use planet.osm>

Attachments (0)

Change History (11)

comment:1 by taylor.smock, 10 months ago

Milestone: 23.09

The wiki page was changed <6 months ago. See https://wiki.openstreetmap.org/w/index.php?title=Tag:shop%3Dhairdresser&oldid=2490553 .

I almost never make a change based solely off of wiki text, unless the wiki text has been around a "sufficiently" long amount of time. I usually use 6 months as an indicator that people who care about that specific tag to not have problems with the changes.

I'll revisit this in September.

comment:2 by stoecker, 10 months ago

There was such a wonderful forum entry somewhere about the tagging decisions - first you make a proposal, then it gets voted, changed, voted, .. approved, documented. And then JOSM ignores it. :-) But I can find that anymore...

Last edited 10 months ago by stoecker (previous) (diff)

comment:3 by taylor.smock, 10 months ago

And [then] JOSM ignores it.

Well, we do have wiki:DevelopersGuide/DefaultPresets . :)
On a slightly more serious note, I really need to go through the popular tags and add the missing ones again. Which I'm not looking forward to.

Of note (for this ticket):

controversial cases (like contact:phone=* vs. phone=*) need to be decided case by case

Of specific note, the unisex key had controversial meanings (as of 6 months ago, osmwiki:Key:unisex explicitely said "[the] OSM community has not settled on the meaning of unisex=*").

I did not see a mailing list post on unisex, so I'm not certain that the OSM community has settled on the meaning of unisex. All I know is that an edit was made to the wiki.

Anyway, if you ever find that forum entry, we should probably link to it from the wiki:DevelopersGuide/DefaultPresets page.

comment:4 by taylor.smock, 9 months ago

Ticket #23133 has been marked as a duplicate of this ticket.

comment:5 by mnalis, 8 months ago

I agree that male + female on shop=hairdresser is common and reasonable usage, and should not be warned against. (if anything, use of unisex on shop=hairdresser might be warned about, IMHO)

Some references (that I know of / was involved with):

comment:6 by taylor.smock, 8 months ago

Cc: Klumbumbus added
Milestone: 23.0923.10

I'm going to push this off another month since the disputed text was changed on osmwiki:Key:unisex in April (2024-04), and we are dealing with that tag in context of shop=hairdresser.

TBH, I'm still not certain why unisex=yes doesn't mean everyone in context of shop=hairdresser -- are there hairdressers that take male and female customers and segregates them? Maybe someone involved in editing the wiki can clarify (@mnalis).

I think for most hairdressers that take male and female clients, unisex as currently documented is still the "correct" tag. In the cases where they don't, I would expect to see gender_segregated=yes.

comment:7 by mnalis, 7 months ago

Always a good idea to give more time for people to chime in!

I've linked the issues that I remembered being related; unfortunately my backlog is preventing me from rereading all that again (and finding ones I probably missed) to provide fair summary, but since I've been pinged, I'll try to give few recollections from the top of my head. Let me know if some particular issue is blocker and needs more explanation; and I'll try to elaborate / dig up the relevant part of the discussions.

While issues with access segregation were mentioned, the consensus seems to be (IIRC) that majority of usages of male and female in OSM in connection with shop=hairdresser (at least in Europe and North America) were in fact about hairstyles offered, and not about gender access segregation (for which there where two or three different proposals on OSM Wiki at the time IIRC, none of them finished) -- although there were passing mentions of some places where sex and/or skin-color-based segregation is still enforced)

E.g. shop=hairdresser + male=yes + female=no did not actually mean that females (or LGBTQ+ people etc.) are not allowed to enter the premises (i.e. access-like rules); but instead that only traditionally-male haircuts are known/offered by the hairdressers (e.g. the hairdresser might not have specialized in traditionally female / long hair haircut styles, and/or might lack the machinery like e.g. hair curlers, hood dryers, female perfumes, etc. what-have-you that would cater to female clientele).

The term unisex was also problematic for multiple reasons: differences between sex and gender (and which one it is supposed to apply to, as those are quite different things, and name seems misnomer in that context), and its popular meaning of "fits all sexes equally well" (which might be interpreted as shortcut for "knows to do (traditionally) man hairstyles as well as (traditionally) women hairstyles" but also as "knows to do only unisex hairstyles; e.g. universal hairstyles which are used equally by man and woman; and no specific man-specific nor woman-specific hairstyles"). Examples for various countries also supported easier direct mapping to male and female tags (e.g. given examples in those threads specify hairdressers exactly in those terms "men" / "male" / "gentleman" and/or "woman" / "female" / "ladies" or combination thereof)

Given that only generally accepted use of unisex=yes in shop=hairdresser context was as a somewhat convenient shorthand for male=yes + female=yes; it was found that that tiny possible advantage (especially in this day and age, where it is less common that people manually type in raw tag keys/values) is far outweighed by all of its ambiguity and other disadvantages; so it far better to be explicit and non-ambiguous and use explicit male+female tags instead, even if it takes a little more space in the database.


Anyway, if I understand this ticket, it is not (yet?) about deprecating unisex for hairdressers (if people feel it has some advantages; which I personally don't see, but would love to hear pro-arguments), but about changing JOSM so it does not incorrectly complain about shop=hairdresser+male=yes+female=yes combination of tags, which seems quite popular use in the wild (in fact, more popular than shop=hairdresser+unisex=yes)

comment:8 by taylor.smock, 6 months ago

Milestone: 23.1023.11

Ticket retargeted after milestone deleted

comment:9 by taylor.smock, 5 months ago

Milestone: 23.11

Ticket retargeted after milestone closed

comment:10 by taylor.smock, 5 months ago

Milestone: 23.12

comment:11 by taylor.smock, 5 months ago

Resolution: fixed
Status: newclosed

In 18920/josm:

Fix #23067: Don't warn on unisex, female, and male tag combinations for shop=hairdresser

male=* and female=* is more verbose than unisex=* and also more precise.
From the osmwiki:Key:unisex wiki page:

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".

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain team.
as The resolution will be set.
The resolution will be deleted. Next status will be 'reopened'.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.