<div dir="ltr">Apply 3 in case all amenities fall in 1 area.<div>Apply 4 in case they are in separate areas.</div><div><br></div><div>Use 1 only in a first iteration when no more details are known.</div><div>don't like 2 at all :-)</div><div><br></div><div>I think camp sites are no different that large factories, schools, universities etc. in this respect.</div><div><br></div><div><br></div><div>regards</div><div><br></div><div>m</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 27, 2015 at 8:31 AM, Jan van Bekkum <span dir="ltr"><<a href="mailto:jan.vanbekkum@gmail.com" target="_blank">jan.vanbekkum@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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><br></div><div>Opinions?</div><div><br></div><div>Regards,</div><div><br></div><div>Jan van Bekkum</div><br></div><div><br><div><br></div><div><br></div></div></div>
<br>_______________________________________________<br>
Tagging mailing list<br>
<a href="mailto:Tagging@openstreetmap.org">Tagging@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/tagging" target="_blank">https://lists.openstreetmap.org/listinfo/tagging</a><br>
<br></blockquote></div><br></div>