Proposal talk:Access=permit

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)

I think it would be better to make a separate proposal for hunting=*, fishing=* and trapping=*. --Tractor (talk) 07:51, 4 August 2016 (UTC)

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
for everyone	access=permissive	booking=only?
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?

--Fkv (talk) 11:16, 11 August 2016 (UTC)

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

To me a permit is something you must obtain before accessing the feature (road or path). How that permit is obtained, limits on the procedure etc are all secondary things, first OSM needs the detail that a permit is required for access. Secondary tags can be developed as mappers come across the need for them .. permit:website=* for example. But first OSM needs access=permit. Permissive to me means it is open to the public now, but that can be withdrawn at any time. Private means it is not open to the public. Permit means that you need this permit. Warin61 (talk) 06:13, 23 December 2018 (UTC)

Thanks for the great write-up and explanations. I think this tag would handle a use case of mine perfectly and that it should be used and adopted. I'm tagging fishing ponds, located inside a U.S. military base, that are stocked by the State of Alaska and open to the public with the single requirement that a special permit must be first obtained. Because the ponds are stocked with fish I would like to be able to signify that in my tagging along with the permit requirement. The combinations fishing=stocked, and access=permit fits that bill admirably. I don't agree that access=private applies to such permit situations as some have argued. They are rather more akin to access=public than access=private or access=permissive. AlaskaDave (talk) 12:35, 18 September 2017 (UTC)

Tagging guidelines

This is a good proposal which fills a gap in the access tagging, and I support this proposal. We have also identified several cases in Hungary where the current access=XXX values cannot accurately express the real conditions. Those areas are frequently controlled by guards and entry without permission may lead even to prosecution. However, access permits can be obtained by anyone after a simple registration, e.g. for recreational purposes. For routing, it is highly desirable to distinguish roads/areas where access is not possible for the general public (access=private) from facilities for which permit can be easily obtained.

For the sake of tagging, I'd suggest to provide a bit more elaborated tagging guidelines with some negative examples. The purpose is to clarify difference between access=permit and other values for more consistent tagging, especially considering boundary cases. My initial suggestion is as follows.

Use access=permit whenever:

• individual permission is needed to access roads and/or other facilities.
• permit is available to the general public and not restricted to certain groups, occupations, affilitations or similar
• permit conditions are well-known, non-discriminatory and not overly narrow. In the simplest case, permit is automatically issued after registration or similar formalities. In other cases, the permit conditions may require certain skills, knowledge or expertise obtainable by anyone e.g. for entering hazardous zones
• the permit may be free of charge or the issuer may require a fee for the permit. In the latter case, the fee is only to cover administrative costs rather than making business by selling access rights

Negative examples: do NOT use access=permit for

• Toll roads, where a fee is assessed for passage, and the only precondition for access is paying the fee. Use access=yes and toll=yes instead
• Closed industrial or governmental areas where access permits are not available to the general public. Use access=private instead
• Private roads where passage is allowed to the general public until revocation. Use access=permissive instead

--Gmatefi (talk) 21:32, 23 August 2018 (UTC)

If permit is not to be used for permits that are obtained by certain groups, where skills are required etc then how are they to be tagged? OSM does not restrict other access values but allows groups etc. Why put that restriction on access=permit? The permit system used on any feature could have any requirements for the granting of the permit, just as an access of private could have any requirement for the granting of access. Warin61 (talk) 22:00, 23 August 2018 (UTC)

The most important access values (yes/no/private/permissive) are already defining the permissions for the general public. The interest for this new tag is similar: tagging roads/facilities where permit can be easily obtained by anyone, irrespectively of his/her group affiliations. The existing "private" value is already defined for cases where "individual permission is needed" and can be used when permits are only obtainable by certain closed groups (personnel, employees etc) as of today. Without this separation, meanings of "permit" and "private" would be highly overlapping and this new tag would be pointless. --Gmatefi (talk) 17:43, 24 August 2018 (UTC)

I think there is a confusion between 'permit' and 'permission'? they do overlap.. so I see the confusion. A permit usually has a formal process that is gone through to gain permission, this I would tag access=permit. Possibly this restriction could be used in this instance? Example: the permit must be given by some formal application? Where as a private area may simply require contact, possibly by a phone call, to gain permission ... an informal process possibly with out paper work, money exchange, this I would tag access=private. If the permit requires someskills then possibly that can be indicated by a sub tag e.g. permit:requirement=electricians_licence ??? Warin61 (talk) 23:38, 24 August 2018 (UTC)

I understand your point, but I think your use cases are different from the ones discussed in this proposal. If you look for the examples here, the key discrimination criteria is being the permission/permit available for the general public or not. In my view, the top level access tagging should always discriminate based on the permission types of the general public, i.e. for ordinary map users. Then secondary level tagging could be used to add further details, like the permission process type (formal/informal), contacts etc. Also, secondary level tagging could be used for elaborating specific permissions for certain sub-groups e.g. for electricians, if their permissions are different from the general public's ones. Our interest is restricted for tagging cases where the "permit is available for the general public". It would be the best to draft a separate proposal on sub-group permission tagging, if you see valid use cases, to give more space for their discussion. --Gmatefi (talk) 10:07, 25 August 2018 (UTC)

To me the main characteristic of a permit is that it is a physical item that you need for access - a paper, a card, a badge your must wear, or a sticker on your car, etc. There is also the process needed to obtain one - the ones I am familiar with require filling out forms and/or presenting valid identification documents. For tagging it shouldn't matter if the permits are only granted to certain groups. In my area there are a lot of parking lots that are open only to town residents who have a permit displayed on their car. It make sense to me to tag this with access=permit and permit:requirement=town_resident and if needed permit:requirement_1=fee. Of course there should also be a scheme for directing people to where/how you get the permit, maybe permit:obtained=townhall. I think someone already mentioned a permit:website=* tag.—Rassilon (talk) 22:27, 28 January 2019 (UTC)

Why not new tag?

For example access=private with access_with_permit=yes? It will not require adjusting from everybody processing access tag Mateusz Konieczny (talk) 15:47, 3 September 2018 (UTC)

Normally extra tags are used for describing additional properties or for adding more details to a feature. With your proposal, "access_with_permit" would be an exemption if it would be defined only for a particular access value to override its default meaning. We cannot prevent mappers to use any syntactically valid tagging combinations, but would we be able to interpret those unambigously? E.g. "access=no;foot=permissive;bicycle=customers;access_with_permit=yes" - what would be the correct meaning? Or just opening the door for confusions? --Gmatefi (talk) 19:59, 11 September 2018 (UTC)

For an actual example near me, the access rights are "access=no;foot=permit;bicycle=permit;motor_vehicle=permit;snowmobile=no;ski=yes" (you can drive, hike, or bicycle on the logging roads with a permit; in the winter, you can freely access them by ski but not snowmobile). "access=no;foot=private;bicycle=private;motor_vehicle=private;snowmobile=no;ski=yes;access_with_permit=yes" is ambiguous: does it apply to all the private access modes, or just some of them? --Carnildo (talk) 16:58, 13 September 2018 (UTC)

Security-related access restrictions

I think this tag could also be useful for distinguishing between POIs before and after airport security controls: one has to secure a permit (a boarding pass) and present some existing permit (proper papers) to enter the security area. Similarly, concession stands and restrooms in a American football stadium are always located past security, so merely specifying opening_hours="on game days" isn’t enough to prevent a search engine from suggesting these POIs as accessible facilities. – Minh Nguyễn ^💬 15:26, 21 November 2019 (UTC)