[Talk-us] Blue Ridge Parkway

[OSM Volunteer stevea]

Long post alert, apologies in advance.  You might jump to the last paragraph, beginning "stated succinctly."

I applaud efforts and discussion I see here regarding subtle distinctions between Blue Ridge Parkway being not a National Park per se, but rather a "park area" administered by the same agency that administers National Parks.  OSM should be able to capture these semantics (and indeed, any, where ever they exist) with our wonderful plastic tagging.  So, let us do so.

The boundary=national_park tag has seen much use and abuse over many years.  Perhaps because it renders as green dashes, it was inappropriately used (and is today?) for state parks and other non-national parks, though in the past (five years ago?) this was rather widely tolerated.  However, now our boundary=protected_area and protect_class keys are superior, even as rendering support for them remains under-developed.  That's OK:  OSM wants accurate tagging rather than tagging for the renderer.  Renderers can, do and will "catch up."  Not in  the case of every tag to be sure, but our consensus, being of utmost importance, deserves the waits involved, tedious as this process can be.

Tagging can go too far by becoming unwieldy and scattered:  too many tags all expressing one same (or very similar) concept.  Discussions like these (here and in similar forums) can and should start with a single semantic concept, pull together disparate but related concepts and use techniques used in classification systems and applied linguistics to develop a "more proper" structure and syntax.  We've done this over and over again to very good effect (boundary=protected_area and protect_class keys being a fine example) and we'll do it again, first to achieve the goal of expressing a concept as a semantic, defining its scope so as to be broad enough but not too broad, being inclusive for the sake of consensus and developing a crisp syntax with which we ultimately tag, consulting well-written wiki which documents.  Those steps (and others) deserve being explicitly laid bare (here, again), and may include others or not necessarily happen serially or even in the above or any particular order.

All that said (whew!) I believe Brad Neuhauser is on the right track when he finds a "distinction" on a "nomenclature page" (excellent!) bifurcating (trifurcating?) National Parks, National Parkways and National Park Service Areas.  And Mike Thompson rightly declares that each nation will likely have its own specific nomenclature.  However it is imperative to mention that while a "military cemetery administered by a national park agency" might have different formal names in Australia and the USA (or any country), their tags (syntax) in OSM should be identical, as they both tag the same "concept" (semantic).  Mike continues that "sub-tag(ging) in addition...may be more appropriate...rather than an entirely different tag."  Yes!  The protect_class tag is, once again, a fine example of such a sub-tag, and it is well-developed, well-discussed and flexible enough to accommodate more growth and sub-classification.

Until rendering support arrives for boundary=protected_area + protect_class=2, we continue to use boundary=national_park as a legacy tag.  Actually, to avoid a collision, we now use boundary:type=protected_area + protect_class=2 + boundary=national_park.  Understandable.

The protect_class key wiki lists 2 as National Park, a widely accepted semantic.  However, National Park Service Areas (NPSAs) and National Parkways are not strictly "that."  A new protect_class key for these entities seems needed.  There is a precedent in protect_class=1 to use 1a and 1b for "strict protection" and "wilderness" (respectively) with definitions for each.  We might do the same for 2, creating 2a for NPSAs and 2b for National Parkways (or 2b and 2c, leaving all 2s to get reassigned to 2a?).  But I don't like this, as it "breaks" a single semantic into sub-classes of arbitrary designation, which could get unwieldy quickly.  (Indeed, it seems to be doing so in this very paragraph!)

Note that word in Frederik's, Brad's and Mike's quoting of the NPS' designations:  "unit."  Some NPS "units" are actually national parks (protect_class=2, crisply and exactly), some NPS units are not.  What are they?  I think we need a new protect_class key.  There is a newish protect_class=27, named "public land" which might fit, but wiki's Discussion page leans towards 27 not being a good match for much besides a catch-all for tangled semantics better described with operator=* and site_ownership=* tags.  As an aside, please allow me to underscore the importance of including such owner/operator tags on national parks, NPSAs and National Parkways (or equivalents in other countries).

Stated succinctly, there are "units" within (and owned/administered by) National Park agencies which need a tag distinct from protect_class=2.  These include, and by no means is this exhaustive, NPSAs and National Parkways.   While these should clearly receive the same operator=* and site_ownership=* tags as their "parent" park entity, strictly speaking they should not receive the protect_class=2 tag.  The exclusionary geometry might be properly done with multipolygons, but the question remains:  what is/are correct protect_class(es) for the excised "unit" entities?

Respectfully,
SteveA
California