On Tuesday 23 April 2019, Peter Barth wrote: > [...] > > From this quite small random sample I'd argue that this is a very low > quality import. I'm not really astonished about that, but I'm > questioning if it isn't time to increase our quality standards wrt > imports and introduce import permissions as opposed to just ignore > criticism and wait a week or two to import.
It is my impression that the problem here runs much deeper. It gets down to a fundamental dissent about what OSM is in essence - 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. The latter is quite clearly a minority opinion among active mappers but it is not a small one and it is a voiceful one (and also supported by quite a bit of money of course). People planning imports are very often approaching OSM with such views of a primacy of usefulness. This is the main reason why i mostly stopped reviewing imports here in substance. Because my critique and review work is aimed at making sure the import benefit and encourage human mappers in their work. In most cases people planning imports however have other goals that have higher priority for them (most often 'getting the data they have into OSM' for the benefit of data users) which makes attempts at working towards other goals fairly pointless and frustrating. I had a quick look at the areas you pointed to and concur that apart from the principal critique of the suitability of the data as a source for information in OSM the data preparation also seems of poor quality. 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). Partly this is also due to using a data source not meant for cartographic applications in the first place. In terms of concrete rules for imports to ensure certain standards of quality - designing clearer and more effective principles would certainly be possible, 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. But i am not sure if this would be of much benefit. Rules in OSM work when they represent consensus and serve to enforce this consensus against a few outliers. But as mentioned above we don't actually have a consensus on this matter so this would be more along the lines of enforcing a value system against a significant minority who disagree with those values. While i would want this to be possible (defending our core values against significant opposition) i am not sure this is still the case. As mentioned i am pretty sure that a majority of active mappers in OSM still supports the primacy of local knowledge and OSM being primarily a project of local mappers to cooperatively assemble their local knowledge but only a relatively small fraction of these are actually willing to defend those principles against other interests. Ultimately it is not the majority which decides where the journey goes but who is willing to invest time and fight for their interests and values. Another general side note not specific to imports and not specifically aimed at Grigory although i refer to his words here of course - 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 or that you are using them as synonyms for other terms you don't want to use because they don't fit your framing. In other words: Whatever you want to say - you do not support your argument by weaving in these words. -- Christoph Hormann http://www.imagico.de/ _______________________________________________ Imports mailing list Imports@openstreetmap.org https://lists.openstreetmap.org/listinfo/imports
