[Tagging] Tagging method of amenities at camp_sites

Warin 61sundowner at gmail.com
Fri Mar 27 08:01:34 UTC 2015


On 27/03/2015 6:31 PM, Jan van Bekkum wrote:
> This is a spinoff of a discussion that was started in the mail trail 
> about the proposal for camp_site=* that is currently open for 
> comments. I would like to limit this discussion to facilities for the 
> entire campground, not individual pitches. Similar questions will 
> apply to other situations than campsites.
>
> Certain amenities that are offered with campgrounds have their own 
> namespace key. Examples are restaurant, bar, shop, shower. Others like 
> toilets and internet can be attributes under tourism=camp_site.
>
> Let's take as an example a campsite with restaurant and shower.
> For tagging a restaurant plus showers that belong to a campground 
> different approaches can be chosen:
>
>  1. The node or area tourism=camp_site gets one attribute
>     amenity=restaurant;showers.
>     Advantage: (1) evident that shower and restaurant belong to
>     campground, (2) no new tag definitions needed
>     Disadvantages: (1) additional attributes for individual amenities
>     (like opening_hours=* not possible, (2) difficult to render
>  2. New attributes are created such as restaurant=yes, showers=hot,
>     restaurant:opening_hours=*
>     Advantage: (1) evident that shower and restaurant belong to
>     campground, (2) attributes for individual amenities possible
>     Disadvantages: (1) duplication of tag definitions for the same
>     object (amenity=shower and shower=hot), (2) difficult to render
>  3. Separate nodes for campground and amenities
>     Advantages: (1) no new tag definitions needed, (2) attributes per
>     amenity straightforward, (3) no rendering issues
>     Disadvantages: (1) not evident that campground and amenities
>     belong together, (2) placing of nodes incorrect if layout of
>     camping area is not known
>  4. Separate nodes for campground and amenities connected in a site
>     relation
>     Advantages: (1) no new tag definitions needed, (2) attributes per
>     amenity straightforward, (3) no rendering issues, (4) evident that
>     campground and amenities belong together, (5) acceptable rendering
>     even if relation isn't properly handled by rendering software
>     Disadvantages: (1) placing of nodes incorrect if layout of camping
>     area is not known, (2) use of relations felt to be difficult by
>     some mappers.
>
> All in all I personally prefer option 4.

For me .. Number 4.

----------------------------
The incorrect layout of nodes within the area;
conveys the information that they exist and
are not too much trouble to correct when that data becomes available.  
In fact it makes it easier  for the correction - just move the node.

Option 4 is easy, simple, effective and adds no new stuff to OSM. 'Just' 
needs documentation for camp_sites?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20150327/42b5e3f8/attachment.html>


More information about the Tagging mailing list