[Tagging] Camp Ground Categories - Tagging established, unofficial and wild campings

Dave Swarthout daveswarthout at gmail.com
Wed Mar 25 12:36:10 UTC 2015


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 <dbannon at internode.on.net>
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
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>



-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20150325/3b0c8451/attachment.html>


More information about the Tagging mailing list