Proposal:Barbers

From OpenStreetMap Wiki
Jump to navigation Jump to search
Tag:hairdresser=barber
Proposal status: Voting (under way)
Proposed by: Casey boy
Tagging: hairdresser=barber
Applies to: node, area, relation
Definition: A type of hairdresser that traditionally specialises in cutting masculine styles and providing other male grooming services such as beard trimming.
Statistics:

Draft started: 2024-01-30
RFC start: 2024-02-02
Vote start: 2024-02-26
Vote end: 2024-03-11


Proposal

This proposal is to formally introduce hairdresser=barber, as a sub-key of the shop=hairdresser tag and as the accepted way of tagging barber shops.

Rationale

Barbers traditionally provide masculine style hair cuts, as well male-oriented as services such as beard trimming. They are unlikely to provide traditionally feminine hairdressing styles or services. In some countries, barbers may require specific licencing. Barber shops are often distinct from hairdresser salons but they may sometimes be co-located within the same building/business as a hairdressing salon.

The distinction between a hairdresser salon and a barbers varies. In some countries, the distinction may not exist at all. However, some common examples of what can be found in a barbers are: specific furniture (salon vs barbers chairs), a barber's pole (either real poles or images of them), imagery examples of masculine hair styles, silhouettes of male faces with beards, imagery of razors, blades and clippers or those items on display, sometimes with themes around (traditionally male) sports or music. They may also have the word "barber" in their decoration or shop name.

Other distinctions are that barbers may tend to focus on using razors and clippers, rather than scissors, when cutting hair. They tend to be cheaper and quicker than a salon, and are more open to walk-in appointments (though this will depend on location and brand).

Current tagging

Currently, the documented way to tag barber shops is simply shop=hairdresser + male=yes.

However, this is problematic for a few reasons:

  • male=* (and its counterpart female=*) is documented as an access restriction, rather than indicating the gender of the intended customers or style/service provided. Although usage is mixed.
  • Saying that barbershops are for men only relies on out-dated gender stereotypes. Whilst traditionally focussed on “male-styled” cuts and masculine services (beard trimming), many barbershops will happily provide services to women. Indeed, in many countries, it would be illegal for them not to (e.g., USA, EU, UK, Australia).
  • Nearly half of all shop=hairdresser (~12,000 out of 25,000) are tagged with both male=yes and female=yes. It is unclear whether these are unisex hairdresser salons that cater for men, or barbers that also cater for women.

There are around 9,300 instances of shop=hairdresser + male=yes + (female!=yes or female!=*), suggesting there are many barber shops mapped in OSM.

Benefits of suggested tagging

Introducing specific tagging for barbers has the benefit of:

  • Unambiguous tagging for data consumers
  • No reliance on gender stereotypes
  • Proposed tagging scheme does not break current data consumers/users. If a data consumer doesn’t understand hairdresser=barber, it should still understand shop=hairdresser which is better than nothing.
  • Enables actual access restrictions to be appropriately mapped. For example, if it is truly not allowed for women to visit a barbershop (perhaps in certain jurisdictions), tagging would be: shop=hairdresser + hairdresser=barber + female=no.

Other options

Various other options exist that could be used to tag barber explicitly. For example:

  • shop=barber - a new top-level value for the shop key.

Pro: the main "pro" to this approach is that a barber shop is tagged on its own merit, rather than as a sub-key, reflecting the distinct nature of a barber shop compared to a hairdresser's salon.
Con: this would be a breaking change for data consumers, with little actual benefit from a data perspective. Barber POIs that are currently mapped would likely "fall off the map" (and new ones not appear) until renderers updated their code. However, if tagged using the suggested tagging, barbers would still appear on the map. Icons could be updated (if a renderer deemed this as needed) without breaking current rendering.

  • shop=hairdresser + barber=yes/no/only - value tagging to indicate whether a hairdresser is a barbers ("only"), has a separate barbers chair/section ("yes"), or does not have a barbers ("no").

Pro: flexible tagging that does not introduce breaking changes for data consumers.
Con: values are not immediately obvious for a mapper, without reading documentation. May result in some confusion (particularly the distinction between "yes" and "only") or introduction of unusual/unexpected values.

After discussions on the Community Forum, a poll found that the most popular approach to specific tagging for barber shops was hairdresser=barber. There is already some usage of this tag (264 instances at the time of writing).

Tagging

A barber shop would be tagged as:

preferably along with tags such as name=*, opening_hours=* etc. For barbers that do not allow women, female=no would also be added.

Other hairdresser= values:
Although not strictly part of this proposal, there has been general support to use comma delimited lists to represent other hairdressers.

Examples

Rendering

Seeing as this is a sub-key, rendering is likely to default to the same as shop=hairdresser.

Features/Pages affected

shop=hairdresser

External discussions

Comments

Please comment on the discussion page.

Voting

Instructions for voting
  • Log in to the wiki if you are not already logged in.
  • Scroll down to voting and click 'Edit source'. Copy and paste the appropriate code from this table on its own line at the bottom of the text area:
To get this output you type Description
  • I approve this proposal I approve this proposal.
{{vote|yes}} --~~~~ Feel free to also explain why you support proposal.
  • I oppose this proposal I oppose this proposal. reason
{{vote|no}} reason --~~~~ Replace reason with your reason(s) for voting no.
  • I abstain from voting but have comments I have comments but abstain from voting on this proposal. comments
{{vote|abstain}} comments --~~~~ If you don't want to vote but have comments. Replace comments with your comments.
Note: The ~~~~ automatically inserts your name and the current date.
For full template documentation see Template:Vote. See also how vote outcome is processed.
  • I approve this proposal I approve this proposal. Proposal author Casey boy (talk) 12:15, 26 February 2024 (UTC)
  • I approve this proposal I approve this proposal. --Moanos (talk) 12:26, 26 February 2024 (UTC)
  • I oppose this proposal I oppose this proposal. As per previous detailed discussions. --Bkil (talk) 16:25, 26 February 2024 (UTC)
@Bkil:can you link to one posting summarizing your position? Mateusz Konieczny (talk) 17:26, 26 February 2024 (UTC)
  • I oppose this proposal I oppose this proposal. I appreciate launching this proposal and voting, but I think the subtag should be barber=(yes/no/only), because it's more descriptive, comprehensive and unambiguous, as discussed in the wiki discussion page. --AntMadeira (talk) 18:02, 26 February 2024 (UTC)
  • I approve this proposal I approve this proposal. The existing tagging scheme with shop=hairdresser, male=yes and female=yes is probably sufficient for some countries. But in other countries such as the UK, hair salons and barbershops are considered two different shop types. They look different both from the outside and inside, have different pricing, and use different techniques. We have been lumping them in together under shop=hairdresser and this tag will give us a way of differentiating them. --Osmuser63783 (talk) 18:38, 26 February 2024 (UTC)
  • I approve this proposal I approve this proposal. have been using it like that before the proposal myself already --B-unicycling (talk) 21:36, 26 February 2024 (UTC)
  • I approve this proposal I approve this proposal. --Fizzie41 (talk) 21:54, 26 February 2024 (UTC)
  • I approve this proposal I approve this proposal. It is interesting to have an scalable scheme --Yopaseopor (talk) 22:06, 26 February 2024 (UTC)