[Tagging] permissive etc. (was Amenity swimming_pool (was Amenity parking))

[Greg Troxel]

Nathan Edgars II <neroute2 at gmail.com> writes:

> On 1/13/2012 7:17 AM, SomeoneElse wrote:
>> When I was adding this:
>>
>> http://www.openstreetmap.org/browse/way/52984927
>>
>> which is something that you do need an actual permit to access (on a
>> horse) I left the horse access as "permissive" but added a note against
>> it. I'm not sure that "access=permit" without some sort of note would
>> make it clear (even to a native English speaker).
>
> If you need a permit, shouldn't it be private?

I see your point, but I think the problem is that we're building an
taxonomy of access rules piecewise by tags, rather than either designing
an taxonomy and then adding tags, or deciding that it's too scary and we
shouldn't.

I wonder what data consumers do with these tags.  I think some of them
get mapped via mkgmap to garmin flags (to avoid routing on private
roads), but I have a hard time seeing how all these nuances would get
used.

I see things as

  yes:
    a right to go there, period
    but with 'fee=yes', not so straightforward

  permissive:
     no right, but not reason not to just go there

  fees:
     the public is welcome to just show up, but has to pay, but it
     may or may not be private, and thus the owner may have a right to
     exclude, even though generally they don't.

  permit:
     this could be easy to get and issued to all who ask, or very
     selective, and it's then very different in tone

  private:
     to me this has the connotation that if you don't already know you
     belong because you have a special relationship, it's off limits


So I'd lean towards access=permit if there is an expectation that anyone
can get a permit, and access=private if that isn't true.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20120113/8c74f30a/attachment.pgp>