On Sun, Jul 28, 2019 at 8:04 AM Paul Allen <pla16...@gmail.com> wrote: > I have no objections to protect_class as supplemental information that data > consumers can make > use of as they wish (including ignoring it). I have an intense dislike of > numbers being used for > anything other than numeric values because they are not amenable to human > inspection. Sure, > editors can unobfuscate things by using an internal lookup table, but that > isn't a complete solution. > Compare an overpass-turbo query for leisure=state_park and for > protect_class=21.
I dislike the numeric classification as well. I dislike 'leisure=state_park' for two reasons. First, it preƫmpts the 'leisure' tag. It turns out that there are State Parks that are also something else in the 'leisure=*' space. A handful in New York are tagged 'leisure=golf_course' and should retain that tagging, but it would be good to have tagging that indicates the protection status. Bethpage State Park wouldn't be turned into condos just because some future administration decides that the state's money ought to subsidize something other than golf - it would be repurposed to some other recreational use. (The legality of releasing it from protection would be a complex political question; repurposing it from one recreation to another could be an administrative decision by the executive branch.) Second, it pushes the problem down one level. Near me, there are 'County Parks' that are functionally pretty much the same as State Parks, and even 'County Forests', 'County Nature Preserves', 'County Wildlife Sanctuaries', and so on... and moreover, even some similar objects at the town level. What is significant is the protection, not the level of government that establishes it, so having 'state' in the name is simply a recipe for more confusion. We already struggle with that issue every time that the national_park tag comes up, because 'national park' to IUCN describes a purpose and level of protection, not a particular ownership. In fact, IUCN's guidelines have a cross-cutting taxonomy of management that divides it into four categories: government (including national, sub-national and delegated entities - the last refers to formal delegation to an NGO); shared (collaborative; joint; transboundary); private (individual; nonprofit - NGO, university, cooperative; for-profit); indigenous (declared and run by the local indigenous community). Any of these can apply to any of the types; hence, in areas that I try to curate, there are some relatively surprising combinations. The Adirondack Park is a non-Federal 'national_park' with shared (collaborative) management between the state of New York and private landowners; the New York City watershed is a set of sustainable-resource-use protected areas with private management (It's outside the city's boundaries. New York City is not its government, merely its landowner functioning in the capacity of a private entity); the Huyck Preserve is a habitat area with autonomous NGO management; and so on. It's really important NOT to think of the problem as being 'the wrong level of government.' Even my for-profit employer is in the game. There are a couple of recreation grounds near my work site that are owned by the company but used by the town under a permanent easement. They exist in part because there is a required setback of 500 m (I may be wrong about the figure) between certain hazardous activities at my workplace and permanent human habitation, but I'm sure that the company is also glad to get the tax writeoff and have its name on the sign as the donor. The 'boundary=recreational_area' idea would work for me if people were actually to get behind it. We would, of course, have to address 3785 somehow - and deal with the fact that means a database reload. Just as 'protect_class=24' is now dead (replaced with aboriginal_lands), we could migrate the other protections over to a named scheme. In fact, that would work with the IUCN codes as well - we don't have to use them unchanged, we can name them! (Of course, we could preserve a correspondence between IUCN's taxonomy and ours, and continue to accept the IUCN codes as synonyms.) In fact, IUCN gives names to the categories in https://www.iucn.org/theme/protected-areas/about/protected-area-categories - although we OSM'ers would probably go with something a trifle less verbose, such as 'strict_nature_reserve', 'wilderness_area', 'national_park' (already used), 'natural_monument', 'habitat', 'protected_landscape', 'sustainable_resource_use_area'. I drafted the protected_area idea a short while before I learnt of the issue with the database, and learning of the issue has already made me less sanguine. The only thing that kept the idea alive for me was that 'area=yes' is available as a workaround, and that most areas tagged with 'boundary=protected_area' also have other tagging that does force a polygon to be created, although there appear to be thousands that do not. So, I'd like to emphasize: * The tagging should address protection status and purpose, not what level of government (or private agency, or indigenous community) manages it. * The purpose should be of a sufficiently general nature (e.g. 'recreation') that a typical state park can be preserved as a single named entity. * If the new tag requires a database reload to become a polygon, then it should not conflict with the existing tagging on typical state parks. If the scheme punishes mappers by failing to render correctly tagged features while rendering incorrectly tagged ones, it will not take off. The reason for the third bullet is that I understand that a database reload incurs a massive disruption to operations and can be done only for extraordinary reasons. The initial support for 'protected_area' waited several years - during which time, mappers were directed that there was no other correct tagging for objects such as US National Forests (large portions of which are not forested, and which are not strict nature reserves, and which are not National Parks), forcing them to decide between tagging for the renderer and waiting years for their objects actually to appear on the map. Small wonder that these issues have become so contentious - the perception is that one part of the community says to another, "your feature does not deserve to be rendered!" _______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging