[Tagging] Forestry/logging

Kevin Kenny kevin.b.kenny+osm at gmail.com
Mon Apr 10 20:10:33 UTC 2017


On Mon, Apr 10, 2017 at 4:05 AM, Mattias Dalkvist <osm-stuff at dalkvist.se>
wrote:

> On Mon, Apr 10, 2017 at 9:49 AM, Michael Patrick <geodesy99 at gmail.com>
> wrote:
>
>>
>> My guess is the permits for future operations are online also. Such an
>> inventory is is a non-trivial task
>> <http://www.pobonline.com/articles/100691-forestry-by-way-of-aerial-imagery-remote-sensing-gis>,
>> especially maintaining it.
>>
>> A better way to handle this would be a federated page that layers OSM and
>> the forestry web service(s).
>>
>>
> This is why I started to think about this, the data about forest harvest
> in Sweden is under a CCBY like licence, but I wanted to get a better
> understanding how to tag it before contacting them and see if we can import
> the data in to OSM.
>

The point about a federated map is that the data that OSM mappers don't
maintain won't be imported.

For maps that I produce (example:
https://kbk.is-a-geek.net/catskills/test3.html?la=42.1344&lo=-74.1186&z=14),
I usually don't attempt to use land cover from OSM. I use land cover data
from the National Land Cover Dataset (NLCD), while I have other data from
OSM and other sources. That makes it similar to elevation data - the layers
in the OSM map that show elevations don't have all the contours in OSM,
they get them from elsewhere.

For that reason, I generally map landcover only where (a) I have personal
knowledge that NLCD is wrong, or (b) I'm mapping in my own suburban
community and want higher-resolution landcover information than the 100m or
so that NLCD gives me. In most cases, for a hiker, NLCD is fine. I at least
have some information about where I might expect to get my feet wet, and
which way to go to avoid pushing through a spruce thicket. It tells me that
I might expect a nice, unobstructed view to the south where the trail
crosses County Road 3 near the center of
https://kbk.is-a-geek.net/catskills/test3.html?la=42.5879&lo=-74.1075&z=15.
That stuff is really what I need to know.

If everything were imported, there would be a nightmare trying to maintain
the data. If a local mapper has repaired anything about the imported
landcover information and there is a subsequent change to the same polygon
in your national database, what do you do? (Damaging the local mapper's
hard-won data is NOT acceptable.)

Incidentally, those maps also shows why I think that some other data should
not be imported. The trails shown in magenta are from some government
databases. The data are reliable in that they show the presence of trails
and their destinations, but their spatial accuracy leaves a lot to be
desired. You can see how the alignment is quite poor indeed where a magenta
trail is overlaid with a black one from OSM. The same database is what put
a parking lot in the middle of the woods south of the Schoharie Headwaters
Unit. (The parking is actually on the turning circle at the end of Prediger
Road). I show the magenta trails primarily as a mappers' 'to do' list for
field mapping.

So let me leave you with a challenging question: how would importing the
data benefit the OSM community more than federating it? What would
importing allow us to do that a federated approach would not? (For my
imports of public land boundaries in New York, my answer was, "it allows us
to conflate boundaries between land owned by different agencies, where the
complete set of parcels is not in any one agency's database." Moreover,
administrative boundaries often are an exception to the general rule that
federation is better than import.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20170410/80d67054/attachment.html>


More information about the Tagging mailing list