[Talk-us] Tagging National Forests

[stevea]

Lengthy replies to lengthy post do follow; fair warning.

>On 08/19/2015 05:29 AM, Nathan Mixter wrote:
>>In any discussions about land use and land cover, we should look at 
>>what organizations have done and how they have mapped ares. For 
>>instance, in USGS imagery in JOSM you can see how they render 
>>borders with just a dashed line and let the land cover have various 
>>shades of color on top of it.

Complex park boundary mapping semiotics are something that I 
identified as needing improvement in OSM as far back as 2009, when 
Nathan and I (along with OSM volunteers Apo42 and DanHomerick) mapped 
many public recreation areas in Northern California (parks, nature 
reserves, commons, state beaches...) finding difficulties with how 
these might be reconciled with landuse tags (forest, wood and 
meadow).  In short, this is not a new problem, and crisp definitions 
(semantics) along with accurate rendering (semiotics) of our tags 
(syntax) are the only combination that will solve these ambiguities. 
The troubles are:  1) getting accurate tagging by everybody 
(difficult when tags have overloaded meanings), 2) achieving 
consensus is difficult and time-consuming and 3) rendering update 
implementations seriously lag 1) and 2) even when they do happen.

(Nathan further quotes USDA, USFS and "interagency" definitions of 
forest vegetation and landuse/landcover)...

And Kevin Kenny replies:
>I hear a lot of argument here, and much of it is philosophizing. Let 
>me offer another argument. Deficiencies in the standard rendering 
>are leading us to impose constraints that do not exist.

YES!  To a large degree, Kevin reiterates that 3) (above) is a major 
problem:  mapnik/Standard rendering seems to lag, get wrong, and/or 
exacerbate the difficulties we have with landuse and landcover 
issues.  Ditto administrative boundaries, especially for public areas 
of

>The very idea that we should have to cut out watercourses and 
>highways from a National Forest to show it correctly on a map is 
>absurd. If the renderer cannot cope with the idea that the Elm Ridge 
>Wild Forest (a protected area - and specifically an area of state 
>ownership with public access for recreation and harvesting of fish 
>and game) lies partly within and partly outside the Catskill Park (a 
>different sort of protected area, not all under state ownership) and 
>in turn has several bicycle corridors (an area of less protection) 
>overlaid upon it, then it cannot cope with the messy reality that I 
>work with locally.

I believe we agree that watercourses and highways which are IN a 
National Forest really are inside the polygon boundary defining it, 
but that we shouldn't necessarily "see" (rendered) "little trees" in 
the middle of a lake, or on top of a highway.  These are rendering 
issues, not tagging issues:  nobody should have to "cut out" of a 
National Forest polygon every single lake within it so that trees 
don't render on it, that is indeed absurd.  Fix the renderer, 
instead.  This largely seems to be issues with mapnik CSS being 
ordered properly, though I likely oversimplify.

>Since I render my own maps, let me begin by observing: THE LACK OF 
>CONSENSUS ON THESE ISSUES MEANS THAT I DO NOT USE OSM AS A DATA 
>SOURCE FOR PROTECTED AREA BOUNDARIES. I go to alternative, mostly 
>government, data sources for the boundaries of government and other 
>protected lands and use them for map production. I simply cannot 
>cope with wholesale retagging of these areas every few months as 
>each new tagging scheme comes through. WE NEED TO REACH SOME SORT OF 
>STABLE CONSENSUS, at least one that lets us produce medium-scale 
>maps suitable for general use without running on a hamster wheel of 
>patching renderers to adapt to changing tag schemes.

In a word:  YES!

>I've half come around to the position that National Forest 
>boundaries don't belong in our database at all. They're often not 
>any more observable on the ground than any other property lines - 
>and I believe that we reached a consensus that delineating land 
>ownership is outside the scope of OSM. (Am I wrong about this?) In 
>fact, the reason that I'm able to ignore OSM on the point is that 
>most of the data I need is available in authoritative form from the 
>agencies that manage the land.

National Forest boundaries belong in our database as much as other 
administrative boundaries belong in our database:  and THEY DO.  Map 
consumers EXPECT to find these in a map.  A map that does not show 
the boundary between California and Nevada, or California and Mexico? 
Absurd!  If small neighborhood boundaries in a large city are shown 
or not shown, I can live with it either way.  If not shown, perhaps 
that city has none, or volunteers haven't yet gotten around to that 
level of detail.  If shown, I do not find these to be "map clutter," 
in fact they are useful to me.  I think many others or even most of 
us agree with this sentiment (though that doesn't automatically 
convey consensus on the topic).  That said, we should strive to get 
administrative boundaries CORRECT rather than just throw up our hands 
and say "too difficult" or "these shouldn't be in OSM." 
Administrative boundaries are worth doing, and if done right we have 
the opportunity to convey difficult cartographic semiotics perhaps 
like never before:  OSM should not squander this, but embrace it! 
Let the designers and cartographers among us put on our thinking caps 
and use color, dashing, thickness (and so on) to really convey what 
we wish to say.  While a tall problem, it is solvable.

Kevin Kenny continues...
>Unfortunately, some of the smaller agencies (mostly county and 
>municipal agencies) still haven't moved forward into using GIS, or 
>simply don't have the resources to make what GIS data they have 
>available to the public, so there's still some amount of measuring 
>on paper maps.

While an important observation, we shouldn't let the speed of public 
agencies adoption of GIS (or lack thereof) drive OSM's data entry. 
Whether paper or soft-copy data, OSM can cope with its entry.

>Since we don't have a good general policy for OSM maintenance of 
>data where the authoritative copy is elsewhere, OSM really simply 
>becomes the convenience of "one stop shopping." I enjoy having that 
>convenience, and so do many other users. But for some of the data, 
>it simply costs too much time and effort to negotiate the minefield 
>of tag wars.

There are two issues identified here:  "authoritative copy being 
elsewhere adds challenges to updating" and "tag wars happen."  These 
are truly different problems.  The former requires diligence and 
attention being paid to changes/drift and doesn't have significant 
"social" (people relations) problems.  It has difficulties, but is 
solvable.  The latter is hugely "social" so movement towards 
consensus are paramount.  Yet crisp definitions (in the wiki, derived 
from "official sources...") is where the consensus must begin. 
Getting to universally agreed upon definitions seems to be a much 
harder problem (than updating data), especially as OSM is a worldwide 
project.  The newer protect_class schema is a very good direction for 
us to pursue, yet rendering support for it (or something like it) 
seriously lags.  In fact, I see very little discussion of this, let 
alone implementation.  These are difficult problems, hard to 
describe, hard to slog through discussion of, hard to achieve 
consensus about, hard to implement in software/map renderings.

>And I still claim it's largely because of the renderer.

Yes:  I agree with you in that paragraph above.  (As I suspect others 
might, too).

>So now let me move forward to specific rendering suggestions...
>Refer, if you will, to...
>There are numerous administrative units, some overlapping, shown here.

YES!  Administrative units can and do overlap, and our renderers must 
cope with this reality.

>The most significant is the Catskill Park. This unit

Calling things a "unit" is useful, but difficult, as one unit will 
likely have quite different attributes than another unit.  The tricks 
are getting the attributes exactly right (defined, say, in a wiki, 
then expressed as tags), and exactly rendered.  This is a long and 
potentially difficult chain of implementation (some of it 
consensus-based, some of it consistent and accurate tagging, some of 
it rendering software), but OSM can (must) do it!

Kevin then describes how some highly local "rules" (of 
administration) affect landuse (such as whether mountain biking is or 
is not allowed).  I, for one (and I suspect MANY others) DO WISH that 
OSM captures these seemingly subtle but actually quite useful 
distinctions.  We must strive to do this in our map data and 
renderings.  We seem a long way from completing these very worthy 
goals (and Kenny simply throws up his hands at using OSM to do so -- 
now!) but we CAN do it.

>You'll see how the parcels can be shown readily by using a 
>semitransparent shading on the interior edge of the polygon, without 
>obscuring what lies within.

Good cartographic semiotics (good design, really) go a long way 
towards even those who are uninitiated with these sometimes subtle 
methods of "seeing things" well.  Maybe you look at a Legend (once or 
twice) but after that, if the design is clever and works well, you 
just understand what you are looking at.  This is a high bar we 
should strive to achieve, but we can get there.

>Shown in the base color is land cover with deciduous forest (medium 
>green) predominant. At the highest elevations and in the wet 
>low-lying areas, coniferous forest (dark green) takes over. There 
>are some patches of mixed forest (lightest green) along with 
>farmland (buff), marshland (aqua) and developed land (pink) in the 
>valleys. Some of the cliffs have patches of bare rock and scree 
>(grey). A light hill shading overlays the whole.

This sounds (and looks) like typical topo coloring and map semiotics. 
A fine place to continue bettering our rendering, as many are already 
familiar with this kind of map display: "as we see it, we already 
know it."

>So here we have large administrative units (lines with their names 
>shown on the interior), smaller and sometimes overlapping 
>administrative units and land use designations (lighter lines with 
>transparent color overlay on the interior, with names in the 
>interior for the larger areas where possible), hill shading, and 
>land cover (base color) all shown. The visual clutter can get pretty 
>bad in spots, particularly where different agencies' GIS systems 
>fail to agree, but the information density is high.

Luckily, difficult is not the same as impossible!

>Patterned overlays are also still available, and I'm not using them 
>very much yet. You can see that I mark emergent wetlands (from yet 
>another data source) with a pattern, if you use the mouse wheel or 
>zoom buttons in the map that I linked to to examine the wet area 
>north of Hensonville at the center. Showing these without a rendered 
>boundary seemed appropriate, since they're approximate at best (and 
>depend on rainfall and beaver activity in any given year).

There are vast numbers of possibilities here.  Think of how back in 
the old 8 bit days of 1980s graphic computing, display screens did 
amazing things with patters/fill colors/edging so you could "see 
things as different."  We have much better display technology today, 
but good design that avoids visual clutter while still well-conveying 
what needs to be shown is still required to make maps better 
communicate dense data.  Largely, this is good cartographic design, 
perhaps coupled with leveraging what people already know (like topo 
shading where it makes sense, different colors of dashing for 
different admin_levels where that might make sense...).

>I contend that if the standard rendering made more use of edge 
>in-fill, pattern fill, and transparent overlays, we'd have fewer 
>arguments.

YES!

>With our use of solid color fills (and opaque pattern fills) 
>exclusively, we simply don't have enough ways of displaying the 
>competing concerns, and lurch among tagging that focuses on land 
>ownership, land administration, land use, and land cover - all 
>related, but distinct concerns - with cascading effects downstream 
>as people try to render whatever tag scheme has come out of the 
>latest round of a never-ending argument. In large measure, it comes 
>down to the renderer.

YES!

>We try to have a tag scheme that says, "this parcel is inside the 
>Catskill Park. It's owned by the Department of Environmental 
>Conservation. It's open to the public. It's covered with balsam 
>forest. It's managed as Wilderness Area" in a single statement. That 
>simply will never be successful. Renderers will have to deal with 
>these cross-cutting concerns, which means rendering overlapping 
>areas that have different meanings.

YES!

>We might as well face the fact that these issues are chaotic, 
>they're always going to be chaotic, and no tag scheme will ever 
>describe them fully. But please, can we try at least not to have 
>continual breakage for major, signed features such as National 
>Forests or the Catskill Park that nearly all map users will want to 
>have rendered somehow?

Thank you, Kevin.  Thank you very much for helping us to visually 
articulate what we are trying to do with our map data.  May we not 
lurch, but SURGE ahead.  Let's continue these discussions, reach 
consensus, better tag, and achieve beautiful rendering.  That's a lot 
of work, but it will be well worth it, and we can do it.

SteveA
California