[Imports] Fwd: Importing West Virginia State Forests Boundary

[Kevin Kenny]

On Wed, Aug 11, 2021 at 5:22 PM Minh Nguyen <minh at nguyen.cincinnati.oh.us>
wrote:

> If Brian had done that where I map, I would've pleaded for the import to
> be reworked or reverted. Ways sharing nodes, sure, but modeling landuse
> areas as relations just because they border each other would be
> incredibly unfriendly to any mapper who has to maintain the data as
> landuse changes in the future.


That's a bit strong, but feelings run high.  Some mappers strongly prefer
shared ways where it's known that two landuses or two types of landcover
actually must have a common border. ("The residential area ends where the
industrial area begins," "The land ends where the water begins," "The
wilderness area ends where the producing forest begins." Others seem to
find it difficult or impossible to maintain.

I have a mild preference for shared ways, myself, in these cases, because I
seldom find that the boundary lines are consistent - always, I find that
there's an overlap or a gap because a mapper skipped a node in drawing a
line. Moreover, I find that drawing the same way multiple times is quite
tedious. I'm prepared, however, to edit either configuration.

My comfort with multipolygons may come from the fact that I routinely
curate some extremely diffuse areas such as the Wild Forest areas in the
Adirondacks, where there's no escaping the complexity and the capabilities
of all the tools are somewhat strained. Even there, I've come under fire -
I don't recall who it was - it might have been you - that asserted that
every individual parcel of an area like
https://www.openstreetmap.org/relation/6360587 should be a separate
top-level polygon, and multipolygons should be reserved as a matter of last
resort only for features with holes, or features with thousands of nodes on
their boundaries. The website, Wikidata, name, protection title, and so on
should simply be duplicated across all the distinct areas.  It was
important to me to be able to refer to the facility as a whole, no matter
how diffuse its boundaries, and I found the proposed solution of referring
to it only by an Overpass query that returns multiple results to be a poor
alternative, so I maintained the relation anyway.In any case, the largest
parcel is unavoidably a multipolygon because of the inholdings. (And one
with an awkward topology at that. including, if memory serves, a "pond on
an island in a lake inside the parcel" where neither water area is part of
the area in question.)

Note that I avoided conflation with municipal boundaries because (a) TIGER
doesn't have them all right, and (b) the surveys that laid down the
townships were often quite primitive, and substantial errors of closure
exist to this day.  There's no guarantee that the borders align, which is
my criterion for conflating shared ways.  Similarly I refrain from
conflation with shoreline unless I understand that there's a true "the land
ends where the water begins" status. (There is such a thing in some of
these cases, because the upstream database that I'm using represents
"Forest preserve land under water" as a separate landuse, and I know that
in that case, the actual shoreline governs, since the landowner of the
shore is the landowner of the water.)

I believe anecdotally that the preference for shared ways vs. redrawn
boundaries is correlated with the mappers' choice of software tools. Those
who use the more powerful but user-hostile JOSM are more amenable to
multipolygons with shared outer ways than those who use more approachable
but less comprehensive tools.  (I fully concede that JOSM is bug-ugly and
has a pretty impenetrable user interface; I use it for its power, and
because I'm accustomed to discovering functionality by spelunking the
inverted-L menu format, now regarded as unstylish.)

-- 
73 de ke9tv/2, Kevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/imports/attachments/20210811/f11b93c2/attachment.htm>