<div dir="ltr">Going over old ground once more: The proposal is abandoned based on<br>strong opposition from the community. I am told that access=permit is<br>the same thing as access=private (which, as far as I can determine, is<br>also no different from access=no). I accept that.<br><br>Warin's opinion is an obvious community consensus. I don't like the<br>consensus. I don't agree with it. But I respect it.<br><br>There are numerous protected areas in my part of the world where<br>access is granted to all comers subject to certain minimal formalities<br>- which may be as simple as going to a Web site, entering contact<br>information, and checking a box that states that you've read the<br>relevant regulations and agree to comply. I want to be able to render<br>these areas on trail maps as distinct from both 'access=yes' and<br>'access=private' because to my mind they are distinct. Specifically,<br>they are places where I have a reasonable likelihood of being able<br>to plan travel, but are flagged that I need to research further. (As distinct<br>from access=private, where if I don't know the landowner, I'm<br>likely NOT to be able to plan to cross. Nevertheless, it's clear that to<br>the hive-mind of the community, they are one and the same.<br><br>I would prefer to produce my trail maps based on OSM data, rather than<br>maintaining secondary information in a private database because the<br>information I want to render doesn't fit in the OSM schema. But I'll<br>go to the work of maintaining the private database in order to respect<br>the community consensus.<br><br>I haven't gone to the trouble of retagging the areas currently have<br>the now-deprecated 'permit' tag - I simply haven't managed to muster<br>very much enthusiasm to do so, partly because I haven't yet worked out<br>the schema for the external database that I'd need to rework my<br>rendering. It's just not been urgent, since nobody's seen fit to<br>disturb the 'permit' tags that I already added. The rendering that I'm<br>using still works for now.<br><br>Proposing that OSM make this distinction was a mistake. I was simply<br>wrong to imagine that enough other people would want what I want. Some<br>data do not belong in OSM. This distinction, apparently, is among<br>them.<br><br></div>