Hi Christoph, Thank you for a detailed answer with your concerns. It becomes clearer to me now.
> lack of language knowledge to read the specifications of the production > method and the landcover classes in it. In the PDF on pages 52-55 there are English descriptions of classes used in the original raster: https://wiki.openstreetmap.org/wiki/File:NMD_Produktbeskrivning_NMD2018Basskikt_v1_0.pdf . Note that we used not all of these classes, and in fact merged several classes of forests into a fewer sets of groups of OSM-tags. >the class 'forest' is the one least unlikely to apply here. >In OSM OTOH we tag based on positive identification. The conceptual difference between two classification principles is clear to me, and it may be a deciding factor in certain life applications, where the cost of misclassification is very high. But does it make a practical difference in this particular use case? What's the cost of occasional misclassification of forests, if we assume that overall quality of input data is high (i.e. mistakes happen but they are rare)? I would additionally argue that frequency of errors of source data for this import is as low or even lower than errors to stem from using stale aerial imagery (e.g. drawing forests where trees have been recently cut) and rounding/resolution/digitalization/human hand unsteadiness. >We don't have a fixed catalogue of tags and say: every point of the earth >surface has to be mapped as one of these. I agree, OSM does not strive to force a mutually exclusive data classification scheme. With one (implicit) exception: there are areas on the map with *no data* and areas with *some data*. Not an enforcement but a limitation we have. This import is meant to convert areas with *no data* into areas with *some data*. For areas when there already are polygons with arbitrary tag combinations carefully assigned by previous mappers, we do not plan to simply delete their work, saying: "our source says there should be forest and nothing else". But for blank areas, nobody can state: "there are no objects of interest for humans and there will never be". Heck, I can see there are trees there! Not necessarily a forest, surely may be a park. Unlikely to be a park though - the closest human dwelling is 10 km away. But *certainly* not white void like the current map says. >No one will object if you use it for such but you are wrong to assume that >suitability for this is in any way a point of consideration when the data set >is produced. I am just fine with "no one will object" part, and I do not care about if "I am wrong to assume" if in the end everyone is happy (or at least not entirely against) and we all have a nice set of land cover information that people like me find useful for their rare moments of pleasure being in nature :-) > But this means the mappers specifically having the computer do certain work > *to their liking and based on their individual judegement*. But this is exactly my point. > You however here seem to be rejecting the very idea of OSM to create a map by > people based on their local knowledge. Nothing beats local knowledge, and this remains to be a ground principle of making maps, not just OSM. Moreover, if I had local knowledge of certain areas of the world, I wouldn't need a map for them for myself; but maybe I would be interested to create such a map for others. But for areas I am interested in, not many locals live there (except for bears, but they don't map in JOSM/iD much). >to support local mappers in their work documenting In fact, I try visiting places (when my time allows) I previously mapped by using aerial image to check if I got it right. Have a plan to make a route predominantly consisting of "highway=track" roads I've added and to ride it on my bike to learn how many of them I got right; following these roads always ends up in a cool adventure. >I would love to see tools for example that assist mappers in delineating >forested areas based on multispectral satellite images with much less hand >tracing work. Such would be a big step forward and a real game changer in >mapping in OSM. Yes, this is what you mean by tools tailored for OSM use, kind of scanaerial but actually capable of tracing forests. >But as i hope i explained using ready-made landcover classifications is not a >substitute for such approach. I might be stretching it a bit, but existing available aerial imagery widely used by OSM mappers was not made for OSM use either, it is just images. Sure, no classification attempts or other enhancements (apart from stitching it together, aligning, cropping…) were usually applied to it during its production, but imagery may still lead humans into misclassification of objects, like mistreating canals for roads, cloud shadows for objects etc. It is always a matter of signal-to-noise ratio we can squeeze from a specific data source. >We have had quite a few initiatives to import automated land cover >classification data in OSM >and we will continue to get more of them "Our greatest weakness lies in giving up. The most certain way to succeed is always to try just one more time. // Thomas A. Edison" >with the whole AI hype that enables more people to produce such without >significant background knowledge. What it is already, the second AI hype since 1960's, I presume? But like many other technology hype waves, there well might be a productivity plateau that follows it. I do hope that we are at that plateau this time. But if it turns out to not be the case… let's try just one more time later. >Среда, 17 апреля 2019, 13:19 +03:00 от Christoph Hormann <[email protected]>: > > >Note i specifically did not make any statement as to the quality of the >data you are basing this import on. This is for several reasons > >* lack of time to actually look at the data in more detail. >* lack of language knowledge to read the specifications of the >production method and the landcover classes in it. >* lack of agreement how to objectively measure quality for the purpose >of importing in OSM (see also the remark on the purpose of the data >below). > >> 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. > >I explained this - a landcover classification system identifying a >certain pixel as 'forest' (f.s.v.o. forest) just says that of the full >set of classes it has the class 'forest' is the one least unlikely to >apply here. In OSM OTOH we tag based on positive identification. We >don't have a fixed catalogue of tags and say: every point of the earth >surface has to be mapped as one of these. > >> 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. > >That is a misconception. That data set was produced with a certain >purpose and is optimized to serve exactly that purpose (and be at the >same time as cheap to produce as possible of course). It is decidedly >not meant for cartographic applications. No one will object if you use >it for such but you are wrong to assume that suitablility for this is >in any way a point of consideration when the data set is produced. > >> 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. > >As said - i very much support use of algorithms to support mappers in >their work, in particular for geometry generation. But this means the >mappers specifically having the computer do certain work *to their >liking and based on their individual judegement*. You however here >seem to be rejecting the very idea of OSM to create a map by people >based on their local knowledge. This does not seem a very good basis >for doing an import in OSM where your primary consideration should be >to support local mappers in their work documenting their local >knowledge and not sparing them the work of doing so. > >I would love to see tools for example that assist mappers in delineating >forested areas based on multispectral satellite images with much less >hand tracing work. Such would be a big step forward and a real game >changer in mapping in OSM. But as i hope i explained using ready-made >landcover classifications is not a substitute for such approach. > >Note while i am pretty convinced importing this data into OSM is not a >good idea i am kind of torn here. We have had quite a few initiatives >to import automated land cover classification data in OSM, most of them >not worked out as far as yours, and we will continue to get more of >them in particular with the whole AI hype that enables more people to >produce such without significant background knowledge. With this >background it would be kind of useful to have a demonstration which >would show the problems certainly much better than the theoretical >considerations i provide here. > >-- >Christoph Hormann >http://www.imagico.de/ > >_______________________________________________ >Imports mailing list >[email protected] >https://lists.openstreetmap.org/listinfo/imports С наилучшими пожеланиями, Григорий Речистов. Med vänliga hälsningar, Grigory Rechistov With best regards, Grigory Rechistov
_______________________________________________ Imports mailing list [email protected] https://lists.openstreetmap.org/listinfo/imports
