[Tagging] Tagging of pitches within a campsite

[Tod Fitch]

> On Apr 30, 2015, at 8:12 AM, Brad Neuhauser <brad.neuhauser at gmail.com> wrote:
> 
> +1 on addr:unit or ref over addr:housenumber. I think ref makes more sense than addr:unit on remote/isolated pitches (ie hike-in sites, not drive-in).
> 
> In addition, I've seen cases where individual pitches are named instead of numbered. It's not mentioned, but to clarify, I'm assuming that would just use "name” 

Sounds like there is a possibility that osm-carto might start showing some information about individual pitches, so maybe we can settle on something.

In the U.S. I see circumstances where addr:unit is the best fit: Mobile home parks and commercial campgrounds like KOA and some county and state park campgrounds that have a street address and the sites/spaces/pitches within are numbered much as apartment units are numbered.

But I also see circumstances where addr:unit, implying there are other valid address tags, is a bad fit: Most public campgrounds in US Forests, US Parks and, at least in California, state parks don’t have a verifiable street address. And backcountry (hike or walk-in) campsites sometimes have numbered pitches but definitely don’t have a street address. For these I think ref=* would be the best fit.

Perhaps this is a case where no one identification standard makes sense: I suggest that pitches be tagged with ref=<number/name> but that in those cases where a valid street address exists for the entire campground, the pitches also be tagged with addr:unit=<number/name>. There would be duplicate information but a campground specific renderer could rely on there being a ref=<identifier> while a more general purpose renderer that is also used for apartments and other commercial building display and navigation would have addr:unit=<identifier> to work with where it makes sense.


> On Apr 29, 2015, at 5:51 PM, Bryce Nesbitt <bryce2 at obviously.com> wrote:
> 
> Which uses newly invited attributes of "water" and "table".  I think it better not to reinvent that wheel, and use instead:
> 
>      camp_site=pitch
>      camp_site:drinking_water=no
>      camp_site:picnic_table=yes
> 
> Or with a more proper namespace:
> 
>      camp_site=pitch
>      pitch:drinking_water=no
>      pitch:picnic_table=yes

The more I think about it, the more I like this example “with a more proper namespace”.

Procedurally, how to go forward? Should this be a new proposal page or an edit of the old subsection of the old camp_site extended features proposal?

Cheers,
Tod

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20150501/a94975bd/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1868 bytes
Desc: not available
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20150501/a94975bd/attachment.bin>