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

Wed Dec 23 17:55:57 UTC 2020

Re:

   - natural=reef with ~27,000 entries
   - natural=glacier with ~56,000 entries
   - place=archipelago with ~1,300 entries

These three are not at all fuzzy, in the mathematical sense.

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"

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.

2) Glaciers are verifiable in person and via aerial imagery: they are very
distinctive areas of permanent ice.

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.

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).

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.

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.

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

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.

-- Joseph Eisenberg

On Wed, Dec 23, 2020 at 9:27 AM Martin Søndergaard <sondergaard246 at gmail.com>
wrote:

> 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.
>
> 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.
>
> First, we have the obvious ones:
>
>    - natural=bay with ~60,000 entries
>    - natural=strait with ~4,000 entries
>    - natural=reef with ~27,000 entries
>    - natural=glacier with ~56,000 entries
>    - place=archipelago with ~1,300 entries
>    - place=sea and place=ocean with ~150 entries
>
> 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.
> Often these features are also added as nodes instead of areas (probably
> because the exact area is impossible to define).
>
> On Tue, 22 Dec 2020 at 09:43, stevea <steveaOSM at softworkers.com> wrote:
>
>> “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.
>
>
> 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:
>
>    - 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.
>    - 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.
>
> 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.
>
> 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.
>
> 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.
>
> /Martin Søndergaard
> _______________________________________________
> 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/20201223/55da36d3/attachment-0001.htm>