<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /></head><body style='font-size: 10pt; font-family: Verdana,Geneva,sans-serif'>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>/Anders</p>

<p id="reply-intro">On 2020-12-24 18:03, Joseph Eisenberg wrote:</p>

<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0">

<div id="replybody1">

<div dir="ltr">

<div dir="ltr">

<div dir="ltr">

<div dir="ltr">Re: Glaciers again.

<div> </div>

<div>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. </div>

<div> </div>

<div>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. </div>

<div> </div>

<div>Re: Bays.</div>

<div> </div>

<div>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. </div>

<div> </div>

<div>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 <a href="https://github.com/gravitystorm/openstreetmap-carto/issues/3634" target="_blank" rel="noopener noreferrer">https://github.com/gravitystorm/openstreetmap-carto/issues/3634</a> and <a href="https://github.com/gravitystorm/openstreetmap-carto/pull/3750" target="_blank" rel="noopener noreferrer">https://github.com/gravitystorm/openstreetmap-carto/pull/3750</a>. </div>

<div> </div>

<div>-- Joseph Eisenberg</div>

</div>

</div>

</div>

</div>

<br />

<div class="v1gmail_quote">

<div class="v1gmail_attr" dir="ltr">On Thu, Dec 24, 2020 at 5:37 AM Anders Torger <<a href="mailto:anders@torger.se" rel="noreferrer">anders@torger.se</a>> wrote:</div>

<blockquote class="v1gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: #cccccc; padding-left: 1ex;">

<div style="font-size: 10pt; font-family: Verdana,Geneva,sans-serif;">

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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".</p>

<p>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...</p>

<p>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.</p>

<p id="v1gmail-m_-4217344996117551102reply-intro">On 2020-12-23 23:41, Graeme Fitzpatrick wrote:</p>

<blockquote style="padding: 0px 0.4em; border-left-width: 2px; border-left-style: solid; border-left-color: #1010ff; margin: 0px;">

<div id="v1gmail-m_-4217344996117551102replybody1">

<div dir="ltr">

<div dir="ltr"><br clear="all" />

<div>

<div dir="ltr">

<div dir="ltr">

<div>

<div dir="ltr"> </div>

</div>

</div>

</div>

</div>

</div>

<div dir="ltr">On Thu, 24 Dec 2020 at 03:27, Martin Søndergaard <<a href="mailto:sondergaard246@gmail.com" rel="noreferrer">sondergaard246@gmail.com</a>> wrote:</div>

<blockquote style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: #cccccc; padding-left: 1ex;">

<div dir="ltr">

<div>most interesting discussion I have seen on this list yet. And I want to give a few of my thoughts as well.</div>

</div>

</blockquote>

<div> </div>

<div>Thank you, Martin!</div>

<div> </div>

<div>Excellent post & I agree entirely with what you say.</div>

<div> </div>

<div>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?</div>

<div> </div>

<div>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?</div>

<div> </div>

<div> </div>

<div>

<div dir="ltr">On Thu, 24 Dec 2020 at 03:58, Joseph Eisenberg <<a href="mailto:joseph.eisenberg@gmail.com" rel="noreferrer">joseph.eisenberg@gmail.com</a>> wrote:</div>

<blockquote style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: #cccccc; padding-left: 1ex;">

<div dir="ltr">

<div dir="ltr">

<div dir="ltr">

<div dir="ltr">

<div dir="ltr">

<div dir="ltr">

<div>

<ul>

<li style="margin-left: 15px;">natural=glacier with ~56,000 entries</li>

<li style="margin-left: 15px;">place=archipelago with ~1,300 entries</li>

</ul>

These three are not at all fuzzy, in the mathematical sense. </div>

</div>

</div>

</div>

</div>

</div>

</div>

</blockquote>

<div> </div>

<div>I'd question a couple of those thanks, Joseph.</div>

<div> </div>

<div>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?</div>

<div> </div>

<div>& with archipelagos, & bigger island nations, whose boundaries are drawn across the open ocean - how can we be precise about that line?</div>

<div> </div>

<div>Thanks

<div> </div>

<div>Graeme</div>

<div> </div>

</div>

</div>

</div>

</div>

<br />

<div style="margin: 0px; padding: 0px; font-family: monospace;">_______________________________________________<br />Tagging mailing list<br /><a href="mailto:Tagging@openstreetmap.org" rel="noreferrer">Tagging@openstreetmap.org</a><br /><a href="https://lists.openstreetmap.org/listinfo/tagging" target="_blank" rel="noopener noreferrer">https://lists.openstreetmap.org/listinfo/tagging</a></div>

</blockquote>

<p><br /></p>

</div>

_______________________________________________<br />Tagging mailing list<br /><a href="mailto:Tagging@openstreetmap.org" rel="noreferrer">Tagging@openstreetmap.org</a><br /><a href="https://lists.openstreetmap.org/listinfo/tagging" target="_blank" rel="noopener noreferrer">https://lists.openstreetmap.org/listinfo/tagging</a></blockquote>

</div>

</div>

<br />

<div class="pre" style="margin: 0; padding: 0; font-family: monospace">_______________________________________________<br />Tagging mailing list<br /><a href="mailto:Tagging@openstreetmap.org">Tagging@openstreetmap.org</a><br /><a href="https://lists.openstreetmap.org/listinfo/tagging" target="_blank" rel="noopener noreferrer">https://lists.openstreetmap.org/listinfo/tagging</a></div>

</blockquote>

<p><br /></p>

</body></html>