I like the values you proposed (the camp_site=opportunistic_hospitality email) and option #4 here - if the relation values are straight forward, then people will make the jump to learn it.
I also suggest a fallback note on the proposal,, such "as map the area, amenities, and information as best as possible, and create a new “map note” on the main OSM view to ask for another mapper to complete the relation/mapping.” This way the only thing left to do for a more experienced (but less familiar with the site) mapper is to make the relation. I look around my area every month to see if there are any new anonymous repair tags people have added to the map, so it could get fixed that way. are fixme= notes also acceptable? Javbw > On Mar 27, 2015, at 4:31 PM, Jan van Bekkum <jan.vanbek...@gmail.com> 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: > 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 > 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 > 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 > 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 > > > > > _______________________________________________ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
