

<HTML><BODY><p>Hello!</p><p>Let me first give a few comments to Christoph Hormann's excellent points about <br>what OSM-project is for different people. Then I want to comment on Kevin's and<br>Frederik's points that I find important.</p><p>I will give an update on what current plans about this NMD-data import are in a <br>separate mail.</p><p>> whether it is a project for humans to cooperatively assemble their own local <br>> knowledge or if it is a project with the primary goal to collect <br>> subjectively useful geodata under a uniform license and in a uniform <br>> format for the convenience of data users.</p><p>I get your point here, and I feel that for me personally OSM is indeed not limited to<br>local knowledge as primary source of geodata. It is usefulness of the OSM map <br>that brought me into the project, not its ideals. Maybe one day I will share the<br>same ideals at some point. My personal believes include the notion of me being <br>lazy (to map things by hand) but curious (to visit places I mapped or want to map),<br>and trusting that Technology can help Humanity to reach whatever goals we have.</p><p>A full world map would never have been drawn with using just local knowledge.<br>Why limit ourselves to stone age ax and a wooden stick when we have iron knives<br>and planes? Moreover, we live now in information age, why not make use of<br>information at our hands?</p><p>> Partly this is stuff that could be fixed by better data processing (at <br>> least in theory - this is not stuff you do with a few mouse clicks in <br>> some standard software).</p><p>Maybe not with a few clicks, but yes, there are GIS-frameworks that have very powerful<br>tools to work with raster data. Even Open-Source ones can do that, but not JOSM.<br>People do make very nice maps these days, apparently using raster data as some sort<br>of base for them. I do want to see similar tools and capabilities for JOSM,<br>and I want to make efforts in this direction, if no one else wants.</p><p>> Partly this is also due to using a data source not meant for cartographic applications in the first place.<br>Trees in nature are not meant as a data source for any map either - they just grow there.<br>It is always humans who interpret them as a "forest" and sometimes draw them as polygons<br>on a piece of dead tree or a surface of silicon/liquid crystals.<br>Data cannot be free of human interpretation, it is the interpretation that gives<br>value/meaning to data. Such interpretation might be partially not corresponding<br>to real world, but if the error is measurable, it can be acted upon.</p><p>> In terms of concrete rules for imports to ensure certain standards of <br>> quality - designing clearer and more effective principles would <br>> certainly be possible,</p><p>I support it as well, however more from a technical standpoint rather than an<br>administrative position. I believe that if something can be measured, it can be <br>improved upon. For example, for the initial import I still see zero <br>warnings here: http://osmose.openstreetmap.fr/en/byuser/Atakua_imports</p><p>I would expect hundreds of new markers with messages like:<br> - "weird small triangles of empty surfaces clammed between landuse"<br> - "this node is too close to a way"<br> - "two forest/water ways intersect each other several times on a short interval"<br> - "how can a swamp be triangular, silly?"<br> - etc.</p><p>But I see zero there. These problems are characteristic to importing of land cover <br>data and surely can be algorithmically detected before and after importing. I<br>feel like there is lack of work in this direction as everyone is busy with roads <br>and points of interest. But nothing that cannot be implemented in software <br>with a bit of an effort in some time.<br> <br>> for example we could add the requirements that <br>> any import needs to be co-sponsored by at least three local mappers <br>> with on-the-ground mapping experience in the area of the import and who <br>> share responsibility for the quality of the import.</p><p>I can find a couple of more folks there that are tired of drawing forest by hand<br>and want to get a chance of doing it as automatically as possible. And I have<br>ground mapping experience, and I do wish to share, or bear or whatever responsibility<br>on the quality. I already do. By the way, very good proposal about local <br>knowledge, it kinda pushes me to get there personally and look around to gain <br>more confidence in what I map, and to see nice remote places at the same time.</p><p>> terms like "fuzzy", "blurred" and "fractal" have become kind of fashionable <br>> in OSM to create a certain framing. My suggestion would be not to use <br>> them. Because once you try defining these terms to give them actual <br>> meaning you will realize that how you use them does not really make much sense</p><p>These are very precise terms for me in mathematical sense, even if they describe<br>"imprecise" things.</p><p>---------------------------</p><p>Now, to Kevin Kenny's important remark about alternatives of data representation.</p><p>> Personally, I don't import landcover, ever. I use external sources of<br>> landcover information, to produce maps like<br>> http://kbk.is-a-geek.net/catskills/test4.html?la=42.2856&lo=-74.1710&z=14<br>> Not everything that a data consumer renders has to come from OSM!</p><p>I use this approach to combine elevation contourlines obtained elsewhere as a <br>separate layer. The rest of the data is based on OSM and is a separate map/layer.<br>This main map comes from a commercial provider who goes through the trouble of <br>regularly regenerating maps for the whole world, including Sweden. I am not sure <br>that this provider would be very interested in adding a separate data layer <br>specifically for me for just one country. Sure, I can generate a land cover <br>layer for myself only and let it be ugly but useful for me.'<br>I already did it for contourlines; they are ugly but I like them more than those <br>coming from the aforementioned map provider. But then I cannot share my land <br>cover work with others unless I maintain a webserver that distributes a new <br>layer as a map, pay for its bandwidth, do advertising etc.<br>I would rather have as much as possible in one place, like the OSM database.</p><p>Note these two things: forcing a user to generate maps himself because OSM is <br>not a map but a database, and lack of layers in OSM. They are OSM's <br>principal design decisions that some people consider very hampering OSM's success:<br>See [1], sections "When the World Needs a Map, Give them a Database", and "OSM's<br>Lack of Layers". <br>Regardless of whether it is good or bad, if we want to make data useful to others<br>via the OSM project, it has to be integrated into the one and only layer of data.</p><p>-----------------------------</p><p>Now to Frederik Ramm's questions.</p><p>> put the import on hold until its usefulness has been widely agreed</p><p>It is already on hold in a sense that we are reconsidering which parts of it <br>should be imported (with local people's feedback on certain municipalities),<br>what data cleanup tools should be applied/developed to assist with data<br>transformations and quality assurance. However, individual contributors (not me,<br>I am too busy working on tools) are free to base their manual mapping work on <br>already generated vector data by manually cleaning it up to their liking.<br>After all, it is not an automatic import if someone looked at each and every new<br>polygon, cleaned them from discovered errors and uploaded them.</p><p>> take these comments, and Christoph's, back to the Swedish list and<br>> ask someone impartial to summarize the discussion on the Swedish list to us?</p><p>I will ask someone from the list (not myself, at least not myself of the same<br>user account :-) ) to prepare such a summary. The discussion at talk-se continues<br>however, so new results/opinions may appear there.</p><p>> It sounds unlikely to me that Christoph and Peda are the first to see<br>> problems; they must have been aired (and ignored?) in the discussion on<br>> the Swedish list as well!</p><p>Sure, certain problems with data were sounded there, some were the same as on this<br>list, some were about more specificly pinpointed issues.<br>Some people liked new data as it is, many disliked it,<br>but everyone there agrees that it should be done better than now.</p><p><br>References:</p><p>1. Serge Wroclawski. https://blog.emacsen.net/blog/2018/02/16/osm-is-in-trouble/</p><p> </p>С наилучшими пожеланиями,<br>Григорий Речистов.<br>Med vänliga hälsningar,<br>Grigory Rechistov<br>With best regards,<br>Grigory Rechistov<br><style type="text/css"></style></BODY></HTML>