[Tagging] Tagging method of amenities at camp_sites

[Jan van Bekkum]

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.

Opinions?

Regards,

Jan van Bekkum
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20150327/348f1f40/attachment.html>