<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">On 27/03/2015 6:31 PM, Jan van Bekkum
      wrote:<br>
    </div>
    <blockquote
cite="mid:CA+9j5RTRFjRxnhgkhYUOg4HJSm9c2Jt6zsQ_0fixnvPspXotQA@mail.gmail.com"
      type="cite">
      <div dir="ltr">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.
        <div><br>
        </div>
        <div>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.</div>
        <div><br>
        </div>
        <div>Let's take as an example a campsite with restaurant and
          shower.</div>
        <div>For tagging a restaurant plus showers that belong to a
          campground different approaches can be chosen:</div>
        <div>
          <ol>
            <li>The node or area tourism=camp_site gets one attribute
              amenity=restaurant;showers.<br>
              Advantage: (1) evident that shower and restaurant belong
              to campground, (2) no new tag definitions needed<br>
              Disadvantages: (1) additional attributes for individual
              amenities (like opening_hours=* not possible, (2)
              difficult to render</li>
            <li>New attributes are created such as restaurant=yes,
              showers=hot, restaurant:opening_hours=*<br>
              Advantage: (1) evident that shower and restaurant belong
              to campground, (2) attributes for individual amenities
              possible<br>
              Disadvantages: (1) duplication of tag definitions for the
              same object (amenity=shower and shower=hot), (2) difficult
              to render</li>
            <li>Separate nodes for campground and amenities<br>
              Advantages: (1) no new tag definitions needed, (2)
              attributes per amenity straightforward, (3) no rendering
              issues<br>
              Disadvantages: (1) not evident that campground and
              amenities belong together, (2) placing of nodes incorrect
              if layout of camping area is not known</li>
            <li>Separate nodes for campground and amenities connected in
              a site relation<br>
              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<br>
              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.</li>
          </ol>
          <div>All in all I personally prefer option 4.</div>
        </div>
      </div>
    </blockquote>
    <br>
    For me .. Number 4. <br>
    <br>
    ----------------------------
    <div>
      <div>The incorrect layout of nodes within the area;<br>
        conveys the information that they exist and<br>
        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. <br>
        <br>
        Option 4 is easy, simple, effective and adds no new stuff to
        OSM. 'Just' needs documentation for camp_sites? <br>
      </div>
    </div>
  </body>
</html>