<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>