On Mon, Apr 10, 2017 at 4:05 AM, Mattias Dalkvist <osm-st...@dalkvist.se> wrote:
> On Mon, Apr 10, 2017 at 9:49 AM, Michael Patrick <geodes...@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.)
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
