|Status:||Draft (under way)|
|Definition:||Access requires a permit, ordinarily granted|
In the United States, at least, there is a fairly common situation of lands, roads, and barriers that require some sort of permit to pass, but where the permit is granted routinely on condition of complying with certain formalities. In many cases, the permit is free of charge and requires only notification to the operating agency.
To a US map user, there is a significant difference between this sort of routinely-granted access and access=private. In the former case, there is a known policy of granting access to all comers (perhaps having to register a specific date, win a lottery, pay a fee, or simply fill out a form). The access terms are well-understood and do not discriminate on the basis of residency in a gated community, membership in a club, occupation (e.g. only emergency service workers), religious affiliation, or similar condition.
By contrast access=private indicates that a private landowner may decide to grant or deny access for any reason or no reason. access=no appears to be even more restrictive - indicating that the granting of access is an exception to the general rule of denying access to anyone but the landowner.
It is common practice for US maps that are produced for hikers, skiers, horseback riders, cyclists, hunters and fisherfolk to render the common cases of "public land open to all comers," and "land accessed by permit" disinctly, and both distinctly from "private land, no trespassing" (which is generally the default). Since things that are tagged alike cannot be rendered differently, some sort of tagging to distinguish these cases is desirable.
Many parks and wild-land regions in the US, and some roads, paths, or places of entry to these regions have a permit access system. These range widely in complexity of the regulations, and from the point of this proposal, a full schema of access conditions is formally out of scope. (See the next section for what is proposed.)
Most US National Parks require permits for access to 'backcountry' areas that are not developed for tourism. These range in formality from merely needing to reserve the intended dates of travel (to ensure that the number of simultaneous travelers does not overstress the resources), to complex and highly competitive lottery systems such as the one in use in Yosemite .
Many State Parks in the US have similar reservation and permitting systems, such as the the one in use in Baxter State Park in Maine . Again, these have highly variable constraints. Baxter State Park's is complex because of usage pressure. By contrast, the permit  for the Eastern High Peaks region of the Adirondack Park in New York is obtained at a trailhead or ranger station on entry to the region, and the process is simply that the hiker or skier fills out and signs a carbon-paper form at a kiosk, keeps one copy, and drops the other in a letter box.
Other authorities have similar systems. For instance, the New York City Bureau of Water Supply owns several hundred parcels of woodland in the Catskill Mountains and the Croton River valley, far from the city itself, that it purchased to protect the quality of the water that enters its aqueducts . Many of these are open to public recreation. Others require a permission card that can be obtained immediately and free of charge on the city's web site .
Many private landowners such as clubs also offer public access, often by offering "day use memberships" or similarly termed arrangements. These are often offered to anyone willing and able to pay a fee, and are not conditioned on any particular residency or affiliation. A typical example may be found at .
In the State of New York at least, there is also a program  where the state encourages rural landowners to open their lands to recreational users (and allows them to put constraints on the use). It's called "ASK", and while it does not guarantee nondiscriminatory access, it at least indicates that the landowner is willing to be asked and sometimes grants permission to strangers. Associated with the program is a standard permission card  where the visitor agrees to comply with the landowner's instructions, to conduct activities in a safe, responsible and lawful manner, and to absolve the landowner from liability except in the case of willful or malicious failure to guard from or warn of hazards, and the landowner agrees to allow access for a given purpose at specific dates and times with specific limitations. In practice, the landowners who participate in the program do not ordinarily discriminate. They find that responsible visitors are their eyes and ears against poachers, vandals, and hazardous conditions, and on the whole feel that they derive a net benefit from responsible and law-abiding visitors. (By contrast, posting the property against trespassing has the effect of excluding only the law-abiding visitors that the landowner would like to have.)
Others have proposed similar tagging for such facilities as parking lots whose use is by permit only, private roads requiring permits for vehicles, and similar facilities. The proponent of this proposal imagines that access=permit might well apply to these cases, but has considered only the specific cases of the outdoor recreational features that he desires to render on his own maps.
Expansion of the access tag
The access=* tag shall be expanded to support the following value:
The transportation_mode specifies the vehicle category or transportation mode to which the permit applies, e.g., foot, horse, bicycle, motor_vehicle. It is permissible to omit the leading access: in from of the category if a transportation mode is specified. See Key:access#Transport mode restrictions for the full hierarchy of transportation modes.
Three additional values for the transportation mode also appear to be useful for the application that the proponent envisions:
These three tags indicate whether the property is open to hunters, fishers, and trappers respectively. There are a great many combinations possible here, and the proponent has seen many in the field. Not only does one encounter "this property is open to foot travelers, but hunting and trapping are forbidden," but also "permits are granted to hunt and fish on this property, but foot travel for other purposes is ordinarily forbidden."
(The proponent will be willing to withdraw these three tags or consider them separately if the consensus is that they should remain out of scope.)
Permit contact information: the permit:* keys
If access=permit or a transportation-mode-specific equivalent is present on a feature, then the feature SHOULD also include one or more tags of the form
where the contact_key is one of phone, email, fax, website, or one of the addr=* keys. (Presumably the other keys listed on the contact=* page might also be relevant, but it is hard to imagine permits, for instance, being issued via Facebook!)
The transportation mode may be omitted even if it was supplied on the permit tag. This important special case allows for a single set of permit contact information. It is common that permits for all allowable transportation modes are obtained from the same source with the same formalities.
Since permit terms and conditions can be fairly arbitrary, no attempt is made in this proposal to present a formal schema for them. Instead, the contact information indicates where those who want access can obtain more information. If a set of standard patterns for permit-based access emerges, obviously more tags in the permit:* hierarchy could be invented. (permit:fee comes immediately to mind as a possibility, but all such tagging is intentionally out of the scope of this proposal.)
All of these tags may apply to a node (such as a barrier=gate), a way (often a highway=*), or an area (denoting an area of land for which permission is required to enter or to travel on other than established ways). Often an area will also be tagged with boundary=protected_area, leisure=park, leisure=nature_reserve, landuse=forest, or some similar tagging identifying an administrative area to which the permit condition applies.
The proponent does not envision that the the map will need to render access=permit differently unless it otherwise has a different rendering for the access=* tags. If it does, rendering it alike to access=private is likely good enough for the main map.
Maps produced specifically for outdoor recreationists will likely treat the different access=* values differently. It is common to show access=yes areas with some treatment such as a green shading near the border of an area, access=permit with another color such as pink, and access=private or access=no with a color or fill pattern warning the user not to enter. Rendering these last two explicitly is ordinarily required only when a visible path traverses such an area.
This proposal, if accepted, will require that appropriate changes be made to the access=* page to add the permit value; a new permit=* page to document the values that provide contact information for obtaining more information about a permit, and an appropriate discussion in the conditional restrictions page.
There are a couple of moribund proposals from some time ago for a permit relation and for a access=license tag. This proposal is similar to the latter (the former, in the opinion of the proponent, is considerably more unwieldy). It attempts to distinguish the permit case from both private and yes, to add contact information about how a permit may be obtained, and to provide specific examples of the types of features that are envisioned. There is also mention in passing of a permit_holders value in the page on conditional restrictions, but it is not developed and not enumerated in the formal syntax given; it appears to be residue from an earlier draft of the page.
The term permit was chosen in preference to license or licence at least in part because it is spelt consistently in US and British English. It also appears to be marginally more popular in existing tagging, although both usages are uncommon at best.
This general function has been requested repeatedly. Several topics on the discussion page for the access key refer to it. It was also the subject of a lengthy recent thread on the 'Tagging' mailing list. No existing tagging scheme appears to suffice for the desired function.
Please comment on the discussion page.