<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>I've been thinking more about these issues and I think what we need is a bit more pragmatic interpretation of the verifiability principle. What is the verifiability principle? It's that we should only add data that can be made independently by two different mappers using different data sources and still come to the same result. The reason we have that is due to that we want OSM to be egalitarian cooperation and that we should not need to have a policing entity. We're afraid that fuzzy areas, or "non-verifiable geometry" would lead to edit wars, and we would need policing to stifle that, and then we have broken the egalitarian cooperation idea.</p>
<p>This means that large bays with unclear borders like Vestfjorden outside Norway should be mapped as a point somewhere in the middle of it (where it's verifiable that it's clearly inside), and not as a polygon showing the approximate span of it. If we start to dive deeper into this we discover that what is verifiable and not is not that clear-cut though. If we keep to bays and straits, what about all those bays that have a narrow opening to the surrounding sea/lake? It's pretty well-defined where the end of that is even if it hasn't been documented anywhere ever, so maybe that can be considered verifiable geometry. However as bays open up and get wider and wider and less defined, the polygon would differ more and more between different mappers, and we enter the range what we traditionally call unverifiable geometry. Vestfjorden is an extreme example as it's almost like open sea. Still no edit wars on that though.</p>
<p>Then we have things like Skagerak Sea between Sweden, Norway and Denmark, it has some form of defined borders as it ends at defined villages and an island group. However the villages do span some area, and also the island group. I just had a look at the polygon. I can see that the mapper know about this border definition but I would place the corners somewhat differently if I had made it, but I wouldn't say that the polygon is wrong so I leave it untouched. I'd say that this is verifiable geometry even with a quite strict interpretation of verifiability, although the border can be put in a 3 km wide range or so. Not sure everyone would agree though.</p>
<p>A main reasons why you would want to map these features as a polygon rather than staying on the safe side and map them all as a point is that 1) it's more satisfying to map complete information (and showing the extent is more complete) and 2) a point won't work for either cartography or queries about these features. If we map Skagerak as a point it would only become a tiny label in the sea, totally useless for a map. Not only in OSM-Carto, but for any map renderer, as there is no size information attached to that point. Cartography would do quite well with a size-specification added to the point, but queries need a polygon, otherwise it will not be possible to ask questions like if "Kungshamn in Sweden is at Skagerak" or not. I don't think we have any system that can answer these questions anyway today, but if such would be developed in the future it needs that data. And as OSM is about geodata it seems like a most relevant goal, if it just can be fulfilled within the scope.</p>
<p>Like it or not, many mappers care about mapping all they know, and getting good maps as end results, and this is a strong motivator to include also what many consider non-verifiable geometry. Put in another way, if we force all these features to be only mapped as a point we quite significantly reduce the scope of what OSM can provide for map makers. Some believe this to be a small issue, others think it's larger. I belong the latter group. Even if we think it's a quite small issue, that should be weighed against what happens if we just relax a bit, opt for a pragmatic interpretation and let things evolve along the diverse paths mappers take.</p>
<p>So what about the edit wars, the policing and the egalitarian cooperation?</p>
<p>I think that the a strict interpretation of the verifiability principle and its rationale is not that believable any longer. Why? There is already plenty non-verifiable geometry in the database, OSM-Carto already renders and thus rewards some of them (like bays and straits), the edit war danger seems greatly exaggerated (often looking at not-yet existing extreme examples rather than the several thousands of already existing examples that haven't caused any edit wars), and policing already exists for other reasons out of necessity (vandalism and other malicious edits). There is also clearly already social hierarchies with some clearly very influential and powerful members, there is no such thing as a completely egalitarian community. You have tremendous power if you are a lead developer in some of the OSM software projects, or if you are in control of what gets done or not in the most popular renderers. Even if we look only at the group that is mappers and is not involved in development and delivery, there is already a social hierarchies formed in the local communities, and the local communities are important to maintain order and protect from vandalism. It's not a chaotic free for all, even if it looks like it on the surface.</p>
<p>In that context it seems unwise to push for a strict interpretation that outlaws what many mappers already do a lot of, and something that adds real value to the OSM data.</p>
<p>My view is that these "unverifiable geometries" actually are verifiable if you just have a bit more pragmatic interpretation. These geometries are verifiable that they exist, the rough extent is verifiable, and it's verifiable which borders that are defined and which that are a bit more loosely defined, in all the properties of the feature is verifiable and can be represented. We could choose to have a "fuzzy" tag or similar, but I think it's enough to tie it to the type of object it is. Anyone understands based on how a polygon is drawn and what type it is if it's exact or not. It's not a problem if a polygon will vary a bit mapper to mapper. It's only a problem if it becomes an edit war, and those would only occur in rather specific and rare cases.</p>
<p>So should we just throw verifiability under the bus then? No. These type of geometries is still something any mapper should handle with care. The key question to ask before you draw one is "how likely is it that there will be an edit war on this feature?". If it's highly unlikely, just go ahead and draw it. If it's likely or you are not sure, at least discuss it with your community first.</p>
<p>/Anders</p>
<p id="reply-intro">On 2020-12-23 18:23, Martin Søndergaard wrote:</p>
<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0">
<div id="replybody1">
<div dir="ltr">
<div>While some might not agree with the tone of Anders, I do think his "enthusiasm" has resulted in the most interesting discussion I have seen on this list yet. And I want to give a few of my thoughts as well.</div>
<div> </div>
<div>I think the discussion so far has been too focused on "does OSM need fuzzy areas?" while the reality is that the OSM database is already filled with fuzzy data; both areas and nodes. And here I don't mean "fuzzy" in the sense of "everything we map has some inherent error"; I mean real fuzzy data.</div>
<div> </div>
<div>First, we have the obvious ones: </div>
<div>
<ul>
<li>natural=bay with ~60,000 entries</li>
<li>natural=strait with ~4,000 entries</li>
<li>natural=reef with ~27,000 entries</li>
<li>natural=glacier with ~56,000 entries</li>
<li>place=archipelago with ~1,300 entries</li>
<li>place=sea and place=ocean with ~150 entries</li>
</ul>
<div> </div>
<div>All of these are "fuzzy" features which have no verifiable exact border, and currently they just exist in the database with no indication that they are in fact "fuzzy" features.</div>
<div>Often these features are also added as nodes instead of areas (probably because the exact area is impossible to define).</div>
</div>
<br />
<div class="v1gmail_quote">
<div class="v1gmail_attr" dir="ltr">On Tue, 22 Dec 2020 at 09:43, stevea <<a href="mailto:steveaOSM@softworkers.com" rel="noreferrer">steveaOSM@softworkers.com</a>> wrote:</div>
<blockquote class="v1gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left: 1px solid #cccccc; padding-left: 1ex;">"Names in nature" is an interesting, complex, challenging, yes, even strategic topic. I think we can get closer to "better," here on this list, with good, respectful, effective dialog. I look forward to that.</blockquote>
<div> </div>
<div>In my opinion this problem is in no way limited to "names in nature". Practically all place=* features (except the "Administratively declared places" category), such as City, Town, Village, Hamlet, etc. are "fuzzy" features, but no one seems to talk about them as such. These places are either defined as:</div>
<div>
<ul>
<li>An area: This is especially common with smaller settlements where the place=village or place=hamlet is just attached to some residential landuse area. But in every case where I have seen this type of tagging the resulting data is flatout incorrect. Suddenly the small park or commercial area in the center of the village isn't actually a part of the village; at least according to the tagging in the database. Or if it is a small hamlet with spread out houses (e.g. with small areas of farmland or meadows in between) I have several times seen the residential landuse being abused by connecting all the houses with a thin strip of landuse along a road. </li>
<li>A node: Here some person just defines an arbitrary point as the "center" of the village or town or city. Often the point is just placed where it will look the best on the map, i.e. "tagging for the renderer''. But even if you try to place it in the most correct center of the city, which center is that? Should it be the square in front of the town hall, the oldest part of the city, the infrastructure center of the city such as a central train station (this one might make a lot of sense for certain routing applications, but for many people it will just be strange). There is no correct answer. </li>
</ul>
<div>These features are by definition "fuzzy". I am not saying it is easy to define even a fuzzy area for a large city, but right now Copenhagen is, according to OSM data, just a single point placed arbitrarily in the front garden of a Copenhagen University building. Why? Because it results in a good place for the label on a map.</div>
</div>
<div> </div>
<div>People keep mentioning the ideals of "Map what's on the ground" and "Every feature has to be exact and verifiable", but combined with the reality of tons of "fuzzy" data already existing in the database the result is a kind of "false accuracy". The natural=bay or place=city or place=locality feature probably isn't located exactly where OSM says it is, and it is likely not limited to the exact location of the single node on which it is defined. But currently there is no structured way of knowing this.</div>
<div> </div>
<div>You can either make a new fuzzy=yes tag, or simply specify that natural=achipelago or place=town will always be fuzzy tags and editors should warn users not to make fuzzy areas too complicated or connect them with "exact" features such as landuse areas or roads.</div>
</div>
<div> </div>
<div class="v1gmail_signature" dir="ltr">/Martin Søndergaard</div>
</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>