I like the direction this is going. A couple of things come to mind though. If we use the model requiring different amenities to flesh out the description of the site that will require a separate node for each of them. The nodes will be hard to place unless you actually visit the campground in question. Being an armchair mapper I use the Internet to determine a great many of the details of the things I map. I won't be able to add nodes using that scenario. The category approach might be easier except in the cases where a site has all of the basics but only some of the luxury items; which category applies?
Relations make a lot of sense except they are tricky to get right. Noobies will inevitably screw them up. Plus, I'm still looking for a way to force simple site relations to render on my Garmin. I realize this is not a propoer issue to raise here but I also know some of you are wanting a way to use the data you've added to OSM to help find these places at vacation time. Just a few thoughts to add to the mix... On Wed, Mar 25, 2015 at 3:43 PM, David Bannon <[email protected]> wrote: > > Warin suggested new category names and implied meanings. Think it was a > quick draft, I have a counter "quick draft" along same lines. > > On Wed, 2015-03-25 at 11:06 +1100, Warin wrote: > > None= nothing other than an area to pitch a tent or park a vehicle. > > Basic = None + a toilet > > Standard = Basic + water > > Comfort = Standard + shower > > First Class = Comfort + cloths washing (+ power?) > > Luxury =Comfort + camp kitchen/swimming pool/restaurant > > David's model (camp_site=* ) - > Basic = nothing other than an area to pitch a tent or park a vehicle. > Standard = Basic + toilets and water > Serviced = Standard + shower + power > Fully_Serviced = Serviced + camp kitchen + Laundry > Deluxe = Fully_Serviced + swimming pool/restaurant > > And define all the other aspects with additional tags. Good so far. But > I am sure someone can think of an anomaly. > > BUT - its silly to have all those other things (mostly amenity=) on one > node or area. So, now we need to define different nodes. And that leads > to having to establish exact location of each. Thats too much trouble in > many cases. I don't know .... > > Jan suggests a relation to link them all together, makes sense to me, > but does it make sense to renderers and thus end users ? I've never used > relations, seems the docs concentrate more on when not to use them. > > Jan, I am really sorry to be suggesting such drastic changes to your > proposal so late but I think might be more acceptable to the community. > > David > > > > > > _______________________________________________ > Tagging mailing list > [email protected] > https://lists.openstreetmap.org/listinfo/tagging > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com
_______________________________________________ Tagging mailing list [email protected] https://lists.openstreetmap.org/listinfo/tagging
