Hi Christoph,
Thank you for you feedback. Yes, dangers of automated classification are well
understood, past failures are studied, and these dangers will be addressed
during this import. Careful visual inspection of imported data is needed,
comparison against available satellite imagery, existing OSM information, and,
when possible, local knowledge. If for any parts of the country concerns about
correctness of new data arise, these parts will be excluded from import.
In the Import Plan it is stated that this project is meant to import areas only
corresponding to forests (with occasional secondary tags) and farmlands. A very
small set of classes with no deep sub-classification. No man-made areas or
features such as industrial zones, residential areas, roads etc., no water
areas (rivers, lakes etc.) — such information present in the source dataset is
thrown away.
I tried really hard to find mis-classified places but so far I could not find
it. This source even classifies cutlines under power lines, northern mountain
vasts, and logging areas as "scrub", the same way they are typically tagged in
OSM, and I must add it is often hard for humans to recognize "scrub" on
satellite imagery. So far I've managed to look though a tiny subset of
resulting data (about 4 of total 290 counties) and again I do not exclude a
possibility that things will go wrong at some locations. But now, apart from
unavoidable presence of muffled digital noise making it through smoothing
filters, I dare to say I wouldn't be able to manually tag forests and farmlands
more accurately than this import has.
>this is inherently incompatible with the tagging system and the way how things
>are mapped in OSM.
>you'd import the whole classification system and philosophy behind it.
I am sorry, but I cannot see how these points apply in this case. Pixels with
values 111-128 map to "landuse=forest" (with a few variations reflected as
secondary tags), pixel 3 corresponds to farmland, pixel 42 — to grass. That's
it. Resulting data layers tagging choice looks and feels the same way I would
have tagged it manually using imagery.
> like natural=wood vs. natural=scrub, natural=scree vs. natural=bare_rock,
> landuse=commercial vs. landuse=industrial or leisure=park vs. leisure=garden
> being indistinguishable based on spectral characteristics alone.
I agree with you on that. However, given that man-made features (apart from
farmlands which are easily identifiable) are not target for this import, the
only relevant issue is to tell apart wood, scrub, scree etc. However, so far I
see good accuracy in detecting scrub vs wood, at the same level of (in)accuracy
a human looking at imagery would have.
>But this has to be done specifically for OSM and for the tagging and mapping
>standards we have and it has to be controlled by the mapper.
We do consider this data source to be done for everyone who can make good use
of it, in particular specifically for us OSM-mappers. The Import Plan in
details describes in several places all stages at which human mappers control
imported data before, during and after the import.
Let's be realistic — it is unlikely that we will be able to manually map
forests in reasonable time in a country sized 1500×500 km by tracing imagery by
hand. We already allow machines to do many repetitious tasks about the OSM
dataset for us, why not let them help us with land cover?
>Воскресенье, 14 апреля 2019, 22:59 +03:00 от Christoph Hormann <
>[email protected] >:
>
>On Sunday 14 April 2019, Grigory Rechistov via Imports wrote:
>> Dear OSM community,
>> This is an announcement and request for comments, suggestions, and
>> approval of land cover information data import for the territory of
>> Sweden.
>>
>> [...]
>Had a quick look over your description.
>
>My general recommendation would be not to import any landcover data in
>OSM generated through automated classification of satellite imagery.
>There are multiple reasons for this, the most significant probably is
>that this is inherently incompatible with the tagging system and the
>way how things are mapped in OSM.
>
>Part of this stems from the very idea of closed landcover classification
>systems as not being meant to positively identify certain areas but
>assigning essentially the least unlikely of a set of potential classes
>to every point on the surface.
>
>Another part of this is due to many of the tagging distinctions we have
>in OSM - like natural=wood vs. natural=scrub, natural=scree vs.
>natural=bare_rock, landuse=commercial vs. landuse=industrial or
>leisure=park vs. leisure=garden being indistinguishable based on
>spectral characteristics alone.
>
>Therefore you'd not just be importing data into the existing OSM tagging
>system, you'd import the whole classification system and philosophy
>behind it.
>
>Don't get me wrong - i am not opposed to using automated analysis of
>open data satellite imagery for more efficient mapping in OSM. This
>has a lot of potential. But this has to be done specifically for OSM
>and for the tagging and mapping standards we have and it has to be
>controlled by the mapper. There is no shortcut to this by importing
>data sets created for a completely different purpose with completely
>different goals.
>
>--
>Christoph Hormann
>http://www.imagico.de/
С наилучшими пожеланиями,
Григорий Речистов.
Med vänliga hälsningar,
Grigory Rechistov
With best regards,
Grigory Rechistov
_______________________________________________
Imports mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/imports
