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
