Please discuss the proposed access=permit feature here.
Washington State Parks pass
Would the Washington State Parks "Discover Pass" be considered a case of "access=permit"? I think it's more akin to the common case of paid parking because (a) it's only for motor-vehicle parking -- if you enter the park by any other means, including being dropped off by a driver who isn't staying, it's not needed, and (b) many of the more popular (or more remote) sites have provisions for on-site purchase of a daily or yearly pass. --Carnildo (talk) 07:29, 2 August 2016 (UTC)
New York has a similar program, and I'm inclined to agree with you that you're describing paid parking. If a motor vehicle can enter to drop off, then we wouldn't previously have labeled it motor_vehicle=private. I've seen other discussions suggesting that we don't have a really good tagging scheme for parking, either, but that's not the purpose of this proposal. Kevin
Expansion on the access tag (hunting, fishing, trapping)
Me, too. I was merely pointing out the fact that "foot access limited to specific purposes" is not ideally modeled by this proposal. I'm happy to leave hunting, fishing and trapping out of scope for now. Kevin
at least 2 dimensions
Your wide range of examples makes access=permit seem too unspecific. Permit can be granted to everyone who wants, or to people who pay for it (i.e. customers), or randomly (lottery). Permit can be requested immediately, or you need to apply months in advance. These distinctions are essential for applications. E.g. if permit is granted immediately to anyone who registers at the entrance, a routing application can safely route you over that path. When you need to register at another place, the router should offer you an intermediate stop there. When you need to win a lottery the year before, the router should avoid the path.
For some combinations, existing tags can be used:
|immediate permit||preparation required|
|whoever the owner likes||access=private||access=private|
|payment required||access=customers / fee=* / toll=*||access=customers / fee=* / toll=* + booking=only?|
|lottery||access=random?||access=random? + booking=only?|
Is there a way to approach this problem without trying to boil the ocean? There are so many variant conditions for permits that I don't foresee an automated router ever really taking advantage of such a scheme, other than possibly having an ID for a permit type and a way to have a collection of objects that assert, "I have permit type X." Besides, most of my examples apply to large outdoor tracts, and the idea of using a router on a back-country trek is kind of mind-boggling. Route-finding is part of the challenge.
Where I started out wanting to go with this: it's pretty conventional locally for trail maps to indicate the borders of where one may venture. There are typically only a few different treatments: "open to the public", "open to permit holders", "private with an arrangement for trail usage, stay on the trail (roughly the same thing as access=permissive)", "keep out". Right now, all that I can do in terms of producing an open version of that sort of map is to show "keep out" for everything that isn't "open to the public," because all of the cases I mentioned fall under access=private today. Is there a way for me to get to the point where I can render such a map as a data consumer, without needing to both design and parse a schema describing all the possible conditions for obtaining a permit?
It's possible that the same purpose could be served by adjusting the understanding of what access=private means today. Right now, I don't see a useful difference between access=private and access=no. In both cases, there's some access and someone who is authorized to grant it, and in neither case is there an expectation that permission will be grant it. But I don't expect that to happen since the use of both tags - meaning the same thing, as far as I can tell - is already entrenched.
It's all well and good to want details - and I want them, too! Remember, though, that map renderers have to wade through the details unless there's a simple tag that encompasses them, and that mappers have to enter the details. I can tag highway=footway and have the result be useful immediately, then go back and add surface type, width, difficulty grade, etc. later to make it even more useful. Similarly, there's a high-level distinction between "permission must be negotiated on an individual basis," and "a permit must be obtained, and there's a recognized process for obtaining one." That distinction could then be elaborated into some sort of representation of the conditions. I had hoped that including a contact schema would at least allow us to place access conditions in the human realm, and not foreclose on adding an electronic schema for the common cases later.
In general, I think - for any feature - that it's poor policy to reject it as "insufficiently fine-grained", unless it rules out by design the possibility of circling around and adding the details later. Kevin
- I don't see much of a chance to add details later. The normal way to add details would be subtags, but these don't work well with access tags. Therefore, any access tag value should have a clear-cut meaning by itself. When the meaning is "there's a recognized process for obtaining a permit", it is a superset of access=customers, and it is also implied for every feature tagged with fee=yes or toll=yes. You could also set access=permit on every single country, because you need a visa or at least get through border controls and customs to get into that country. In order to drive a car on public roads, you need a driving licence and a licence plate, each of which you get by a recognized process, so every "yes" value for motor vehicles on OSM_tags_for_routing/Access-Restrictions would need to be replaced with "permit". But what about the "destination" values etc., we cannot combine them with "permit". We could merge them using a semicolon (motor_vehicle=permit;destination), but that would be logical "or". We need a logical "and", which we cannot do.
- Your proposal is really well and carefully done, but the more I think about it, the more it seems to me that "permit" does not really fit into the access tag hierarchy. Access tags should stand for who has or gets a permission, not what process it takes to get that permission. What about new and independent key like permit=registration_at_entry/registration_offsite/online/lottery ?
- --Fkv (talk) 05:19, 12 August 2016 (UTC)
- It needs at least some tie to the access hierarchy, to allow for cases like 'ski=yes snowmobile=permit'. I'm entirely open to adding a key like 'permit:method=*' (or 'snowmobile:permit:method=*' if different modes require different permits), or whatever keys you think you need. (I won't promise to fill them all in when I map!)
- I gave a bunch of heterogeneous examples, but I'm leaving the process for getting permission deliberately out of scope. In fact, the very heterogeneity is why I'm leaving it out of scope - it belongs to the human domain, and I'm trying not to have to encode all the possible rules. Saying that I must encode them, and then come up with a way of classifying them in order to make the simple yes/permit/no distinction on a paper map, is really defeating most of the purpose. It also puts me right back in my current condition for every new permit regime that I encounter. At some point, the details belong to the human domain. They're not something that a router, say, will ever make sense of.
- The purpose of 'access=permit' is to detail that the answer to 'who has or gets a permission' is 'everybody'. But 'access=yes' isn't right, because there are formalities that have to be dealt with in advance. (As opposed to most of the government lands in the Adirondack Park, say, where anyone can just walk in at any time.) 'access=private' or 'access=no' (and I still don't understand the distinction between these) also aren't right, because they strongly connote 'stay away' - if I don't have an invitation, I have no reason even to think about asking permission. 'access=customers' feels like a very poor fit. I mostly see it on parking facilities and service ways, which are usually signed 'parking for customers only' or some such. If I saw it on a tract of forest, I'd have absolutely no idea what business I might hypothetically be favouring with my custom. 'access=destination' also doesn't fit; I generally see that on ways posted 'no thru traffic'. I might put 'access=destination;forestry' on some of the ways leading to the trailheads. I can drive my truck on them, but if I'm not a contractor for the Finch-Pruyn Lumber or International Paper, only for the purpose of going to the trail. I'd also mark most of them as 'high-clearance vehicle' since they have many more rocks and tree roots than are ordinarily found in a public road.
- I wonder if you're still approaching this from a motor-vehicle perspective, or from a point of view limited to automated routing. In those domains, I expect 'access=permit' to be at best an uncommon case. (In fact, I can't really think of one, and it seems to me that a motor vehicle router could simply treat 'access=permit' in a similar fashion to 'access=private'.) On the other hand, it's quite common indeed for recreational access to public lands in the US - neither common enough simply to assume it, nor rare enough simply to ignore it or sweep it up under 'access=private'. In places where there are lands of both sorts, maps produced for outdoor recreationists virtually always render yes/permit/no differently. Kevin