[Talk-us] Parks, again

Fri Jan 5 20:09:41 UTC 2018

On January 4, 2018 at 6:21:03 PM PST, Bradley White <theangrytomato at gmail.com> wrote:
>> As you say "feel like Type 2" I think is where it fuzzies in my mind.  Parks go to 3, 4, even 11 and beyond.  Parks have a wide range of "experiences" besides 1 and 2.
> 
> So do roads. There are countless kinds of roads, with varying levels
> of importance and physical features. Instead of using a catch-all
> "highway=road" tag, and instead of tagging infinitesimal levels of
> network importance (or any of the other countless possible metrics),
> we develop a classification system that allocates all roads into a
> small set of (semi)-easy-to-work-with-and-understand classes. Some
> roads don't fit well into this system, true. It isn't always clean; it
> can be ambiguous; it continues to be debated over, and that's fine.
> But, for the most part, it has worked, certainly better than the
> all-or-nothing alternatives would have.

I believe you are saying (agreeing) that "roads have many flavors."  Yes.  We have many highway=* tags to accommodate those, and while there remain some sticky difficulty in a few corner cases, as we map with values motorway, primary, trunk, secondary, tertiary... OSM (recall, "Street" is our middle name) does well as a result.  The tag "highway=road" is not a "catch-all" tag applied recklessly to any and all roads:  for the most part roads are tagged with the above (more correct, more precise) values and "highway=road" is left for more ambiguous cases, for example when fuzzy aerial imagery suggests a road/highway, but little or nothing else is known.  If I got any of that wrong, please gently correct me.  Although, I think we are largely in agreement:  we both (and many of us in OSM) use the highway= tag with little argument or consequence.  (Again, in a few minor cases, discussion continues).

> I agree with previous posters that this is same case with parks. In
> the same way that the fact that there is something different enough
> about a freeway and a narrow county back-road to represent them
> differently in the database, there is something different enough about
> a park I would take a kid to play on the playground for an hour, and a
> park that I can spend half the day mountain biking around in without
> encountering more than a small handful of people, that I think they
> should be differentiated between in our data. I don't think the title
> given to a piece of land should necessarily have bearing on the data
> representation, in the same way "Hampstead Heath" doesn't get
> "natural=heath" just because it's in the name.

I don't know to which previous posters you refer (this is a new thread I've broken off) and I am not sure of the point with which you are agreeing.  If I had to guess (I prefer not guessing) it seems you mean that OSM could benefit from a wide array of park tagging similar to how it enjoys a wide array of highway tagging.  I do not disagree, meaning I agree.  Sure, early on we seem to have "broken out" (from "generic parks") the specific semantic of "national_park."  As I said before, doing so (and where we are now), brings us up from one type of park (all of them) up to two (a certain kind of them excluding the rest), with two being a very small number.  There might be dozens or even hundreds of types of parks, and refining this to exactitude and full consensus all across Earth could take OSM decades, with much tedious and messy "sausage making" along the way.  Not that it wouldn't be valuable to do so (it would be) since as a result of those efforts, OSM might become one of the best park maps ever made of our whole planet.  Alas, as "street" IS our middle name, we've come closer to the goal of well-describing our highway networks, rather than our parks.  Though, parks (and many, many other objects in OSM) are somewhat well-represented, I think many agree.  We crawl before we walk, we walk before we run.

However, we haven't really well or fully described parks.  We only partially describe them, which "isn't nothing."  (I'm happy to accept this, use it to enter parks, AND improve on our park entry schema).  As I mentioned,  in 2009 Apo42 in California got into the (good, in my opinion) habit of adding to a (partial, though substantial) statewide parks import a new (back then) tag of "park:type" which often blended jurisdiction, type of natural area and/or purpose.  For example, some of its values are county_park, state_beach and state_historical_reserve.  This was an early, first foray into better characterizing what California's Department of State Parks throws into a large bin called "parks," (all of them, from beaches to historical reserves) while using the state's own data to better sub-categorize them.  As you say, there are all kinds of purposes for what humanity calls "park" and it would be good for OSM to capture these aspects.  What we haven't done is talk about what vast issues this gives rise to, primary:  what is important?  Jurisdiction?  The season and/or hours a given park is open?  Whether it allows campfires?  These and many other aspects (like other places, parks are a terrific example of how well OSM can "show" these) of various amenities (restrooms, campgrounds, specific recreation facilities like ski lifts or improved bike trails...) can be and are entered in OSM to good effect.  However, I think we can all agree we might do a whole lot better.  The "big iceberg beneath" are the vast and myriad kinds of things humanity means when we utter the word "park" (on a tag in OSM, or when a city, county, state, nation, campground company... calls a chunk of land one).

> Currently, I use the tagging scheme detailed by Greg earlier. I am
> certainly not opposed to using "leisure=park" along with a basic
> classification tag, say "park=developed/undeveloped" or something, but
> Greg's scheme has the benefit of using established tags with rendering
> support that still more or less respect the definition and intent of
> the tags. While "leisure=nature_reserve" has generally assumed some
> kind of conservation status, I think the newish
> "boundary=protected_area" tags do a much better job detailing land
> conservation, and that "leisure=nature_reserve" is the perfect tag to
> adopt for the type 1 parks which Greg talks about. These 'type 1'
> parks are, after all, pieces of *nature* being *reserved* by a
> government agency for *leisure* of the public.

Let's tag as our wiki defines.  If we don't, our project will eventually self-destruct into an ooze of ambiguity from a tragic lack of consensus.  Words mean what words mean, tags as defined in our wiki mean what the wiki says they mean.  "Your" examples (or "his," or "theirs...") provide valuable insight into what is meant by park, but please don't let "your" examples restrict what the rest of humanity includes in "park."  Improvements to tagging schema have been successfully proposed and implemented, even to the point where they are rendered (this seems crucial to eventually complete, though it can work by being on a parallel and slower track).  Whether or not there is rendering support is something to consider, yes, but let's not tag for the renderer AS IF it is the only consideration.  We could do that with parks, though we are a long, long way from doing so.  Simply because something isn't one of two things doesn't mean it isn't something, especially when "one" is an all-encompassing categorization of exactly that thing.  We can do better by understanding this simple fact.

(Paraphrasing from a side-channel communication):  I know that there are posters on 'tagging' who believe we all live in a world of neat regimentation of perfect information, precisely fitting a schema.  Mmm, no.  Not always.  Language can be ambiguous, in which case it must be disambiguated so we may better understand each other.  Sometimes, what is needed is a better classification schema to do so.  OSM and parks?  We're not there yet.  This is not a major problem in OSM, but it does give rise to exactly these sorts of misunderstandings.  Let's continue to allow leisure=park to remain as elastic as it has been for the existence of this project, improving upon it if we wish to do so.

SteveA
California