[Imports] Import of forests, farmland and other types of land cover for Sweden generated from Naturvårdsverkets Nationella Marktäckedata 2018

[Grigory Rechistov]

Hello!
Let me first give a few comments to Christoph Hormann's excellent points about 
what OSM-project is for different people. Then I want to comment on Kevin's and
Frederik's points that I find important.
I will give an update on what current plans about this NMD-data import are in a 
separate mail.
> whether it is a project for humans to cooperatively assemble their own local 
> knowledge or if it is a project with the primary goal to collect 
> subjectively useful geodata under a uniform license and in a uniform 
> format for the convenience of data users.
I get your point here, and I feel that for me personally OSM is indeed not limited to
local knowledge as primary source of geodata. It is usefulness of the OSM map 
that brought me into the project, not its ideals. Maybe one day I will share the
same ideals at some point. My personal believes include the notion of me being 
lazy (to map things by hand) but curious (to visit places I mapped or want to map),
and trusting that Technology can help Humanity to reach whatever goals we have.
A full world map would never have been drawn with using just local knowledge.
Why limit ourselves to stone age ax and a wooden stick when we have iron knives
and planes? Moreover, we live now in information age, why not make use of
information at our hands?
> Partly this is stuff that could be fixed by better data processing (at 
> least in theory - this is not stuff you do with a few mouse clicks in 
> some standard software).
Maybe not with a few clicks, but yes, there are GIS-frameworks that have very powerful
tools to work with raster data. Even Open-Source ones can do that, but not JOSM.
People do make very nice maps these days, apparently using raster data as some sort
of base for them. I do want to see similar tools and capabilities for JOSM,
and I want to make efforts in this direction, if no one else wants.
> Partly this is also due to using a data source not meant for cartographic applications in the first place.
Trees in nature are not meant as a data source for any map either - they just grow there.
It is always humans who interpret them as a "forest" and sometimes draw them as polygons
on a piece of dead tree or a surface of silicon/liquid crystals.
Data cannot be free of human interpretation, it is the interpretation that gives
value/meaning to data. Such interpretation might be partially not corresponding
to real world, but if the error is measurable, it can be acted upon.
> In terms of concrete rules for imports to ensure certain standards of 
> quality - designing clearer and more effective principles would 
> certainly be possible,
I support it as well, however more from a technical standpoint rather than an
administrative position. I believe that if something can be measured, it can be 
improved upon. For example, for the initial import I still see zero 
warnings here: http://osmose.openstreetmap.fr/en/byuser/Atakua_imports
I would expect hundreds of new markers with messages like:
- "weird small triangles of empty surfaces clammed between landuse"
- "this node is too close to a way"
- "two forest/water ways intersect each other several times on a short interval"
- "how can a swamp be triangular, silly?"
- etc.
But I see zero there. These problems are characteristic to importing of land cover 
data and surely can be algorithmically detected before and after importing. I
feel like there is lack of work in this direction as everyone is busy with roads 
and points of interest. But nothing that cannot be implemented in software 
with a bit of an effort in some time.

> for example we could add the requirements that 
> any import needs to be co-sponsored by at least three local mappers 
> with on-the-ground mapping experience in the area of the import and who 
> share responsibility for the quality of the import.
I can find a couple of more folks there that are tired of drawing forest by hand
and want to get a chance of doing it as automatically as possible. And I have
ground mapping experience, and I do wish to share, or bear or whatever responsibility
on the quality. I already do. By the way, very good proposal about local 
knowledge, it kinda pushes me to get there personally and look around to gain 
more confidence in what I map, and to see nice remote places at the same time.
> terms like "fuzzy", "blurred" and "fractal" have become kind of fashionable 
> in OSM to create a certain framing. My suggestion would be not to use 
> them. Because once you try defining these terms to give them actual 
> meaning you will realize that how you use them does not really make much sense
These are very precise terms for me in mathematical sense, even if they describe
"imprecise" things.
---------------------------
Now, to Kevin Kenny's important remark about alternatives of data representation.
> Personally, I don't import landcover, ever. I use external sources of
> landcover information, to produce maps like
> http://kbk.is-a-geek.net/catskills/test4.html?la=42.2856&lo=-74.1710&z=14
> Not everything that a data consumer renders has to come from OSM!
I use this approach to combine elevation contourlines obtained elsewhere as a 
separate layer. The rest of the data is based on OSM and is a separate map/layer.
This main map comes from a commercial provider who goes through the trouble of 
regularly regenerating maps for the whole world, including Sweden. I am not sure 
that this provider would be very interested in adding a separate data layer 
specifically for me for just one country. Sure, I can generate a land cover 
layer for myself only and let it be ugly but useful for me.'
I already did it for contourlines; they are ugly but I like them more than those 
coming from the aforementioned map provider. But then I cannot share my land 
cover work with others unless I maintain a webserver that distributes a new 
layer as a map, pay for its bandwidth, do advertising etc.
I would rather have as much as possible in one place, like the OSM database.
Note these two things: forcing a user to generate maps himself because OSM is 
not a map but a database, and lack of layers in OSM. They are OSM's 
principal design decisions that some people consider very hampering OSM's success:
See [1], sections "When the World Needs a Map, Give them a Database", and "OSM's
Lack of Layers". 
Regardless of whether it is good or bad, if we want to make data useful to others
via the OSM project, it has to be integrated into the one and only layer of data.
-----------------------------
Now to Frederik Ramm's questions.
> put the import on hold until its usefulness has been widely agreed
It is already on hold in a sense that we are reconsidering which parts of it 
should be imported (with local people's feedback on certain municipalities),
what data cleanup tools should be applied/developed to assist with data
transformations and quality assurance. However, individual contributors (not me,
I am too busy working on tools) are free to base their manual mapping work on 
already generated vector data by manually cleaning it up to their liking.
After all, it is not an automatic import if someone looked at each and every new
polygon, cleaned them from discovered errors and uploaded them.
> take these comments, and Christoph's, back to the Swedish list and
> ask someone impartial to summarize the discussion on the Swedish list to us?
I will ask someone from the list (not myself, at least not myself of the same
user account :-) ) to prepare such a summary. The discussion at talk-se continues
however, so new results/opinions may appear there.
> It sounds unlikely to me that Christoph and Peda are the first to see
> problems; they must have been aired (and ignored?) in the discussion on
> the Swedish list as well!
Sure, certain problems with data were sounded there, some were the same as on this
list, some were about more specificly pinpointed issues.
Some people liked new data as it is, many disliked it,
but everyone there agrees that it should be done better than now.

References:
1. Serge Wroclawski. https://blog.emacsen.net/blog/2018/02/16/osm-is-in-trouble/
  С наилучшими пожеланиями,
Григорий Речистов.
Med vänliga hälsningar,
Grigory Rechistov
With best regards,
Grigory Rechistov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/imports/attachments/20190429/0a0fbf67/attachment.html>