<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Re:<div><ul><li style="margin-left:15px">natural=reef with ~27,000 entries</li><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><br></div><div>Since it has never been defined in this conversation that I recall, let's start with a definition of "fuzzy":  "Fuzzy" logic in math or data is a "means of representing vagueness and imprecise information"</div><div><div><br></div><div><span style="color:rgb(0,0,0);font-family:-webkit-standard;font-size:medium"></span>1) Reefs in OpenStreetMap are mapped when you can see the reef under the water on aerial imagery. This is verifiable and fairly precise, within a few meters. </div><div><br></div><div>2) Glaciers are verifiable in person and via aerial imagery: they are very distinctive areas of permanent ice.</div><div><br></div><div>3) Archipelagos are partially cultural concepts but most often represent island groups which are close together and share a geological origin, as well as a human-created name. In OpenStreetMap they are mapped as multipolygon relations which contain each island's coastline, so this is quite precise and verifiable by visiting the area in person and asking the local people the name of the island group or chain.</div><div><br></div><div>However, there certainly are examples of regions which are inherintly "fuzzy", aka "the boundaries are not verifiable." It is quite reasonable to consider the area of a region like "The Alps" to be fuzzy, because no two people will agree on where to draw the outer boundary of a line which represents where the Alps stop. The same problem happens when trying to define many kinds of regions as an area, including valleys, seas, and even named cities (since the cultural definition of a city is often different from the administrative boundary). </div><div><br></div><div>In some cases, like with mountains or valleys, it might be possible to create a definition with a precise boundary by using topographical extremes: that is, a valley would be defined as extended all the way to the ridgeline of all surrounding hills, and a mountain would be defined as extended all the way to the lowest topography in the surrounding valley. Unfortunately this definition does not match the most common cultural meaning of the concepts, since it includes all land as part of both a valley and a mountain, when taken to the limit. For example, by this definition Geneva would both be in the Rhone valley and in the Alps. Milan would be in the Alps and in the Po valley. Sacramento California would be in the Central Valley but also in the Sierra Nevada mountain region, the same as Yosemite National Park's main lodge.</div></div><div><br></div><div>So the best option for many of these features is to map the centre, rather than the edges: the center of the Sierra Nevada is the peaks along the highest ridge, and could reasonably be mapped as a natural=mountain_range way which follows all the highest ridges. The center of the Po valley is the Po river - this is already mapped, so I'm not sure that we need to represent it a second time. But some valleys are mapped as linear ways. </div><div><br></div><div>The centre of a city is mapped as a node at the economic/cultural central point. While one might argue about whether the centre of Tokyo is on this street or another, the node placement is much more precise than any outer boundary in the suburbs, which could be debatable for 10s of kilometers</div><div><br></div><div>The principle here is that we should map the most verifiable feature: when an area is fuzzy (the boundaries are not verifiable), it is often better to map the center as a node or linear way, when this can be agreed upon and confirmed to be correct by other mappers.</div><div><br></div><div>-- Joseph Eisenberg</div></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Dec 23, 2020 at 9:27 AM Martin Søndergaard <<a href="mailto:sondergaard246@gmail.com">sondergaard246@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><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><br></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><br></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="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 22 Dec 2020 at 09:43, stevea <<a href="mailto:steveaOSM@softworkers.com" target="_blank">steveaOSM@softworkers.com</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);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><br></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><br></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><br></div><div dir="ltr">/Martin Søndergaard<br></div></div>
_______________________________________________<br>
Tagging mailing list<br>
<a href="mailto:Tagging@openstreetmap.org" target="_blank">Tagging@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/tagging" rel="noreferrer" target="_blank">https://lists.openstreetmap.org/listinfo/tagging</a><br>
</blockquote></div>