Proposal talk:Extend camp site

camp site numbering

How about using addr=housenumber for campsite numbers, and have a tag like camp_site=numbers so programs can pick it up as a POI. Then use ref=* for any description --MikeyCarter 00:53, 18 August 2010 (BST)

I would prefer ref=* cause this are no common address like housenumbers, just for internal use on a single camp site. But dunno how to build a good POI out of it --!i! 06:33, 18 August 2010 (BST)

capacities

Capacities for tents, caravans and cabins could be specified in a scheme similar to the one proposed in http://wiki.openstreetmap.org/wiki/Proposed_features/More_Parking_Spaces. Perhaps these should be using some sort of predicates like accommodation_type:durable/short=yes/no/NUMBER.

There is allready the capacity=* key system, why no capacity:tents? More over I think we should distinguish the number of tents in places free for everyone and places for long time camper? --!i! 13:28, 27 December 2009 (UTC)

capacity=* sounds reasonable, I changed the proposal accordingly --Augustus.kling 19:02, 29 December 2009 (UTC)

capacity:tents=yes sounds pretty strange to me. Anyway if the majority prefers this, I will not oppose. --EvanE 21:37, 14 January 2010 (UTC)

What is the information for long time camper good for? These places are not available for short term campers. But even if the capacity is given, you can't assume that places are available at any given time. You always have to go for reservation if you are traveling in holidays or other busy times. --EvanE 21:37, 14 January 2010 (UTC)

If you preffer a small more private camp_site it is nescesarry to get the number of places. The specific attributes might be interessting for statistics IMHO. But ok your right it miss a direct usage, doesn't it? --!i! 06:16, 15 January 2010 (UTC)

animals

Instead of an animal tag it was proposed to annotate the property equal to access permissions such as dog=yes/no.

Have a look at See Animal. They use a very similar system. More than dog or horse wouldn't make sense, doesn't it? --!i! 13:32, 27 December 2009 (UTC)

Horses could be interesting, too. --Augustus.kling 19:02, 29 December 2009 (UTC)

Of course, the mentioned article knows horse=yes/no allready. --!i! 12:04, 6 January 2010 (UTC)

Animal is as of today a german only page. It's even not a proposal. To say it friendly: they are idling. --EvanE 21:51, 14 January 2010 (UTC)

All right but why to reinvent the wheel? I guess they allready thaught about a good scheme. --!i! 06:18, 15 January 2010 (UTC)

Being an german-only proposal has the disadvantage, that people might not understand the meaning of the proposal or details theirof. We might reuse their work anyway, if we find it adequate for our needs. --EvanE 20:48, 17 January 2010 (UTC)

Yes but ATM it is a good base that could be converted if it changes in future. They represent the animal acess restrictions in buildings, so IMHO it is ok --!i! 08:29, 18 January 2010 (UTC)

OK, let's use it. --EvanE 00:57, 19 January 2010 (UTC)

memberships

Memberships of sites in associations shall be given in another relation. These relations are not part of this proposal.

Isn't a tag association=ADAC,Tourismusverband,.... more usefull? At the moment there's only the use for a website catalogue. Right relations are a better collection approach but they are difficult to handle (how to find a relation for a specific organisation?) so this would --!i! 16:31, 26 December 2009 (UTC)

I think, we should not do the work of camp-site operator or related organisation. IMO the website is sufficient. Beside, handling multiple entries, which would be necessary, seems to be a problem. --EvanE 22:01, 14 January 2010 (UTC)

Ok but at the moment that cooperation is the main reason for this extension proposal and therefore it would be nice if we can deal with this task or? It would be a good example of how OSM can be used by organisations and how they can benefit from a cooperation. The enumeration is IMHO uncritical but I agree that a relation is the better way --!i! 07:44, 15 January 2010 (UTC)

If someone creates a relation with all the camp_site of one association, I don't mind. But that's a more general problem, concerning a lot of features like shops, fuel, hotels, restaurants, societies and a lot more. At least everthing that might have an operator tag. So let's stay with These relations are not part of this proposal. --EvanE 21:20, 17 January 2010 (UTC)

You are right :) --!i! 08:30, 18 January 2010 (UTC)

caravan_site separated?

What is the difference between camp_site, caravan_site and camp_ground? If you respond to this please also mention to which region/dialect you are referring to. Perhaps there is a better wording that unites all three. If so existing tags could be mapped to a new scheme (after vote).

tourism=caravan_site Is a place, where cou can park with a caravan overnight or for longer periods. It is allowed to sleep there, but camping is usually not allowed and beside toiletts there is usually no infrastructure available.

In my opinion the use is very mixed. I guess the most users would think that it's a camp_site. caravane_area would be more clear? --!i! 12:06, 6 January 2010 (UTC)

Look at the Kicking Horse campground in Yoho national park of Canada. Near the campground entrance there is a large caravan_site for those unlucky people, who didn't get a place on the campground, but need a place to stay overnight. I hope, this clarify the differences. --EvanE 22:18, 14 January 2010 (UTC)

Ok so I think we have to make more clear, that it is more a parking place than a camp site. --!i! 06:20, 15 January 2010 (UTC)

Just adding amenity=parking like here should make things clear. --EvanE 21:27, 17 January 2010 (UTC)

tent/caravan areas

To allow the operator to tag the seperated areas for tents there might be a camp_site=tents/caravan area. --!i! 13:28, 27 December 2009 (UTC)

See the striped and checkerboard areas in example 2 (was added in the meantime). It uses tents=yes and caravans=yes to express such usage restrictions on areas. I propose this tagging instead since it mirrors the access restrictions in use for animals more closely. --Augustus.kling 12:41, 13 January 2010 (UTC)

I prefer the original tent=yes/no/number. Their might be several areas where tents are allowed, each with its own capacity. The same goes for caravans. --EvanE 22:31, 14 January 2010 (UTC)

site / relation

I would prefer, if all these tags operator=*, naturism=accepted, ... would be a properties of the relation and not of the area outline. It is quite common, that camping sites have disconnected areas (e.g. left / right of the road). Then this would lead to redundancy. --Bk 12:41, 14 January 2010 (UTC)

I don't think that we should tag such things on the relation. Tagging these properties/attributes on the contained objects is simpler and allows them to differ. This is illustrated in example 2 where the camp site is tagged with naturism=accepted but the store on the site is tagged naturism=no and thus overwrites the former. Inheritance of values could be solved. However that requires a more general discussion than a camp site proposal could provide.

Does it make sense to use a separate mulipolygon relation for the camp site and contained areas to disambiguate further?--Augustus.kling 21:58, 14 January 2010 (UTC)

Well you are right it is logical to tag common attributes to the relation but remember that it is more complicated that to tell somebody just to add it to a node. --!i! 13:59, 14 January 2010 (UTC)

Tagging the relation instead of the area has some drawbacks. Neither does the common mapper understand relations very well nor have relation a good support in the three major editors (Potlach, Merkaartor, JOSM). Properties inheritat from a relation are not immediate visible while editing. Seeing only a part of all properties is disturbing. As of today there isn't even an idea how to solve this inappropriated visibility. --EvanE 00:02, 15 January 2010 (UTC)

Regarding split areas: I am not aware of any such camp_site. The mileage outside Europe / North Amerika may vary. Anyway if you encounter such a camp_site you have two ways to solve this problem. First you can use several members with role outer, second you can handle the parts as separate camp_site which share the same operator. I prefer the later. --EvanE 00:02, 15 January 2010 (UTC)

Site perimeter as multipolygon

Similar to the established tagging for German boundary=administrative, the different parts of the camp site are combined to a multipolygon relation tagged as type=mulitpolygon tourism=camp_site All other tags for the camp site go here, too. Then this relation is added to the site relation with role perimeter.

I realize this may seem like an overkill to some, but it would be optional and seems to me the natural way to handle these cases. --Bk 16:00, 14 January 2010 (UTC)

That is fidling with relation just for the sake of relations. I don't see any practible value. --EvanE 00:02, 15 January 2010 (UTC)

roles in site relation

It says:

Put everything that is part of the site as members of the relation. Roles are to be given as follows 
  outer: for the enclosing way or node tagged with tourism=camp_site 
  inner: objects that are on site 
  external: objects that belong to site but are located off-site

In this proposal, the site relation is used in no way different than it would be for a school, university and so on. So if you really need to extend the site feature, the right place to suggest this would be the discussion page for the site relation

(Apart from that I don't really like this suggestion: These roles are geometrical in nature, but a site relation is a logical grouping. However the site-area could get role=perimeter as suggested on the discussion of the site relation.) --Bk 16:12, 14 January 2010 (UTC)

I see your point and thus suggest to leave the role as undefined/empty. Adding roles to site relation should be proposed at the site proposal's discussion page.--Augustus.kling 21:58, 14 January 2010 (UTC)

The site proposal suffers from diverging interest. We shouldn't rely on its uncertain future. Other than a university which might spread over several places, camp_site usually are closed areas with only a limited number of external points nearby. The broad approach of the site proposal is not necessary for camp_site. On the other hand can an approved relation for camp_site support the development of a broader site relation. --EvanE 00:02, 15 January 2010 (UTC)

The problem is the wording for the roles. Regarding the choice words, inner and outer are opposite. But if you look at the meaning, inner and external are opposite. Furthermore there is possible mix-up with the already established multipolygon relation. The meaning of outer is the same, but inner means something different here, which is a little irritating. Why is it useful to tag inner / external anyway? --Bk 00:36, 15 January 2010 (UTC)

The roles 'inner' and 'outer' are chosen according to multipolygon-relations. If there is no external member they are merly identical. On the other hand we sometimes need things which are outside of the physical camp_site but belong to it because it is only available for camp_site users. Otherwise a 'simple' multipolygon-realtion would be sufficient. --EvanE 22:05, 17 January 2010 (UTC)

It is simply not compatible! For multipolygon, the role inner describes holes in the area. But here the role inner does not mean to "cut something out of the site" but it means "the element belongs to the site". These are totally different meanings, but described by the same word. It shouldn't be like that - maybe we can just change wording of the roles. --Bk 23:27, 17 January 2010 (UTC)

Oh, this stupid example. Multipolygon relations describe in no way holes in an area. It expresses a geometric relation, namly one or more area(s) (inner) completly within another area (outer). That's all about it. In this sense you might say: The inner areas belong to the outer area. Beside giving a hint to renderers multipolygon states a (at least geometric) relation between inner areas and outer (surrounding) area. So we are completly compatible. --EvanE 00:52, 19 January 2010 (UTC)

More properties

The following could be added:

• areas for season campers. These are often separated.

I agree but this would make the capacity tag more complicated (tents, caravans, bucks) and for each a season version. Wouldn't it would confuse the editors if capacity:tents=capacity:tents_season+x? --!i! 20:10, 14 January 2010 (UTC)

I don't think it makes much sense to specify the capacity here. (Would be the same as for normal guests, somehow.) But there is often an distinct area for these long time campers and it could be mapped as such. It's like landuse, but on a smaller scale. :) --Bk 01:10, 15 January 2010 (UTC)

Ok so as a second option let's specify the number of capacity=number and capacity:season=number directly at the tent=yes,caravan=yes,cabins=yes areas to make it more detailed? Sounds good :) --!i! 07:55, 15 January 2010 (UTC)

Like I explained on topic capacities there isn't much sense in specifying long-time campers. There might be one exception, if there is a seperate area for long-time campers not availableto short-time campers. --EvanE 22:27, 17 January 2010 (UTC)

AFAIK this is allways the case --!i! 08:35, 18 January 2010 (UTC)

No there might be all kind of mixed regulations. Even new regulations every season are possible. --EvanE 01:24, 19 January 2010 (UTC)

Instead of complicating the capacity=*-tag I would propose to introduce a new tag camp_site=long_term/short_term/mixed --TRex 15:59, 24 November 2010 (CET)

• Different Opening_hours:
  • for the reception (The time where you can arrive, check in and check out.)
  • restricted times, when it is allowed to drive on and off the site by car
  • times when visitors are allowed
  • also interesting: Is it open the whole year or at what months is it usually closed?

It is quite difficult to get this informations doesn't it? But I see the last one is very interessting to search for a camp_site that is currently opened. --!i! 20:10, 14 January 2010 (UTC)

No, not if you are at the site. At least it needs to be specified, what is meant by the opening_hours tag. A closed gate does not necessarily mean, the reception is not occupied. (Maybe they just have quiet time and don't want to have cars driving around.) The first point I wrote is still the most important, I think. --Bk 01:10, 15 January 2010 (UTC)

If you're on site you should be able to get any disered information directly. Unlike the key opening_hours suggests you can any kind of opening-time: hours (of course), hours per day of week, days, month, opening-season. Please look at the description at Key:opening_hours for details. --EvanE

It says "Limitations on access to site. Could be a gate closed during the night or a different season". I just liked to point out that the meaning of this is not really fixed: There could be times when the gate is open; times when the gate is closed but guests can use a keycard; times when the keycard does not work (night and quiet time). But all this is not really important as you can find it out when you are there. I think opening_hours should instead specify the times when the reception is open and check in / check out is possible. --Bk 23:38, 17 January 2010 (UTC)

OK, change the text to Limitations on access to site for customers. Can express everything from daily openening hours over opening hours at specific days of the week or a holyday up to season limits and all together. Check-in/out you do only once per visit. Entering/leaving the camp_site is everyday usage and thus of major importance. --EvanE 01:24, 19 January 2010 (UTC)

Not really. These access times for customers are usually quite similar / reasonable and so of minor importance. (Although access might be restricted for motor cars, you can always park in front of the site and get in on foot. So it's not a big deal if you like to go out all night. :) ) However imagine you have a long journey and need accommodation for one night. Then the opening hours of the reception is very important information and it can vary a lot. --Bk 11:34, 19 January 2010 (UTC)

I think we should give a simple example for opening_hours directly in the draft.

How would it be tagged, if a camp_site is open from April till October and the gate closes from 22:00-07:00. --Walterschloegl 09:56, 28 February 2010 (UTC)

• What kind of lavatory is available (flush toilet, squat toilet, outhouse, ...) Interesting for people that expect western comfort.

Isn't comfort modelled by the "stars"=* system (tag:tourism=hotel) allready? I think this might be a direct option of tag:amenity=toilets--!i! 20:10, 14 January 2010 (UTC)

OK, this belongs to amenity=toilets. --Bk 01:10, 15 January 2010 (UTC)

Star system will work in western countries, but is non-existent in Africa. Therefore the lavatory tag as proposed is really useful: flush, squat, longdrop

• Prices for accommodation. Some might not like to see things like this in osm, but it is really useful information and sometimes not available otherwise. --Bk 13:16, 14 January 2010 (UTC)

I don't think that it is good to add this cause: it might motify for edit-wars. We link to the contact informations website=[http://... ''http://...''] so it's a short way to get the current prices. And the pricemodells are quite complicated (price for what, how long, with car,...) --!i! 20:10, 14 January 2010 (UTC)

Water:

Instead of fresh_water=yes/no (which seems to be a new OSM tag) I would suggest:

drinking_water=yes/no if there is drinking_water available, and

watering_place=yes/no if there is a possibility to fill the water container of a camper. (e.g. with a garden hose)

amenity=drinking_water,watering_place to tag the nodes extra. --Walterschloegl 09:59, 28 February 2010 (UTC)

I will mention drinking_water, but think that watering_place will not be understood correctly. Instead a open water area such as a bath or drinking place for animals we be assumed. I guess fresh_water or possibly fresh_water_supply are clearer.

I agree, that water_point is better understood for getting large amount of water. So drinking_water and water_point can be used instead of fresh_water and watering_place --Walterschloegl 20:46, 1 March 2010 (UTC)

I am seeing lots of Campgrounds with non-potable water faucets in many locations for hand/dish-washing. It isn't big enough to be a water_point, so would this apply as...

amenity=watering_place

potable=yes/no --Hockeyrink 19:27, 3 August 2010 (UTC)

I suggest using drinkable=* instead of potable=*. According to Tagwatch drinkable is used 764 times compared to 3 uses of potable. --Augustus.kling 01:20, 4 August 2010 (BST)

Power-Supply:

For power_supply=* I would suggest

power_supply=yes/no/iec60309/typ_f according to

http://en.wikipedia.org/wiki/IEC_60309 (very common on camp_sites)

http://en.wikipedia.org/wiki/Mains_power_systems (not a norm, but a common lettering system and much easier to tag than the norm).

typ_f would represent Typ F here, which is the equivalent to norm CEE 7/4 (=Schuko). --Walterschloegl 10:03, 28 February 2010 (UTC)

Only stating IEC60309 is not enough as it defines a range of different socket/plug types.

I'd like to use this type system since it's a lot easier. Where do these types come from? http://www.ita.doc.gov/media/Publications/pdf/current2002FINAL.pdf ? If so, does the type system contain all types that are to be expected on camp sites?

I think we can't trust too much in the mentioned document as it states types A, C, H for Scotland where C, G would be correct. Also, as far as I know, there are multiple type L sockets/plugs used in Italy. If I'm correct with this (and they are used on camp sites) we need to be able to specify the types further.

• Please have a look at the power_supply definition, if this is ok so: http://wiki.openstreetmap.org/wiki/Key:power_supply --Walterschloegl 17:39, 5 March 2010 (UTC)
• At http://wiki.openstreetmap.org/wiki/Talk:Key:power_supply I've proposed to use plug type based tagging like plug:cee_7_4=yes, unified with proposal for EV charging station plug tagging (like plug:chademo=yes). Joosep-Georg 22:23, 2 January 2013 (UTC)
• I propose to add "part_time" as a possible value for campings where electricity is available part time, for example in the evening only when the generator runs or if supply is unreliable. These are common situations in Africa. On the other hand I doubt if "type_f" adds value. The default for "yes" is the local plug. It can only be interesting in countries with a mix of plugs, for example Zimbabwe uses the UK as well as the South African style plug. So the tag would become: power_supply=yes/no/iec60309/part_time.

"Food Storage:"

In bear country, bins to store food may be provided at some sites. Knowing where these are in the backcountry can be quite important. I suggest amenity=food_storage. Brianegge (talk) 03:15, 14 August 2014 (UTC)

Short stay possible?

Hi, I've seen campings that rent "places" indiscriminate to the equipment used for camping. So, for instance when staying for one night with one tent and one adult, it can still cost 15 Euros on a "Mini-camping" or on some campings up to 20(!) Euros. Therefor it might help to add a tag ShortStay/Short_stay. It would help to prevent expensive surprises ;-)

You are right, this is a very interesting scenario, but nevertheless are price-related stuff the right things for OSM? --!i! 20:02, 11 July 2010 (UTC)

I would argue that instead of giving price information the minimum and maximum length of a stay should be given. What do you think about introducing minstay=* and maxstay=*? Especially minstay=* would give an indication if the camp site intends to take guests for just one night (minstay=1 night) or not.--Augustus.kling 18:04, 15 July 2010 (UTC)

15 January 2017 rtfm Similar to "Short stay possible?" : motorcycle_friendly

Often on "family" campings, bikers aren't welcome. Additionally, there might be a possibility to dry clothes.

This tag doesn't only affect tourism=camp_site but also tourism=guest_house and tourism=hotel.

So mainly for information purpose here's the link to the proposal:

https://wiki.openstreetmap.org/wiki/Proposed_features/motorcycle_friendly Cheers, rtfm

Private and semi-private camps

How would you tag camps that are not available to the general public? (e.g. camps that are owned by a religious organization and only available to that organization's members) Would you use access=private? What about camps that require you to join some sort of camping association (similar to a youth hostel association), but anyone who pays the fee can join? Would this get the same tag? --ToddDTaft 13:15, 22 December 2010 (UTC)

I don't see a way in this proposal to differentiate between a camp that primarily provides a place to sleep (but may provide other optional services, such as food or live entertainment) and a camp that provides a "full service" program. By "full service", I'm referring to camps (often for children) where you sign up for a session of one or more weeks, and the camp staff provides all meals, daytime and evening activities (arts & crafts, swimming, sports, etc.) as part of the camp fee. --ToddDTaft 13:15, 22 December 2010 (UTC)

Terminology

The English word is campsite, not camp site. A campsite is often a designated location for a single tent, trailer, or RV, contrasted to a campground, an aggregation of campsites and infrastructure. —Michael Z. 2011-07-16 16:22 z

I agree that “camp site” sounds foreign and a campsite is much smaller than a campground. My preference would be amenity=camping. (I find the whole tourism=* tag an inaccurate generalization; many many hotel guests and museum visitors are not tourists. -T99 08:43, 17 August 2011 (BST)

I agree - we need something to differentiate between a single campsite and the enclosing campground. Brianegge (talk) 12:17, 27 November 2014 (UTC)

Re: "The English word is campsite, not camp site." - that's correct, but we are stuck with this tag, I think.

Re: "A campsite is often a designated location for a single tent, trailer, or RV, contrasted to a campground, an aggregation of campsites and infrastructure." - that's incorrect. You are thinking of the definition of "campsite" in American English, I think. Apparently in British English the word "campground" is not used, with "campsite" having a similar meaning. "Pitch" is used for a tent or caravan (RV) site - usually for 1 vehicle or tent, though sometimes for 2 or a group. See tourism=camp_pitch for these features, parts of a campsite (aka campground) --Jeisenbe (talk) 00:23, 3 July 2019 (UTC)

Icons/Rendering

There are suggestions as to the Icons to be used. Where the feature/key already exists use the recommended Icon/Rendering for consistency across the map. E.G. Toilet, shower already have icons .. using T or S simply adds to the number of things to remember .. and why should it be different to a toilet or shower outside the campsite? Warin61 (talk) 3 February 2015 (UTC)

Tent areas .. rather than black rectangles .. what about a green tent symbol - easy to under stand? Same for caravan areas - a yellow caravan symbol? Warin61 (talk) 3 February 2015 (UTC)

motorhome_site ?

I think there is some confusion in caravan_site, in uk this a place where hundreds of 'static caravan sites' where people leave a caravan year.

So how to tag the places where you can park and spend the night with campers rather than a real camping ?

I have ask it in the help ,the proposal was an extension of camp_site.

To goal is well to tag area like describe in the wiki : http://wiki.openstreetmap.org/wiki/Tag:tourism=caravan_site

a place where people with caravans / motorhomes / recreational vehicles can stay overnight, or longer, in allotted spaces known as "pitches" or "sites".

Bear cache

Can't seem to find a tag for bear caches (bear proof boxes for storing food near a campsite). If anyone knows of something otherwise should come up with a proposed tag such as Amenity=bear_cache. DFyson (talk) 07:14, 20 August 2016 (UTC)

Rentals

As in boat_rental, different accommodations are proposed for rent in camp sites in my country- I don't know elsewhere. It would be possible to add those proposals: Tent_rental=yes/no and MobileHome_rental=yes/no. Those are often weekly rented(from a Saturday to the next). And tag won't be acceptable as an amenity. It could even be camp_site=MobileHome_rental and camp_site=Tent_rental as they are not offered in other places.--Bewam (talk) 14:31, 28 September 2016 (UTC)

Pods

There's a new trend called "Pod", something like a wooden tent, 2 examples :

• http://www.giteslecreux.com/minicamping.html
• http://www.campinggranbosco.it/en/pod

See also Glamping

I would define these as bungalows and tag them accordingly. IrrerPolterer (talk) 10:55, 14 September 2024 (UTC)

Where to assign address?

I have a small problem with Campingplatz Offenbach-Bürgel:

• Street address (number 400) is already assigned to the restaurant building
• ... but it would be good to give the address to the restaurant and to the camping area itself

Shall I duplicate the tags onto other objects even if the number belongs only to the building?  « Saper // @talk »  20:58, 28 May 2017 (UTC)

Why not use amenity=reception_desk instead of camp_site=reception?

User:Jeisenbe, could we please discuss this?

camp_site=reception The reception which is usually located at the camp site's entrance - please consider using the more universal amenity=reception_desk instead if the position is known, otherwise you may add reception_desk=yes, though that is less useful Bkil (talk) 15:35, 10 April 2019 (UTC)

While camp_site=reception is not an approved feature, it has been in use since 2009 and is used 1017 times (https://taginfo.openstreetmap.org/tags/camp_site=reception) compared to only 302 uses for amenity=reception_desk https://taginfo.openstreetmap.org/tags/amenity=reception_desk

Also, the tag amenity=reception_desk was rejected several times (proposal 1 & 2, proposal 3, proposal 4, proposal 5) due to several issues with the tag. Several commenters thought it was too ambiguous.

Camp_site=reception is clearly a specific feature within a campground, and it can be used on a whole building, rather than on the location of a desk.

You are free to start a new proposal for amenity=reception_desk or something similar, but rejected tags shouldn't be recommended on unrelated pages, especially on abandoned proposals. --Jeisenbe (talk) 02:41, 11 April 2019 (UTC)

Although, I've seen hundreds of reception areas/points/desks in my life, I haven't seen any camping receptions recently, so I couldn't tell what kind of differences to expect. If you separate features by function, a building is a separate entity that can be seen from a distance by the campers, while toilets or the reception is a distinct feature that campers should seek inside, so it rarely makes sense to combine them.

I'll try to go through the comments again to better understand the reason for the resistance and what we can improve to map this world-wide notable phenomenon and perhaps propose another name for the tag.

I'm coming from the direction of reusability: we don't have separate tags for playground=entrance, bar=entrance, allotments=gate, farm=gate etc, instead we try to unite the tagging of common concepts. Without giving much consideration, camp_site=reception, hotel=reception, motel=reception, guest_house=reception, school=reception, office=reception, community_centre=reception, sports_centre=reception, events_venue=reception sounds pretty excessive to me and I could go on forever with this list. The concept of ticket vending booths and guest information tables/points/terminals as well that are loosely related, as they also serve a similar purpose of checking in and providing guidance. The worst part of this is that guest_house/hotel/etc is a value token in this context, not a key token, so it feels a bit off. Also, lots of the affected keys are already taken and used for a different meaning to represent "kind", and suggesting different naming/tagging schemes for different kind of POI to represent the same concept would not be wise. All else equal, I would still prefer reception=camp_site/office/hotel/motel/etc more for this reason, as this would enable making reception=* a primary tag later on, but I'm still open to suggestions regarding the exact naming. Bkil (talk) 12:08, 11 April 2019 (UTC)

A campsite reception is usually a separate building next to the main entrance. Or at less developed campgrounds it might be a caravan. It's the place you check in and pay, and usually has the office in back.

Office, hotel and motel receptions are a bit different. Usually office and hotel receptions are a desk next to a lobby. A hotel will usually have just one, but an office building can have many receptions for each business. A motel may occasionally have a clearly separate building where you check in, but I think of that as the "lobby" of the hotel, with the reception desk just a part of that. So these features are not quite as important or as easy to map as a separate reception building at a campground.

Perhaps tagging the main entrance for a hotel, motel or office building is enough. --Jeisenbe (talk) 12:35, 11 April 2019 (UTC)

It looks like not all of my reasoning has gone through, but no worries. I've been to hotels/guest houses that encompass multiple buildings, do not have a clear main entrance and have functional units scattered through the complex (like reception, accounting, kitchen, laundry, cloak room, chill room). It doesn't make a feature more or less separate if it is encompassed in a given structure/building. What determines a feature is what a typical map user would want to accomplish there, and check_in/reception=* is a typical first point of contact. It should be up to a mapper whether she thinks that the given feature on the ground would be useful to map, we can't know that from a distance. It is hence best to design and offer mapping options for all reasonably expected use cases beforehand, as if mappers start to come up with their own ad hoc solutions on the field, things could get ugly - conflicts ahead. Receptions can offer various services that we can not be sure about from a distance (like valuable depository, mail handling, cloak room, payment, reservation, billing, bar, lobby, ...). Office buildings can have a main reception near the entrance and as you've mentioned separate receptions per company (even multiple ones if they have cargo/delivery/kitchen receptions as well), but I don't see an issue with that. My aim is not to map each and every chair and table in a small, straight forward office building, rather provide guidance for mappers how they can map this for complicated scenery when in need. entrance=main is already mappable and I do tag that as I see fit, but as already mentioned, this is not always enough, and we need something when it is not enough. --Bkil (talk) 16:58, 16 April 2019 (UTC)

Moved content: additional tags

In July 2017 a user added this long list of new tags to this abandonded proposal page. I've moved them here. They should be proposed in a new proposal, if desired. Most of the tags below are undocumented. --Jeisenbe (talk) 02:45, 11 April 2019 (UTC)

water_quality=potable/non_potable Quality of the water

I'm sure such tagging should be universal over OSM. See drinking_water:legal=* at natural=spring Bkil (talk) 12:49, 11 April 2019 (UTC)

water_location= central/at_site Location of the water at the campsite

This doesn't sound objective and verifiable enough. The key naming is not the best either. As such a high level property, I don't see people searching for this. It is much more useful to add drinking_water/water_point/water_tap as a separate POI. Bkil (talk) 12:49, 11 April 2019 (UTC)

toilets_position=sitting/squat Toilet use

toilets_disposal=flush/longdrop Toilet disposal

See toilets:position=* and toilets:disposal=* in amenity=toilets that applies to venues in general. Bkil (talk) 12:49, 11 April 2019 (UTC)

big_rigs=yes/no The site is accessible for trucks, etc. This is similar to tents=yes and caravans=yes

I'm not completely satisfied with this word. Bkil (talk) 12:49, 11 April 2019 (UTC)

kitchen=yes/no Availability of a kitchen for guests

This should apply to other tourism providers as well (hostel, motel, etc.). Bkil (talk) 12:49, 11 April 2019 (UTC)

Shop=yes/no Availability of a convenience store for guests

Don't use upper case in keys, also shop=yes is an already taken primary tag, meaning that this POI is a shop but of an unknown kind, both of which are false in this case (i.e., a camp_site is not a shop, and its type is shop=convenience in most cases). Although the same issue comes up when tagging amenity=fuel, we should probably create a new tag for this. Bkil (talk) 12:49, 11 April 2019 (UTC)

dish_washing=yes/no Availability of basins for dish washing

The key is misleading - it reads as if they provide a service for washing your dishes. Bkil (talk) 12:49, 11 April 2019 (UTC)

laundry=manual/machine/no Availability of a basin for laundry or a washing machine

See washing_machine=yes at amenity=washing_machine Bkil (talk) 12:49, 11 April 2019 (UTC)

dryer=yes/no Availability of a laundry drier

bar=yes/no Availability of a bar

fee=* Campground fee

See fee=* - the actual amount should go into another tag, like charge=*, price=*, fee:amount=*, fee:price=* or something else Bkil (talk) 12:49, 11 April 2019 (UTC)

swimming_pool=yes/no Availability of a swimming pool for guests

pets=yes/no Admittance of pets

See dog=*, Proposed_features/pet Bkil (talk) 12:49, 11 April 2019 (UTC)

payment:credit_card:uplift=* Fee uplift is payment is made by credit card

fenced=protecting/non_protecting/no Is the site fenced and does it protect against intruders?

See barrier=fence, fence_type=* Bkil (talk) 12:49, 11 April 2019 (UTC)

guarded=day/day_and_night/no Is the site guarded and when

See supervised=* Bkil (talk) 12:49, 11 April 2019 (UTC)