The tag access=permit is intended for cases where permits are routinely issued to everyone who just asks. This situation is common for nature preserves in the United States.
We are direly missing a tag for cases where a permit is not routinely granted. Currently the solution the wiki suggests is using private. In practice; permit is often misused for this case.
That’s why I started a draft to fill this gap. I drafted two alternatives that I’m asking the community to help choose between. Alternatives to the exceptional_permit term are also welcome.
For the car-free zone in the examples, I assume that there are thousands of people who do have a permit. They still cannot access private roads of other people.
With more specific tagging, routers have the possibility to take this into account and to let the user select that they have this specific permit.
I see what you are trying to do. For this to work well, you should know not who is the authority giving the permits but also the different types of permits they issue (on which area exactly, conditions maybe, for whom ?) It could be just access to a specific work or place for some people, general access for others.
I’m not interested in recording too much information directly in OSM. I don’t think it belongs here. The proposed tagging does however leave the possibility to create an external database to record details.
This is exactly what I’m proposing, did you get confused along the road or am I missing something?
Or would it be more effective to iteratively refine access=permit? Despite the wording of the access=permit draft proposal, access=permit is already routinely being used for a variety of permissiveness, anything from “just ask” (some protected areas) to “boarding pass required” (after security at an airport) to “resident permit only” (street parking). It was inevitable given the plain English meaning of the word “permit”. Some of these uses have already been tagged with permit=* or parking:*:permit=* to clarify the intent.
Routers don’t necessarily distinguish between access=private and access=permit in the manner that one might think after reading the relevant wiki pages. Some routers ignore access=private at the beginning and end of a route if doing so would get the user closer to their destination. Valhalla equates access=permit with access=residents, but both behave just like access=yes, which is an oversimplification even in the case where access is routinely granted. (Don’t you still have to ask for the permit? Wouldn’t that potentially require a detour or at least a delay?)
I suppose this isn’t the best photo to illustrate the article as worded. In this particular case, the Cranberry Bog State Nature Preserve requires you to obtain a permit at least two weeks in advance. You wouldn’t know from the sign on the ground by itself; you’d be expected to call the number to learn that the router effectively led you to a dead end.
But residents is =private . This can be fixed. The difference that can be made is whether there are individually assigned parking spots, which may not be within the scope of access= .
Boarding pass may be considered =customers , and clarified with eg customers | Keys | OpenStreetMap Taginfo (N=537 ; although being used for freeform text directly in a disorganized manner) . The issue of lounges can be handled similarly.
That isn’t decisive. =private doesn’t mean “individual”. You may not be able to park in others’ spots in a “private” carpark, or enter others’ properties in a gated community/estate/complex. But they are still =private inside.
Maybe the documentation is not clear enough, but this is not quite right. Generally you have to apply for a permit ahead of time – could be just the day before, but in popular areas up to a year ahead of time may be required . Even if routinely granted, the application may be a bit of a process, and it’s not necessarily as simple as just asking.
Also although permits may be routinely granted, they can be limited. Only 100 per day might be issued for a given area. This can be done on a first come first served basis, or a lottery system for extremely popular areas. For example: Inyo National Forest - Recreation Passes & Permits
A lottery system of course means that an individual is not guaranteed a permit even though permits are routinely granted in general.
I also like this idea. Although the aforementioned documentation suggests access=private to encapsulate situations wherein a permit is required in advance or otherwise limited in quantity, this feels idiosyncratic when associated with e.g. a piece of otherwise-public land.
Perhaps an alternative to access=private in these scenarios is to encourage the development of a permit=* tagging schema that can be used to describe the type of permitting system being used (e.g. walkup, lottery, etc.)
I’m happy to see a proposal draft in this space; thanks for starting the discussion.
I really like the idea that several people have suggested of using access=permit for all types of permits (including those that may be in limited supply or need to be obtained in advance), since this seems to match the common usage already. I also like using permit=<type> or something like that to describe the type of permit system in more detail.
One thought: permits are sometimes granted in multiple ways. For example several popular wilderness areas in Washington State, USA require permits for overnight camping. You can get a permit either by entering a lottery at the beginning of the year (often 6+ months before your desired entry date), or you can visit a ranger station the day before your start date and inquire about a “walk-up” permit (some of the available permits are specifically set aside for this purpose). Not sure if that complexity is necessarily worth documenting in OSM, but thought it was worth mentioning.
I wonder if permit:website would be useful, similar to reservation:website which tells you where you can go to make a reservation at a business/attraction. (Since this is often a different URL than the main website of the thing).
