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

[Anders Torger]

Maybe we need to split "small" and "large" fuzzy areas into different 
concepts. Or at least different discussions, as they are quite different 
in terms of how they affect the map and what needs they fulfill.

I do see a risk of edit wars of large fuzzy areas that make great impact 
on overview maps. I already thought we had that on country borders in 
conflict areas and such, so maybe we already have routines to deal with 
that? If we can't introduce features due to edit war risk, maybe the 
problem is not the feature as such, but how we can handle edit wars? 
Edit wars is completely new to me though, so I don't know much about 
this problem area or how much we normally let it affect our features.

I don't think these large fuzzy areas need to have very large amount of 
nodes by the way (they just lay on top, as they are defined as fuzzy 
it's unnecessary to specify lots of nodes), but they need to cover a 
large geographical area. You couldn't really edit them in JOSM or iD 
normally I think, but I don't think "normal" mappers would need to 
either. Having them in an external database and not integrate with the 
normal tools would be ok, and I guess that would also solve the edit war 
issue too. I'd very much like it to be rendered in OSM-Carto at some 
point though so we don't completely forget about it, but I would suspect 
that there are technical difficulties to do that with the current 
platform so we could skip that for now.

However, fuzzy areas needed for rural and outdoor maps cover a wetland, 
a piece of forest, a small plateau, a slope of a mountain, a valley, a 
peninsula in a lake etc, those are unlikely to be a problem in terms of 
edit wars. They are also small enough to be accessible for edit in JOSM 
and iD today, and as I often mention already exists and renders in the 
form of bays and straits, which I actually need to use quite often as we 
have these in our lakes of different sizes and coverage, meaning that 
point naming without size differentiation doesn't work.

Having a "fuzzy tag" I think is a good idea, although we could also do 
it as a flat structure with a list of tags that are defined as being 
fuzzy. Anything that works :-).

If there is large opposition from the people that make the renderers 
most of us use against these type of features I don't think we have much 
chance of success though. I think it's hard to get crowd-sourcing going 
if there is no renderer at all supporting it.

/Anders

On 2020-12-21 17:16, Paul Allen wrote:

> On Mon, 21 Dec 2020 at 15:47, Brian M. Sperlongano 
> <zelonewolf at gmail.com> wrote:
> 
>> The current data model works just fine for fuzzy areas: it requires a 
>> polygon combined with tagging that indicates that the area is "fuzzy". 
>>  Since the current data model allows both polygons and tags, fuzzy 
>> areas could be mapped just fine from a technical standpoint.
> 
> I assume that there is a technical limitation on the number of nodes in 
> such a
> polygon.  A limitation that may apply to any or all of editors, 
> database tables
> and renderers.  There may be some technical workarounds, there may not 
> be.
> 
>> "Whether we want fuzzy areas"
> 
> To an extent, everything we map is fuzzy, in that there is always 
> imprecision.
> Aerial imagery may be offset.  Roads may pass through woods giving 
> little or
> no visual indication.  GPS traces have errors and require many traces 
> to
> achieve good precision.  Everything we map is fuzzy in the sense that 
> it
> is imprecise but we live with that and understand that the map is an
> approximation that we may be able to improve upon at a subsequent date.
> 
> The dislike of fuzziness here appears to centre around verifiability.
> We don't want edit wars over the extent of a boundary for which
> no definitive answer can ever be given.  We want rigidly defined
> areas of doubt and uncertainty.  I'm not sure that a fuzzy tag
> will resolve that problem.  The precise boundary of a wetland
> doesn't matter too much and a few tens of metres either way
> isn't a problem; when it comes to "The Alps" that is a different
> matter.  Simply tagging an area as fuzzy doesn't mean another
> mapper won't disagree with your polygon and edit it.
> 
>> The statement that fuzzy polygons is "damaging" is an argument not 
>> based in fact.  It is not damaging to me to have building outlines, 
>> which I do not care about.  I can simply ignore them.  Likewise, fuzzy 
>> areas cause no damage to people that do not care about fuzzy areas, 
>> provided that there is tagging that distinguishes them from non-fuzzy 
>> areas.
> 
> The problem is the edit wars that may arise.  Not a technical issue but 
> a
> behavioural one.
> 
>> Further, since we have free tagging, there is nothing preventing 
>> mappers (especially ones not party to these conversations) from adding 
>> additional fuzzy areas to the database, mapped with some invented 
>> scheme, and potentially even creating data consumers to consume such 
>> invented tagging.  Many tagging schemes in OSM have arisen in this 
>> manner.
> 
> And there is the deeper problem.  People will do it anyway.  And 
> possibly have
> their additions reverted by the DWG.  Repeatedly.  In the short term, 
> that may
> work.  In the longer term, "any tag you want" may win.  You can't turn 
> back
> the tide but, with barriers you can divert it.
> 
> If we don't have fuzzy areas, people will abuse place=locality and 
> other
> tags to get labels rendered.  If we do have fuzzy areas then renderers
> can calculate label placement, label size, and which zoom levels the
> label appears at.  Fuzzy areas also mean we have meaningful tagging
> rather than abused tagging, which makes searching for such areas
> simpler.
> 
> --
> Paul
> 
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20201221/3ca3ac83/attachment-0001.htm>