[Tagging] Fuzzy areas again: should we have them or not?

[Anders Torger]

It's difficult to make short replies, I'm sorry, so first a quick 
summary for those that don't have time to read:

The summary of this post is that I see OSM say one thing about its data 
principles but do another, and that is confusing to mappers. Either OSM 
need to implement what they say, or let data representation continue to 
evolve. Status quo just leads to lots of friction. I don't think it's 
fair to expect mappers to follow a specific way to map if the current 
data and OSM-Carto behavior point at something else. I also talk about 
the "tagging for the renderer" argument, where I claim that OSM-Carto 
behavior is an important complement to wiki documentation (and it's not 
something I have made up, I have been told so by OSM-Carto maintainers).

After that summary, on to the long discussion:

I perfectly understand that the original idea of OSM is only about 
strictly verifiable data and nothing about maps, the maps and routing 
products is just a side effect of what happens to be possible to make 
with that ground-truth data. I also understand that some see this as a 
very rigid and important core principle.

I also know that the OSM community is huge with lots of ideas and views 
of how OSM should develop onward. It's easy to see just by looking at 
what data that is entered, what issues that are reported and so on that 
there are lots and lots of mappers that look beyond the data in their 
editor and at what actually comes out of it in the end. No matter how 
aggressively that idea is attacked, it's here to stay, *unless* we start 
doing real policing in the database. Which is actually quite easy to do. 
Let's start with bays. You can do that with a script, just find all bays 
defined as polygons and replace them with a centrally placed point. And 
of course remove the rendering from OSM-Carto.

It's harder to get rid of fuzzy polygons inside forest polygons for 
example. But what we can do is simply remove the ability to name these 
polygons, as it doesn't make much sense to name any forest when say only 
50% of the names is verifiable with a strict interpretation of the 
verifiability principle, in rural nature I'd say it's even lower only 
10% or so as the nature is much more contiguous there. The only sane 
thing by a data consumer is then to ignore all these names, and if no 
data consumer will use the data, why enter it? Sure, if you have the 
view that OSM is only about the database and it doesn't matter if data 
gets used or not we could still enter it where it actually fulfills the 
strict interpretation of the verifiability principle, but I think few 
mappers find that motivating. I believe that it should be fun and 
rewarding to map.

Today neither existing OSM data or current OSM-Carto behavior is a good 
representation of a rigid view of the original OSM data principles. It 
has evolved. But as pointed out above it's technically easy to roll it 
back. So why is this not done? Either it's because OSM is unable to 
implement their own principles, or that there actually isn't a consensus 
that that we should roll it back. I think it's the latter.

I have in this thread stated that I wish OSM should not roll back to a 
more strict data model but rather let it evolve further where mappers 
want. I think a rollback is unneccessary, and a further development is 
low risk, ie we don't break egalitarian cooperation or introduce lots of 
more edit wars and policing etc. Especially if we do it piece by piece, 
tag by tag. I also think a further development introduces more value to 
the data and is good use of the unique crowd-sourcing resource we have.

However, I also think it's better to rollback than keeping status quo, 
which is only confusing to mappers and a source for unnecessary 
conflicts. It's not fair to lead mappers to falsely believe that they 
are welcome to enter a specific type of data, especially in this case 
when this data actually leads to functionality which cannot exist 
without it. In my case it's actually a deal breaker, if this type of 
data is not acceptable and/or the use of it will not evolve, then I 
won't map nature at all as it won't be possible to reach the level 
required that it can replace traditional maps in current use in 
Scandinavia, and if that cannot be done in the long term, I see no point 
in mapping it beyond simple illustrative uses.

That's why I would have liked to have a straight up answer, "should we 
have them or not" like in the thread title. I have come to know that 
it's probably not possible though, so then it will be about eternally 
arguing over this issue without getting anywhere, or just ignore what 
others think and just do my own way and hope that it will prevail in the 
database in the long run. Actually I think that is how most people do 
it, and that is why the data in the database is the way it is.

And then on to commenting the "tagging for the renderer" argument:

Caring about what the data can be used for in the end is not the same as 
tagging for the renderer. I don't think it's constructive if any 
discussion which goes one step further from the database and thinking 
about how the data can be used is bogged down with formulaic "tagging 
for the renderer" attacks.

Looking at what OSM-Carto does is not the same as "tagging for the 
renderer". That OSM-Carto is used to guide mappers of desired methods to 
use is not something I have made up myself, I've heard that from 
OSM-Carto maintainers in a issue report discussion about land cover 
pattern being drawn on top of rivers. I don't map virtual things, I only 
map stuff that is verifiable in a broad sense. But there are several 
ways to do that. Should we punch holes for water bodies inside forests 
or not? Most renderers don't care and draw water bodies on top, but 
OSM-Carto doesn't so then I do punch holes. What about technically 
splitting landcover polygons which otherwise cover huge area and get 
several thousands of inners? Some renderers draw these technical splits 
between same-type polygons as a visible border. But OSM-Carto does not, 
and maintainers of OSM-Carto says it's okay with such splits, so then 
it's probably okay. And so on.

OSM-Carto behavior works as a necessary complement to the loose wiki 
documentation to guide mappers on how to map, and I think that is a good 
approach. If we don't want that, we must make the wiki documentation 
much more detailed, and even if we do that we will get the problem that 
many mappers won't read that but instead just use OSM-Carto for 
sanity-checking their data they have entered, as they have always done.

/Anders

On 2020-12-24 20:04, stevea wrote:
> Long, prickly post ahead.