[Talk-us] Parks, again

[OSM Volunteer stevea]

There is a lot to unpack in this discussion.

First, OSM has the strong tenet that we should not code (data tag) for the renderer.  That is sound advice and largely serves us well, but it fails to directly address that there is no point to being an OSM volunteer unless there ARE renderers which display the results of our mapping (tagging).  Well, if you spend time in the more "coding" aspects of our project, you can glean the largely opaque (to most OSMers) processes and personalities of renderers and rendering, and maybe that is appropriate:  after all, they are the "back end."  Yes, this is where important decisions are made about what data in our map either are or are not shown.  (I'm talking about Carto, what might be called OSM's "front door" or "pretty face.")  Carto is, for better or worse (and it has gotten much better) what most mappers (and other OSM consumers, though not all) "see as OSM."  I know that's not strictly true, but let's say for purposes of this discussion about parks that it is.

Especially since having discovered OSM in 2009, I love cartography and mapping.  I also love parks, hiking, biking, nature and enjoying our public lands which are protected (at certain "levels") from further human development.  So, even as I got started mapping in OSM back then, accurately mapping parks (indeed, even positing ideas at how we might potentially improve how OSM maps parks, something I continue nine years later) became an important goal of mine in this project, reflected in my user page, mapping practices and passionate talk-us discussions.  I have followed many twists along the way, such as when leisure=nature_reserve is more correct than leisure=park, a lengthy debate (here) about landuse=forest (which I eventually cried "uncle" about, seeing that we were badly smearing the semantics of well-established wiki definitions, although they were and are ambiguous), striving to "do the right thing" with National Forests, National Parks, State Parks et al, important distinctions between landuse and landcover (still badly under-addressed in our project, as rendering distinctions between them remains muddy and has not fully emerged), the development of the protected_area (a good thing, but sorely lacking in helpfulness when it comes to being rendered — a difficult task, I realize) and other related topics.  It is quite complex, it is difficult to communicate about all the moving parts, let alone reach solid consensus, let alone render perfectly what we mean.

Tagging accurately, with well-designed and well-documented (in our wiki) schema are absolutely essential.  Rendering, at least at "some" level (a single renderer suffices, one, like Carto, which is also well-designed to carefully "map what is important and not map what is not important") isn't QUITE AS essential, but let's use the word "vital" or say "very important."  The full path from "volunteer entering data" to "seeing it blossom upon the map" is largely what drives the passion of OSM volunteers doing our good work.  So the choice of what to render (in Carto) is vital.  As we diligently enter map data, we are pulled forward by the sometimes-seemingly-contradictory desires of wanting to see beautiful renderings of our work as well as to rather precisely enter data, and not code for the renderer.  Threading that needle is not alway successful, and it is often thwarted, as I believe it is in this case (parks and related entities, what we might agree are "protected areas") by the distinct lack of these entities rendering well.  It is also complicated by the legacy of older/preceding tagging conventions.

We've done good work with developing the protected_area schema in our tagging syntax.  We haven't done good work rendering the full spectrum of what we mean by those.  Again, this is difficult.  Colors, confusion with landuse/landcover, ideas about dashing (whether jurisdiction, landcover, "use," or other — I'm open to all ideas) are valid topics to discuss.  Let's understand that there has been a medium-long arc of history (over a decade) in our project which must accommodate the way things were done two, five, ten years ago, as well as that we wish to move forward with more robust tagging schema AND better renderings of those schema.  In short, and it is widely known:  legacies can be challenging to grow beyond.

These are complex issues, we have been evolving them over years on top of doing things with more simplistic (legacy) methods, and so many issues must be accommodated in a "smart growth" (towards excellent tagging being supported by excellent rendering) methodology.  This forum may not be the best way to do that, as I feel I have typed too much for one missive already.  Please, let good discussion continue.  We are many people, with many good ideas, who wish to see the "right" and "best" things happen as our project grows and improves.  Once again, I believe us to be more in agreement than disagreement, and ask that many here who wish to make bold steps forward continue to do so, though we do well to consider our histories even as we leap ahead.  Coupling new tagging schemas with rendering is key.  But building the consensus that allows that "stack" or "workflow" to full fruition is difficult indeed.

SteveA
California