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
_______________________________________________
Talk-us mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/talk-us
