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

[Anders Torger]

These discussion of running around in the mountains on glaciers with a 
GPS often become quite theoretical :-). But anyway, the point I wanted 
to make is the risk of edit wars *in practice* is rather low even for 
named nature with more or less fuzzy borders, and is similar to the risk 
of edit wars due to accuracy challenges. I think that if edit war 
doesn't happen, a fuzzy area is fine to have and we shouldn't be overly 
strict about the verifiability principle.

I also think that that if we would pick out a representative group of 
mappers and have them describe what the verifiability principle means, 
what is okay to map or not, and why we have it, I think we would get 
largely varying answers, so it's very hard to make a strict 
interpretation be widely used, unless we enforce it with fixbots etc.

I can agree that it would be better to make a multipolygon that use 
existing coastlines rather than drawing a low poly on top some distance 
from the coastline. As multipolygons can share the same ways we don't 
need to duplicate any ways. Coastline bays would also make it easier to 
make a query engine. I think one can allow both methods (multipolygon 
edit is still quite difficult to do for many mappers, especially when 
sharing ways), but recommend coastline version.

While the negatives often focus on huge areas like the Alps etc, I see 
the main need for this is on small to medium scale. I have say 5 - 10 of 
these names per 10x10 km square in rural nature. These needs 
crowd-sourcing if they should be mapped. The Alps and other very large 
areas is perhaps less than 1000 names all over the world. It could be 
do-it-once static database on the side if we would like.

It's very interesting to know that the OSM-Carto decision to reward area 
mapping of bays was made by one person in disagreement with the others. 
I had no idea.

Open source projects are generally "you get a feature you what want by 
implementing it yourself", ie if you want some new feature, you can get 
it if you have the ability to yourself change the code. However, doing 
something that is in disagreement with others working in the same code 
repository is not normal. Sure "commit wars" can happen (same like edit 
wars in maps, but for source code), but it is rare, and point towards 
management issues. When there is a disagreement in an open source 
project there is generally either one "dictator" (quite common in open 
source, typically the original author) that decides what goes in or not 
if there is a conflict, or there is a consensus to only enter things 
that all agree on, and drop all controversial features. Projects often 
start out with a dictator or a very small and tight board. For older 
and/or larger open source projects the dictator is then often replaced 
with a concensus model or a deciding board of some sort. A deciding 
board can be better as the consensus model can cause the project to 
stall if the project is of the type that almost any new feature is 
controversial at some level.

I don't know what management model OSM-Carto is using, but if that has 
happened it seems like it would be a good idea to look it over.

Following these discussions and seeing the views about the necessity of 
fragmentation to achieve development it seems that OSM is in a situation 
where almost any new feature indeed is controversial, and therefore it 
is at risk of stalling.

/Anders

On 2020-12-24 18:03, Joseph Eisenberg wrote:

> Re: Glaciers again.
> 
> While it's possible for 2 mappers to disagree on the extent of a 
> glacier (or a river which quickly changes course) due to using 
> different aerial imagery, this can be fixed by visiting the location in 
> person and to confirm the edge of the glacier. This would be a 100% 
> verifiable geometry, because I could visit the same location and check 
> if the location is correct within the precision of my GPS device. While 
> this might not be practical for some glaciers in inaccessible places, 
> it is also possible to verify the geometry next year when new aerial 
> imagery becomes available.
> 
> In contrast, better or newer imagery will never make it easier to 
> determine where the Sierra Nevada ends and the Central Valley begins. 
> Imagery will also not help you decide which villages are suburbs of 
> Boston or not. Those boundaries are inherently non-verifiable.
> 
> Re: Bays.
> 
> You are right to mention that mapping bays as an area is a problem. 
> This has been discussed extensively at OpenStreetMap-Carto, and it 
> should be noted that the decision to render labels based on the mapped 
> area size was made by one person, without agreement by the other 
> maintainers of the map style.
> 
> Several of us think that it is a mistake to ask mappers to map these 
> huge geometries which are already well represented by the 
> natural=coastline on the sides which are verifiable. See 
> https://github.com/gravitystorm/openstreetmap-carto/issues/3634 and 
> https://github.com/gravitystorm/openstreetmap-carto/pull/3750.
> 
> -- Joseph Eisenberg
> 
> On Thu, Dec 24, 2020 at 5:37 AM Anders Torger <anders at torger.se> wrote:
> 
> When I made the starting post I didn't have a better name than "fuzzy 
> areas", and I don't really have it still, but what I meant to address 
> were those areas that are coined as "non-verifiable geometry" in 
> relation to the verifiability principle.
> 
> Glaciers are really hard to make an accurate outline of. I've done a 
> few of those and the problem I have here in Sweden is that you need 
> late summer photos to actually see where the ice is under the snow, and 
> you don't get that in the free photo layers, and you also need very 
> accurate topology correction of the photos, which indeed has become 
> much better in recent years but still leaves more to be desired.
> 
> However, regardless of that they are generally verifiable geometry in 
> the verifiability principle context. The challenge with glaciers is 
> that of accuracy not of verifiability.
> 
> Bays with wide openings to the sea on the other hand, where does it 
> end? That border is undefined and thus non-verifiable, and according to 
> a strict interpretation of the verifiability principle, which I see 
> leading OSM community members honor, those should then not be mapped as 
> a polygon, but should be mapped as a point placed somewhere clearly 
> inside (verifiably inside) the bay.
> 
> But let's talk about glaciers again, and other features whose challenge 
> is accuracy not verifiability. These features can lead to "edit wars" 
> if you have two mappers that use different sources and each of them 
> believe theirs is more accurate. Why do I bring that up? Because the 
> risk of "edit wars" due to conflict of how the geometry should be drawn 
> seems to be the primary argument against allowing drawing of 
> non-verifiable geometry. The argument goes that there would be lots of 
> edit war so we would need a policing entity and by that we would 
> through the whole egalitarian cooperation principle out the window.
> 
> However my answer to that is that the danger is exaggerated and we 
> already have plenty of non-verifiable geometry all over the map, 
> without any big issues of edit wars. They are not really much more 
> danger than those features that are hard to draw accurately. And we can 
> not just leave everything that out. Oh well, we can if we police it, 
> but we're not really that active in that (vandalism is more important 
> to stifle) and we can clearly see that mappers want to map these 
> things, so I don't think we should outlaw it, but instead drop the 
> passive resistance and let it evolve.
> 
> It does add value to the data. With an approximate geometry available a 
> renderer can make proper decisions of how big to make a text label, and 
> it's also free to move it around a bit to avoid collisions and improve 
> readability. Geometry also makes queries better, if you ask the map to 
> show a named bay or a plateau or forest or whatever, it can zoom to 
> that place and show the proper area of the map where it is rather than 
> zooming in max on a point. It shouldn't draw the outline though, as 
> it's defined as "fuzzy". Queries like asking if feature X borders to 
> feature Y also requires that geometry is available. Sure there can be 
> inaccuracies if you ask things like "is feature X within fuzzy feature 
> Y". Looking through the history there are suggestions of advanced 
> features where you can define how wide the fuzzy border is so the map 
> could answer "unclear" on such a question in addition to true/false, 
> but I think that is overkill. I would say that inaccurate answer on 
> border queries is a cheap price to pay.
> 
> It's more about if we *want* these geometries to exist or not. If we 
> want them, we can have them and their issues can be managed. If we 
> don't want them we can look at their specific challenges and exaggerate 
> and just say no to any proposal. But it seems like we will have some of 
> them anyway (they are in), unless we start policing and removing.
> 
> The problem with status quo is that there's mixed messages to mappers, 
> these geometries are in there and some are rendered, and are obviously 
> useful to the alternative (mapping as a point), but they are still 
> according to some against the rules, so when someone wants to develop 
> this further with a new tag, say for a plateau, it is at great risk of 
> getting roadblocked by the same strict interpretation of the 
> verifiability principle. Status quo also means a lot of passive 
> resistance towards these, for example by not rendering them, like 
> peninsula and valley tags today. There's one thing not rendering 
> snowmobile paths and other speciality information, another to leave out 
> generic map information like name of valleys, to me as a mapper that is 
> a message that we really don't care about this type of general-purpose 
> information or at least not if it must be made with a "non-verifiable 
> geometry".
> 
> That lead me to write the somewhat confrontational heading "should we 
> have them or not?" because I as a mapper is really tired of these mixed 
> messages, and in my personal mapping I already use these geometries a 
> lot and I am in need of more tags (plateau etc) and like others to be 
> rendered (valley, peninsula...). If powerful community members intends 
> to backtrack and move back to point mapping or even just continue the 
> passive resistance it means that a major motivational factor to map is 
> swept away for me, that of being able to properly name nature. So it 
> would be nice to know where OSM is heading...
> 
> A sidetrack of this discussion is if this should be in a different 
> database or not. It seems like GIS experts think it should be separate, 
> but OSM is not a traditional GIS system. I'm for any solution that 
> works though, but it must work seamlessly with OSM editors though as 
> these geometries are plentiful and needs crowd sourcing by the mappers 
> just as all other geometries.
> 
> On 2020-12-23 23:41, Graeme Fitzpatrick wrote:
> 
> On Thu, 24 Dec 2020 at 03:27, Martin Søndergaard 
> <sondergaard246 at gmail.com> wrote:
> 
> most interesting discussion I have seen on this list yet. And I want to 
> give a few of my thoughts as well.
> 
> Thank you, Martin!
> 
> Excellent post & I agree entirely with what you say.
> 
> As I mentioned a while back (may have been in another of Ander's 
> threads?) - we draw an area & say that this is a town / village, but 
> what about that house 300m down the road, & the one 500m beyond that? 
> Do those people think they live in this town?
> 
> My own city is a major built-up area, but as you go out into the 
> surrounding country, you come to suburbs with acre / <hectare house 
> blocks, then a bit further there are multi acre / hectare blocks, but 
> where does the "city" end?
> 
> On Thu, 24 Dec 2020 at 03:58, Joseph Eisenberg 
> <joseph.eisenberg at gmail.com> wrote:
> 
> * natural=glacier with ~56,000 entries
> * place=archipelago with ~1,300 entries
> 
> These three are not at all fuzzy, in the mathematical sense.
> 
> I'd question a couple of those thanks, Joseph.
> 
> Glaciers are constantly moving, so how can they not be fuzzy, 
> especially now with climate change apparently melting Arctic glaciers 
> at an ever increasing rate, so their boundaries must be constantly 
> changing?
> 
> & with archipelagos, & bigger island nations, whose boundaries are 
> drawn across the open ocean - how can we be precise about that line?
> 
> Thanks
> 
> Graeme
> 
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

  _______________________________________________
Tagging mailing list
Tagging at openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
_______________________________________________
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/20201225/a2967b82/attachment-0001.htm>