[Tagging] Feature Proposal - RFC - Subkey camp_pitch:*
tod at fitchdesign.com
Thu Apr 11 14:25:21 UTC 2019
> On Apr 11, 2019, at 1:01 AM, Joseph Eisenberg <joseph.eisenberg at gmail.com> wrote:
> Thank you for your comments, Graeme
>> aren't you duplicating everything that exists under the
>> tourism=camp_site & caravan_site pages ?
> This proposal is for designating features that are available at
> individual spots for one tent or one caravan (normally, although I
> suppose a group tent site could also be tagged within larger
> campground). They key tourism=camp_site or tourism=caravan_site should
> be used on the area of the whole campground or caravan site.
> The tag camp_site=pitch_site is only used if there are multiple
> designated pitches within the site.
> So these subkeys were made to define if there are certain amenities or
> facilities available at an individual pitch, eg: do you have your own
> picnic table, fire ring, drinking water tap, electrical outlet, and
> parking right at the pitch?
> It would also be possible to map every feature with separate nodes, eg
> amenity=drinking_water on a node marking the location of a water tap,
> but if every pitch in a large campground has a water tap, this could
> lead to rather crowded map renderings.
More than just crowded map renderings. Consider the case of a camp pitch with a picnic table, fire place, parking and water tap that are for the exclusive use of the people camping at that pitch. If you tag it with:
Oops, can’t put multiple amenity tags on one object. And every time someone suggests formalizing a scheme for formalizing multiple values it gets bike shedded or worse.
So now you are having to use multiple objects for the camp pitch which leads to the issue of showing association (now we need a site relation or equivalent). And since these features can be for the exclusive use of the people occupying the site, we need to show some sort of access restrictions. Basically, it gets much more messy if we don’t have camp_site sub keys that implicitly show association and access restrictions.
Going over the old list of sub keys, I can see where some of them are probably not desired. “Surface” may be one, especially if the camp pitch is mapped with a polygon. Would surface still work if the pitch is only mapped with a point (that seems to be true of highway=turning_circle so a precedence has been set)? If so, then camp_pitch:surface could be removed from the proposal.
But it remains that some features of a camp site pitch that we have general tagging for if they are stand alone items are more easily mapped and represented with their mutual associations and access restrictions if we use sub keys.
More information about the Tagging