[Imports] WRI Congo Basin forestry tracks import

Tue Feb 17 16:58:17 UTC 2015

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi, Christoph:

Thanks for sharing. My comments inline.

On 17/02/15 15:57, Christoph Hormann wrote:
> On Tuesday 17 February 2015, Thomas Maschler wrote:
>> 
>> I added a link to the wiki for a technical documentation of
>> origin, production process and accuracy assessment. Find the link
>> also below, for your convenience. 
>> https://wri-forest-atlas.s3.amazonaws.com/Team/Projects/OSM/cmr_roads
>>
>> 
_technical_report.pdf
> 
> Thanks for that - this clarifies a lot of things.
> 
> Based on this the primary source is Landsat Imagery from 1999-2003.
>  That implies a number of things:
> 
> - Under the circumstances here, i.e. with a strucured landcover, it
> is impossible to identify a highway=track on Landsat images. - What
> is actually mapped therefore are clearings in the forest.  These 
> would normally be tagged man_made=cutline.  It is of course safe to
>  assume that in the center of a longer line clearing there is a
> road at the time the clearing is cut which is usually a
> highway=track.  But this already involves quite a lot of
> guesswork.
> 
> Add to that the fact that the data basis is 10-15 years old meaning
> that unless the tracks have been used and maintained for a
> different purpose than logging (which would make them something
> different than highway=track in most cases) they probably have
> decayed and grown over again since that time, especially if the
> clearing visible on the Landsat image that was the basis of the
> mapping was already several years old when the image was taken
> (leading to a possible total age of 20+ years.)
> 
> My recommendation therefore would be to not use this data for an
> import but render a map layer from it that can be used as a hint by
> the mappers in the sense of 'look for a road here and if there is
> one map it based newer high resolution images'.

If this was an automatic import, I would also strongly recommend not
to do it. In any case, I wouldn't recommend any roads automatic import
anywhere nowadays.

But this will be a ***MANUAL*** import. And this means that people
involved in it will check the data correctness before it actually
upload it. In case a road is clearly poor in accuracy, they will
correct it, as we do every day with legs of roads that were traced
with lowres imagery and that now fall in an area that has already
hires. And any segment that is clearly wrong and shouldn't be there
will be NOT imported. This will be done with all segments, one by one.

A similar MANUAL import (not finished) was set for Central African
Republic. I myself used that import to improve the road coverage in
that country. And everyone was fine with that. There too, some tracks
(or parts of tracks) were not imported. Manual imports are slow, but
are more similar to normal mapping than to an import.

Your recommendation of using a rendered map layer to use as a hint is
very similar to this proposal. The only difference is that here you
don't have a map layer but the tracks themselves. If they are ok, you
just import them. If they don't get an acceptable accuracy (maybe
because they were traced with lowres imagery and now we have hires
imagery to check its accuracy), it can be corrected, whether using the
original track (moving&&adding nodes) or tracing a new one, pasting
the tags of the original track into the new correct one and deleting
the old one. And if they are wrong, outdated, etc, they aren't
imported. Simple. The advantages of this method are: 1) you don't have
to trace again all tracks, only those incorrect, and 2) you have the
info from the original file ready available and correctly tagged in
the tracks.

> 
>> Logging roads are inside logging concessions or logging titles
>> and access is granted to logging companies only. Often, roads are
>> blocked once abandoned. However, law is not always enforced and
>> even if blocked, roads are still used by motorbikes and
>> pedestrians to access the area.
>> 
>> Plantation roads inside plantations are private as well.
> 
> If the roads are within privately owned/leased land and the owner 
> forbids access to the general public the correct tagging would be 
> access=private.  access=forestry is for public roads that are
> limited to forestry use by a public authority.  But since you speak
> of logging concessions i would assume neither is the case, i.e.
> this is normally public land where logging rights are given
> exclusively to some company but other uses of the land and roads
> are not generally restricted unless specifc restrictions for other
> reasons exist locally.

If government gives rights for logging, if means it's for forestry
traffic, and that's exactly what we have in the wiki (
http://wiki.openstreetmap.org/wiki/Key:access ): "Only for forestry
traffic". I don't see your differentiation anywhere in the Key:access
wiki. Likewise for agricultural use.

> 
>> All logging road are unpaved. We didn't include this attribute
>> in most of the layers, because it was a given. Material depends
>> on the local situation. Mostly it is laterite, but it could also
>> be rocks, sand etc. Unpaved would be the most appropriate tag.
>> However, if you say, track tag already assumes, that the road is
>> unpaved, we can discard the surface tag.
> 
> That would be a good idea.
> 
> 

Cheers,

Rafael.

- -- 
Twitter: http://twitter.com/ravilacoya

- --------------------------------

Por favor, non me envíe documentos con extensións .doc, .docx, .xls,
.xlsx, .ppt, .pptx, aínda podendoo facer,  non os abro.

Atendendo á lexislación vixente, empregue formatos estándares e abertos.

http://es.wikipedia.org/wiki/OpenDocument#Tipos_de_ficheros
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQIcBAEBAgAGBQJU43MYAAoJEB3niTly2pPQndUP/1+JtTsQzEdzkUY6DeyRH4sN
PScRLpvsN/YUxOz8xeHYcd/g/7GpgtIhjb/pZDBn/iqyCqu3bTJAFKL8UMamrGGJ
Yg7PmEIRSGONiZw+q12/0bIfTixlLpogUmHE39EUAUlQMfPi1BpF9bsXPtfd641M
68B5yJi4OL9zTPajXj+W3B7qW5l+4BczTtLhZD3NnVGDI1eeYTBeTn/zt2WvYovu
XDDypnO3oQu8LYZhdc1Q6dT+AVM7PNmQhVPsSC/Jb8zUwnKhCr0E8T837Ag3s/JF
vkayeEFeJx7izMsnmqdpYuNlEXpxqfsXjk2X+wRuGFqUq9nP+hRcVkmekkB2Ppz3
PiSw+KXR40EUwNQeJSj02wRGFxDSM51YTgvzqvMM/kHxZ11raLwagYJ8urYzN/On
AOmOSLreXbVI2hnfa6dP5Mac0KE/YBb6sXdE03wPihTHjJYK/0jTLmkFRkUzeG3z
uAiB6wBrBFQsBI1q6Oqjk4gcTHoNZwR8VCJSVQzSDgjsaj5U6K9VGFeYm5nU/OQz
kV179JR64rKgd2bSMSGaVHcijl2rXRNU59KWzxQz3ucxIZEx49YSHew/LqdQ0X4y
wPe9gmBzvTSQCdOQR30fMHGN1cNMCbCJsAycUKSeHZ5bGVom/yljgkYUT/ZntxRK
Ua9XSz8UkumN6F737/kS
=D81z
-----END PGP SIGNATURE-----