Proposal:Clubhouse
(Redirected from Proposed features/clubhouse)
Jump to navigation
Jump to search
| Tag:amenity=clubhouse | |
|---|---|
| Proposal status: | Rejected (inactive) |
| Proposed by: | Casey boy |
| Tagging: | amenity=clubhouse |
| Applies to: |  ,  , 
|
| Definition: | A location used and operated by a club |
| Statistics: |
|
| Draft started: | 2021-04-02 |
| RFC start: | 2021-04-02 |
| Vote start: | 2021-04-21 |
| Vote end: | 2021-05-05 |
Definition
A clubhouse is a location (normally a building, though sometimes a building floor or room) that is almost exclusively used, and normally owned or operated, by a club. The clubhouse may be used for club activities (e.g. hosting games, club meetings, training), storage (e.g. of equipment, materials, trophies), and/or social events. Access to the clubhouse is usually restricted to members of the club and their guests. Private, non-club-related events may be hosted through hiring of the clubhouse, though this is not the primary function of the clubhouse and is at the discretion of the club or its management. Additionally some larger clubhouses may have facilities, such as a bar or restaurant, which the public can visit.
A clubhouse may range in size from a large, multi-room building to a small portable building (note: although the term portable is used to describe this building, it is a permanent feature). Some clubhouses may include facilities such as changing rooms, a bar, or multiple function rooms. Others may simply be a single room.
Distinction from a community centre
A community centre is a term with a very specific meaning: a public amenity where members of the wider community can meet to undertake a range of activities. This is often done through booking all, or part of, the amenity for periods of time. This is the primary function of a community centre.
This means that multiple groups from within the wider geographic community may use the amenity. Examples include religious or political groups, activity classes (e.g. yoga/zumba), and clubs. However, just because a club meets there, or is even based there, it does not explicitly mean that a community centre is a clubhouse, or vice versa.
Since many groups of individuals will meet at a community centre, it means that it is almost certainly not owned or operated by the groups using that amenity. Often community centres are owned, or operated by, local governments, religious organisations, or charities. Unlike a clubhouse, access to a community centre is not based on the membership of a specific club.
Proposal
This proposal aims to clearly identify a clubhouse (see definition) as a separate entity from a community centre (see rationale). To do so, this proposal will:
- Approve the use of the amenity=clubhouse tag when tagging clubhouses.
- Deprecate the use of the amenity=community_centre, community_centre=club_home tagging scheme specifically for clubhouses.
- Deprecate the use of golf=clubhouse. A golf clubhouse should instead be tagged as amenity=clubhouse, club=sport, sport=golf (see rationale).
- Formally deprecate other non-standard tags:
This proposal does not affect the tagging of clubs which are based in actual community centres.
Rationale
The current tagging convention of amenity=community_centre, community_centre=club_home is ambiguous and controversial. This scheme was not part of the original amenity=community_centre proposal and appears to have developed through Wiki editing. The deprecation of amenity=clubhouse, which was previously an "in use" tag, was also only done through Wiki editing.
Whilst it is laudable that an attempt was made to bring the clubhouse tag into a community based tagging scheme, the current implementation is inaccurate and appears to have been done without wide consultation. As explained in the Definitions section, a clubhouse is distinctly not a community centre.
Even if one asserts that a club is a type of community, saying a clubhouse is therefore a type of community centre ignores the (approved) meaning of community centre. A community centre has a specific role in allowing multiple groups to meet in a building that is for the use of the wider (normally geographic) community. A clubhouse also has a specific role in that it is normally for the use of a single club and not the wider community.
Combining a private clubhouse into the community centre tagging scheme is, therefore, to be discouraged.
The deprecation of golf=clubhouse is a natural result of approving amenity=clubhouse, else every sport would be justified in using its own tagging scheme for their clubhouses.
Tagging
A clubhouse may be tagged as a node an area. If tagging as a node, the node should be located within the footprint of the clubhouse building. If tagging as an area, the area should be drawn around the edge of the clubhouse building. Other buildings, grounds, or facilities of a club should not be included.
In cases where club=* has been drawn as an area encompassing all of a club's facilities (e.g. clubhouse, sports pitches, car park) then the amenity=clubhouse needs only to be accompanied by the operator tag, assuming it is located inside this area. Note: this approach to mapping clubs isn't included in this proposal but merely mentioned for completeness.
Other tags (e.g. bar=yes) can be added as appropriate.
Clubhouse as a node
If a building area has been drawn for the clubhouse, the node (POI) should be placed inside it. If not, check regional tagging conventions as to whether amenity and building tags can be combined - in some regions this is discouraged.
- amenity=clubhouse (required)
- club=* (recommended - unless inside a larger club area)
- operator=* (recommended)
- building=* (depending if clubhouse occupies a whole building, if building outline is mapped, and also on regional conventions)
Clubhouse as an area
- amenity=clubhouse (required)
- club=* (recommended - unless inside a larger club area)
- operator=* (recommended)
- building=* (if clubhouse occupies whole building and depending on regional conventions)
A fictitious example
For example, a clubhouse with a bar that belonged to the Mighty Rugby Players rugby union team might be tagged as:
- amenity=clubhouse
- name=Might Rugby Players Clubhouse
- club=sport
- sport=rugby_union
- operator=Mighty Rugby Players Team
- bar=yes
- access=private
- building=yes (If no other building type suited, or if type was not known. Also note regional conventions.)
Examples
Example 1: Community Centre - Parish Hall
- OSM link: https://www.openstreetmap.org/way/419359969
- Type: Community Centre
- Sub-type: Parish Hall
- Purpose: Hosts religious (Christian) activities as well as being available for hire by the general public (for example yoga classes).
- Operator: St Paul's Church (Church of England)
- Website: https://stpauls-scotforth.org/hiring-our-buildings/st-pauls-hala-centre/
Example 2: Community Centre
- OSM link: https://www.openstreetmap.org/way/553634903
- Type: Community Centre
- Sub-type: Community Hall
- Purpose: Hosts a whole range of community groups and activities.
- Operator: Barton Road Social Enterprise
- Website: http://bartonroadcentre.co.uk/
Example 3: Clubhouse
- OSM link: https://www.openstreetmap.org/way/451330221
- Type: cluhouse
- Club: sport (tennis)
- Purpose: A clubhouse with bar, changing facilities, and lounge area. Open to club members only.
- Operator: Bowerham Lawn Tennis Club
- Website: https://clubspark.lta.org.uk/bowerhamlawntennisclub
Places currently informally tagged as amenity=clubhouse: https://overpass-turbo.eu/?w=%22amenity%22%3D%22clubhouse%22+global&R
Rendering
Renderers may chose to add an icon to the rendered building footprint or POI node to identify a clubhouse, perhaps using the same icon as they use for the club=* key (if any).
Features/Pages affected
- club=*
- community_centre=*
- community_centre=club_home (and other "club" pages referencing this tagging scheme)
- golf=*
- golf=clubhouse
External discussions
https://lists.openstreetmap.org/pipermail/tagging/2021-March/060748.html
https://lists.openstreetmap.org/pipermail/tagging/2021-April/060773.html
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 |
|---|---|---|
|
{{vote|yes}} --~~~~
|
Feel free to also explain why you support proposal. |
|
{{vote|no}} reason --~~~~
|
Replace reason with your reason(s) for voting no. |
|
{{vote|abstain}} comments --~~~~
|
If you don't want to vote but have comments. Replace comments with your comments. |
~~~~ 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. Casey boy (talk) 14:07, 21 April 2021 (UTC)- I approve this proposal. --Brian de Ford (talk) 14:52, 21 April 2021 (UTC)
- I approve this proposal. PeterPan99 (talk) 15:42, 21 April 2021 (UTC)
- I approve this proposal. --Komadinovic Vanja (talk) 17:23, 21 April 2021 (UTC)
I oppose this proposal.- Sorry, but the proposal tries to break a perfectly working scheme.
- It further inflates the amenity=* key,without a good reason.
- In its core, it starts with a hair-splitting differentiation if a community meeting in a clubhouse is different from a community meeting in another facility. Yes there are very different communities, some broader and open, some more specialised and more privat. But this was already solved by the sub-tagging schemes, allowing to specify both the type of the facility and the target group. This is a scheme well-accepted by the OSM community for the last 5 years, with steadily growing usage.
- Please remember that the key/value scheme we have in OSM is based on British spelling, instead of e.g. a category number, but is not a literal one-to-one mapping of detailed British semantics. There are some people who like a so called "duck-tagging" scheme, but that does not work overly well since it fragments the tagging.
In contrast, a slightly structured scheme with a broader top-level tag and sub-tagging reduces top-level fragmentation, while allowing finer differentiation in the sub-tagging.
This helps data consumers who are not interested in the details. They might e.g. just want to distinguish a place where some people meet - for whatever reason - from a healthcare facility, or one where people receive social help. - It does not matter for OSM categorisation if the facility houses just one community/club or any number larger than that. If you want to express that, you could propose a capacity-like tag. Or you could set a number of nodes tagged "club=*" within the building/campus of the amenity.
- The proposal has unresolved issues, e.g. it proposes to "Formally deprecate other non-standard tags: ... building=clubhouse", which is wrong since first specifying a building type is not a "non-standard tag", and it is unrelated of the top-level tag being used. There is no need for such deprecation.
- The examples given in the respective section of the proposal do not provide any further insight.
--Polarbear w (talk) 18:23, 21 April 2021 (UTC)
- I approve this proposal. We really need a way to distinguish the local Hells Angels chapter from the local senior-activity center. --Carnildo (talk) 18:35, 21 April 2021 (UTC)
- Indeed we need that. And we have it already. We use community_centre=* and community_centre:for=* for this purpose. --Polarbear w (talk) 20:54, 21 April 2021 (UTC)
- I appreciate that is how you feel - you've made that quite clear throughout. Whilst I respect your opinion, and doubt I'll ever change your mind, others (including myself) disagree with it and feel clubhouse =/= community centre, despite whatever sub-tags you add, hence this proposal. Casey boy (talk) 10:27, 22 April 2021 (UTC)
- Indeed we need that. And we have it already. We use community_centre=* and community_centre:for=* for this purpose. --Polarbear w (talk) 20:54, 21 April 2021 (UTC)
- I oppose this proposal. I agree completely with Polarbear w. clubhouse is not an top-level tag and the already existing tagging is completely sufficient. When not, it should be extended, not deprecated. --SafetyIng (talk) 19:18, 21 April 2021 (UTC)
- I am not sure how one could extend a tagging scheme when that tagging scheme is misidentifying a feature at its primary level. It doesn't matter what sub-keys we add to amenity=community_centre if a clubhouse =/= a community centre. I understand and appreciate some think a clubhouse is a type of community centre, however, I (and others) don't. Hence the proposal. Casey boy (talk) 10:47, 22 April 2021 (UTC)
- I approve this proposal. --Rskedgell (talk) 19:33, 21 April 2021 (UTC)
- I oppose this proposal. Why shouldn't the club=* key be regarded as a top-level key for exactly this purpose? Like in shop=* where once amenity=shop was used before it was deprecated for a long time... --Kjon (talk) 19:44, 21 April 2021 (UTC)
- some people think that club=* doesn't describe a physical reality and therefore lacks a parent tag when describing a clubhouse. i'm not saying that this argument is correct, on the contrary i think it's debatable. but it does exist and the proposal seems to me to be a coherent way of describing the clubhouse of a club. Marc marc (talk) 23:10, 21 April 2021 (UTC)
- You may want to check the definition of the club key stated in the approved proposal. There it says: "This proposal aims to provide a key for mapping the location where clubs regularly meets." I struggle to find a meaningful difference that requires an additional amenity=clubhouse tag. --Kjon (talk) 08:37, 22 April 2021 (UTC)
- Location alone clearly does not describe an amenity. Sure, placing a POI node for club=* says "a club meets here" but it doesn't say: is this just a spot in a field or is it a clubhouse? Are there different opening hours for the club vs the clubhouse (i.e. does the club only meet at certain times but the clubhouse is open for longer periods)? This clubhouse tag would allow us to map an additional feature, just like we do with leisure=pitch or amenity=parking Casey boy (talk) 10:07, 22 April 2021 (UTC)
- You mention that location does not describe an amenity, yet the very first sentence of this proposal says: A clubhouse is a location (normally a building, though sometimes a building floor or room) that is almost exclusively used, and normally owned or operated, by a club. Using club=* you are perfectly able to specify with kind of location you want to describe by adding either building=*, room=*, community_centre=* or nothing at all if it's just a spot in a field.
- But the amenity=clubhouse tells you it is more than just the location. It tells you that there is a clubhouse at that location. The issue with adding sub-tags to the club=* tag is that club=* can be applied to a single POI, a building, or an entire area with multiple buildings etc. Singling out a clubhouse from that isn't always straight forward and certainly not explicit. Casey boy (talk) 16:54, 26 April 2021 (UTC)
- Also, just to note. I am not suggesting we don't add the club=* tag. Just that it would be complimented with amenity=clubhouse for the club's clubhouse. If the club was just located in a spot in a field, of course you wouldn't add amenity=clubhouse. Casey boy (talk) 16:56, 26 April 2021 (UTC)
- I also don't understand why you mention leisure=pitch or amenity=parking in that context? You should add operator=* to specify that these features are operated by the club; the same is valid for leisure=sports_centre. --Kjon (talk) 11:39, 25 April 2021 (UTC)
- I mention them because they, along with amenity=clubhouse, are separate, unique "objects" that we can map and can all be contained with a larger club area. Yes, we could simply tag a clubhouse as building=yes, operator=* but that doesn't convey the same information (and a club might operate multiple buildings). Some might say this is micro-mapping, but a clubhouse can be the main object people are interested in visiting. Casey boy (talk) 16:54, 26 April 2021 (UTC)
- You mention that location does not describe an amenity, yet the very first sentence of this proposal says: A clubhouse is a location (normally a building, though sometimes a building floor or room) that is almost exclusively used, and normally owned or operated, by a club. Using club=* you are perfectly able to specify with kind of location you want to describe by adding either building=*, room=*, community_centre=* or nothing at all if it's just a spot in a field.
- Location alone clearly does not describe an amenity. Sure, placing a POI node for club=* says "a club meets here" but it doesn't say: is this just a spot in a field or is it a clubhouse? Are there different opening hours for the club vs the clubhouse (i.e. does the club only meet at certain times but the clubhouse is open for longer periods)? This clubhouse tag would allow us to map an additional feature, just like we do with leisure=pitch or amenity=parking Casey boy (talk) 10:07, 22 April 2021 (UTC)
- You may want to check the definition of the club key stated in the approved proposal. There it says: "This proposal aims to provide a key for mapping the location where clubs regularly meets." I struggle to find a meaningful difference that requires an additional amenity=clubhouse tag. --Kjon (talk) 08:37, 22 April 2021 (UTC)
- some people think that club=* doesn't describe a physical reality and therefore lacks a parent tag when describing a clubhouse. i'm not saying that this argument is correct, on the contrary i think it's debatable. but it does exist and the proposal seems to me to be a coherent way of describing the clubhouse of a club. Marc marc (talk) 23:10, 21 April 2021 (UTC)
- I oppose this proposal. This proposal confuses buildings with services. club=* and/or building=clubhouse may serve as less ambiguous alternatives. --501ghost (talk) 22:05, 21 April 2021 (UTC)
- The building=* tag should only be used to describe the building itself not its usage. A clubhouse could be an old building=warehouse, part of a building=hangar, or a simple building=cabin. This amenity=clubhouse instead describes the amenity itself, i.e. the "thing" being used.
- We could potentially consider club=clubhouse (for example) but I'm not sure I particularly see why that has any benefit. Casey boy (talk) 10:22, 22 April 2021 (UTC)
- I approve this proposal. the proposal seems to me to correctly solve the problem described on tagging about community_center and about building=clubhouse (building does not describe the actual use but the appearance of the building, it is totally possible to have a building=house amenity=clubhouse Marc marc (talk) 23:15, 21 April 2021 (UTC)
- I approve this proposal. --Fizzie41 (talk) 00:38, 22 April 2021 (UTC)
I have comments but abstain from voting on this proposal. I want to see whether *=clubhouse will actually be preferred over *=club_home. ---- Kovposch (talk) 07:37, 22 April 2021 (UTC)
- This is a valid point and I understand where you're coming from. You did raise this in RFC but were the only one to do so. I note now that Minh Nguyen has also raised this (and objected to the proposal on this basis). So we'll have to see what happens and perhaps consider a different term if that is an issue. Casey boy (talk) 10:22, 22 April 2021 (UTC)
- I approve this proposal. While distinction between clubhouse and community centre is clear and understandable, there's slight confusion regarding "house" part of the "clubhouse", just as Marc marc described. --Fghj753 (talk) 09:08, 22 April 2021 (UTC)
- I oppose this proposal. I oppose this specific proposal despite using this tag often. This proposal's distinction between clubhouse and parish-hall-as-community-center is quite contrived. What if a parish doesn't rent out its hall? Moreover, this proposal conflicts with the tag's existing usage in the United States: "clubhouse" does not necessarily refer to a club per se. – Minh Nguyễn 💬 09:24, 22 April 2021 (UTC)
- As I've responded to on the discussion page, it's a shame you didn't raise the issue of the term "clubhouse" in RFC as it's something we could have perhaps worked on. Clubhouse is quite clear (at least for me) in British English and this wider usage of clubhouse seems a bit of an Americanism - but is certainly worthy of discussion.
- In terms of differentiation, it's something some people seem to feel very strongly for/against. For me (and others), it's very clear that a clubhouse =/= community centre. Others disagree. Casey boy (talk) 10:22, 22 April 2021 (UTC)
- Yes, it's quite unfortunate and I'm sorry for throwing a wrench into things after you had put so much effort into this proposal. The downside to any tags you like is that there's no good way to know when the tags you like take on a life of their own, other than to keep a very close eye on the tagging list.
:^)– Minh Nguyễn 💬 19:01, 22 April 2021 (UTC)
- Yes, it's quite unfortunate and I'm sorry for throwing a wrench into things after you had put so much effort into this proposal. The downside to any tags you like is that there's no good way to know when the tags you like take on a life of their own, other than to keep a very close eye on the tagging list.
- I approve this proposal. I'm missing a tag like this for the clubhouses of sports clubs, hobbyists, pigeon folk, and scouts. Using amenity=community_centre feels contrived and I feel that it is stretching the semantics of that tag beyond its breaking point. --JeroenHoek (talk) 11:02, 22 April 2021 (UTC)
- I oppose this proposal. I don't see why the introduction of this tag should deprecate any building=*. --Dieterdreist (talk) 21:22, 22 April 2021 (UTC)
- Thanks for the comment. The consensus from those that responded on the tagging mailing list was that "clubhouse" is not a building type and building=* is not used to describe building use. Therefore it would be a mistake to use building=clubhouse. Casey boy (talk) 13:29, 23 April 2021 (UTC)
- Of course clubhouses are a kind of building, have specific requirements that lead to a specific clubhouse design, see for example http://www.fih.ch/media/806437/14-pitches-guide-clubhouse.pdf or https://www.fai.ie/sites/default/files/atoms/files/Clubhouse_Document.pdf or think about clubhouses for golf clubs. The deprecation of buildings with an amenity tag is a reason to oppose for me. —Dieterdreist (talk) 22:01, 23 April 2021 (UTC)
- Not all are. As I explained in the definition, some are simple portable buildings/cabins. That being said, if this relatively minor point was removed, would you support the proposal? Casey boy (talk) 08:35, 25 April 2021 (UTC)
- The question was not, whether all clubhouses are buildings of the clubhouse typology, but whether there is such a typology and whether there can be buildings of such type (because if there can be, then we would not want to deprecate the tag, no?). I would vote yes to the current proposal if the deprecations of building=* and golf=clubhouse were removed (the latter is an old established tag that does not harm and is compatible to be kept in parallel until this can be sorted out later, no need for deprecation at this time). --Dieterdreist (talk) 23:18, 25 April 2021 (UTC)
- Not all are. As I explained in the definition, some are simple portable buildings/cabins. That being said, if this relatively minor point was removed, would you support the proposal? Casey boy (talk) 08:35, 25 April 2021 (UTC)
- Of course clubhouses are a kind of building, have specific requirements that lead to a specific clubhouse design, see for example http://www.fih.ch/media/806437/14-pitches-guide-clubhouse.pdf or https://www.fai.ie/sites/default/files/atoms/files/Clubhouse_Document.pdf or think about clubhouses for golf clubs. The deprecation of buildings with an amenity tag is a reason to oppose for me. —Dieterdreist (talk) 22:01, 23 April 2021 (UTC)
- Thanks for the comment. The consensus from those that responded on the tagging mailing list was that "clubhouse" is not a building type and building=* is not used to describe building use. Therefore it would be a mistake to use building=clubhouse. Casey boy (talk) 13:29, 23 April 2021 (UTC)
- I approve this proposal. I now see the light and how amenity=* is an appropriate key. I think it's easy to distinguish between community centers and clubhouses. --Lectrician1 (talk) 01:49, 30 April 2021 (UTC)
- What if there were two buildings? Both could legitimately be tagged as you described. How would you know which was the clubhouse? Why make people/data consumers infer something, when we can explicitly tag it? Casey boy (talk) 08:35, 25 April 2021 (UTC)
- Give me an example where two buildings would be tagged with this? club=* states it's for any place that a club meets. Clubs usually only meet in one place. I'm not sure 2 places are possible.
- This is interpretation is too narrow. The club=* key has been applied to whole areas (almost like a landuse tag), which may contain multiple objects such as buildings, sports pitches, car parks etc. Just like amenity=school for example. It is entirely possible, therefore, that two buildings will be in the area "where a club meets" (e.g. the clubhouse and an equipment store).
- We should make people infer something because:
- Give me an example where two buildings would be tagged with this? club=* states it's for any place that a club meets. Clubs usually only meet in one place. I'm not sure 2 places are possible.
- What if there were two buildings? Both could legitimately be tagged as you described. How would you know which was the clubhouse? Why make people/data consumers infer something, when we can explicitly tag it? Casey boy (talk) 08:35, 25 April 2021 (UTC)
- I don't find it necessary to simplify 2 tags into 1. I also live where there exists clubhouses for clubs that are contain a golf course, swimming pool, and tennis courts (a "country club"). Using club=sport with sport=golf;swimming;tennis allows me to easily tag these things and still note it's a club. Your tagging scheme still requires 2 tags in this example and offers no simplification: amenity=clubhouse, sport=golf;swimming;tennis.
- I don't want more amenity values.
- I see clubhouses being a building type and use, and the proposed tag doesn't cover both instances and is confusing.
- --Lectrician1 (talk) 16:59, 27 April 2021 (UTC)
- Point 1 - presumably you'd tag each of those individual items though (assuming they're not inside a building)? I.e. you'd draw the outdoor tennis courts and tag as leisure=pitch and sport=tennis? That's all I'm suggesting with the clubhouse. Mapping out a unique object. And just to be clear, I'm not suggesting you don't add the club=* key to the whole area or building (if it's just the one building).
- Point 2 - frankly this is doesn't make sense to me. We aren't limited to the number of values in a key (as far as I'm aware), so if it fits, it fits.
- Point 3 - OK, this I can understand and others have also pointed it out. If I do a future iteration of this proposal, I will remove the deprecation of building=clubhouse from the proposal. Casey boy (talk) 20:14, 27 April 2021 (UTC)
- --Lectrician1 (talk) 16:59, 27 April 2021 (UTC)
- I approve this proposal. --Nacktiv (talk) 20:01, 25 April 2021 (UTC)
- I oppose this proposal. Lacks specificity. What is a club? Any group can call itself a club -- or not. If it calls itself an association or collective, or similar, what to do then ...—Preceding unsigned comment added by RCD49 (talk • contribs) 2021-04-25T22:28:39
- That seems a bit of an odd complaint. Your issue should be more with club=* in that case. Casey boy (talk) 16:42, 26 April 2021 (UTC)
- Not odd for me at all. It translates into "a club is a specific community defined by a common interest", thus subtagging community_centre makes more sense for me than a separate amenity value. --Polarbear w (talk) 23:01, 3 May 2021 (UTC)
- That seems a bit of an odd complaint. Your issue should be more with club=* in that case. Casey boy (talk) 16:42, 26 April 2021 (UTC)
- I have comments but abstain from voting on this proposal. I think that the adoption of the term clubhouse outside the British/American world is negligible and could have a low appeal, hence amenity=club_home would be a better option. Yet I feel the need to tag the home of a club, as I find "club" alone a term that lacks a direct link to the physical location unlike "shop" or "office", as you may also be an active member of a club without meeting physically for most part of the time. In such a case "club_home" could be just a room inside a commercial building mostly offering support services to members.--GOo (talk) 20:25, 25 April 2021 (UTC)
- I oppose this proposal. Same reasons like Polarbear. --TheBlackMan (talk) 06:15, 26 April 2021 (UTC)
- I approve this proposal. --Hike39 (talk) 08:43, 26 April 2021 (UTC)
- I oppose this proposal. Same as Polarbear. --SherbetS (talk) 16:02, 26 April 2021 (UTC)
- I oppose this proposal. Although I grasp the concept and differentiation needed between club houses and community centres, it is unclear to me, both in the description as with the examples how clubhouses located within a community centre should be tagged. Using a node would create an amenity=clubhouse within an amenity=community_centre ? Drawing additional area around an already mapped room, floor or building mapped as area is also not desirable and conflicts with other mapping principles, as they are not separate physical structures. Different and more careful crafted tagging scheme is needed, or the existing maintained as it works fine in most cases when the clubhouse is part of or located in a community centre. The proposed deprecation would destroy this more common and accepted practices. --Bert Araali (talk) 20:19, 26 April 2021 (UTC)
- The proposal specifically states "This proposal does not affect the tagging of clubs which are based in actual community centres." So it's exactly as you said the "existing [method is] maintained ... when the clubhouse is part of or located in a community centre". Does this alleviate your concerns? Casey boy (talk) 09:10, 27 April 2021 (UTC)
- I read that sentence, that you don't change the current tagging of clubhouses in community centres. However I can't find in the page amenity=community_centre what that actually means. Therefore my question, does this mean that those should be mapped as amenity=clubhouse (as a node or as an area ?) within an amenity=community_centre ? If that is the current practice, it doesn't seem to be documented. Describing that current "undocumented" practice (as was attempted on the discussion page) could be helpful and make me better understand the deprecations you propose. Creating a new area around a building NOT along the edges or boundaries of the land use for the clubhouse and it's facilities, is not common what we do for other amenities like amenity=school. So I am not convinced, the proposal might want to address these issues but at least for me I don't grasp it in it's current format, how this can work for most cases. More practical instead of a fictional example might help , improvement of the proposal ? I followed the discussions during the RFC and read those on the discussion page. I mapped only few club houses so far, so try to understand the issues and proposed concept as a "common" OSM mapper. In my opinion you didn't take enough time to address all the concerns and issues raised, the proposal is not mature enough. --Bert Araali (talk) 11:58, 27 April 2021 (UTC)
- I'm not sure why this proposal would describe how to use a different key/tagging scheme? But, for clarity, no, it doesn't make sense to add amenity=clubhouse to amenity=community_centre. As discussed in this proposal, a clubhouse is not a community centre. Instead, if a club is based inside an actual community centre (i.e. somewhere that carries out many of the functions listed here) then ignore this proposal completely and use the current documented scheme of community_centre=club_home (I note it seems that you are saying this use is undocumented but that is incorrect - it's just not documented on the page you'd linked to). Hopefully you agree that this is therefore just a minor point that could be clarified when the wiki page was written/updated if this proposal were accepted?
- Yes, amenity=school maps the whole grounds, but that's just one type of example. Plenty of other amenity=* tags don't follow the same format. Additionally, in some countries POIs are only added as nodes. I don't think it's wrong, therefore, to tag amenity=clubhouse inside a large club=* area if that's what people wanted to do.
- It would also be helpful if you could point out which concerns I haven't addressed (perhaps on the discussion page). As far as I can tell the only ones I haven't are the ones where they fundamentally disagree and think we should keep the approach of merging clubhouses into community centres. The use of "club_home" instead of "clubhouse" and not deprecating building=clubhouse were raised but didn't garner any support until, frustratingly, after voting had started. Casey boy (talk) 15:10, 27 April 2021 (UTC)
- I read that sentence, that you don't change the current tagging of clubhouses in community centres. However I can't find in the page amenity=community_centre what that actually means. Therefore my question, does this mean that those should be mapped as amenity=clubhouse (as a node or as an area ?) within an amenity=community_centre ? If that is the current practice, it doesn't seem to be documented. Describing that current "undocumented" practice (as was attempted on the discussion page) could be helpful and make me better understand the deprecations you propose. Creating a new area around a building NOT along the edges or boundaries of the land use for the clubhouse and it's facilities, is not common what we do for other amenities like amenity=school. So I am not convinced, the proposal might want to address these issues but at least for me I don't grasp it in it's current format, how this can work for most cases. More practical instead of a fictional example might help , improvement of the proposal ? I followed the discussions during the RFC and read those on the discussion page. I mapped only few club houses so far, so try to understand the issues and proposed concept as a "common" OSM mapper. In my opinion you didn't take enough time to address all the concerns and issues raised, the proposal is not mature enough. --Bert Araali (talk) 11:58, 27 April 2021 (UTC)
- The proposal specifically states "This proposal does not affect the tagging of clubs which are based in actual community centres." So it's exactly as you said the "existing [method is] maintained ... when the clubhouse is part of or located in a community centre". Does this alleviate your concerns? Casey boy (talk) 09:10, 27 April 2021 (UTC)
- I oppose this proposal. Same as Polarbear. --Gendy54 (talk) 13:12, 28 April 2021 (UTC)
- I oppose this proposal. Personally, I'm against this tag because I do not see how it adds anything that can not already be done by the club key. Also, a lot of times the distinction between a club, an outreach social facility, or really anything with the word "club" in it (or that's organized) is not clear either. For instance, the Wikipedia definition of a club is "an association of people united by a common interest or goal." Which could really mean anything. So, I don't think any kind of club tags are good. That goes just as much for the "normal" club tag as it does this. You can't fix the problems simply by adding the words "amenity" and "house" to it though. Adamant1 (talk) 08:39, 29 April 2021 (UTC)
- I oppose this proposal. Unstructured tagging makes life more difficult. --WambacherWest (talk) 10:51, 3 May 2021 (UTC)
- I oppose this proposal. The tag focuses too much on the building and is not good for the area around the club.--TheNottingHum (talk) 14:00, 5 May 2021 (UTC)
- @TheNottingHum: Can you elaborate? This statement does not seem to describe the proposal... --Lectrician1 (talk) 15:39, 5 May 2021 (UTC)
- Yes, just for clarity, this proposal would not have stopped you using the club=* tag on the area around the club. This was simply to describe an amenity belonging to the club. Casey boy (talk) 15:49, 5 May 2021 (UTC)
Voting closed
Voting on this proposal has been closed.
It was rejected with 13 votes for, 14 votes against and 2 abstentions.
For analysis, see discussion