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

[Kevin Kenny]

On Mon, Dec 21, 2020 at 3:01 PM stevea <steveaOSM at softworkers.com> wrote:

> I'm not sure, Kevin.  I do agree that imprecise data frequently enter OSM
> (may such imprecision be only minor, please) and that "fuzzy" can very well
> be a valuable extension of that concept, allowing it to widely envelop what
> might be meant by an explicit tag denoting "fuzzy."  Yet, I don't want
> endless haggling, it is counterproductive.
>
> Presently I do my best to listen.  I realize it is easy to shoot down what
> sounds like folly, while not contributing something positive instead.  As
> we're in an early stage of this discussion, I don't well comprehend what
> those who wish "fuzzy" to enter OSM mean to accomplish.  So, I watch its
> evolution, participating in discussion when I believe others might find
> value in my contributions.
>

That's why I'm presenting specific examples (Arietta Township, Hamilton
County, Jamaica Bay, the Red Sea) of, "this is the problem I have, and this
is the question about the data that I want to be able to answer."  I don't
think we can achieve a useful consensus here until and unless we can first
achieve consensus on whether, "In what county is Indian Lake vlllage", or
"Is Port Sudan on the shore of the Red Sea?" are questions that are in or
out of OSM's purview.

If they're in scope, then I think they could be a useful bellwether for the
easier 'indefinite area' problems. ("Alps" is a thornier case, but maybe we
could garner some useful insight by addressing the easier cases first.)

I'm pretty certain from the earlier discussions that Mateusz would argue
that these questions are out of scope, and that Frederik would also tend
toward that position, but perhaps qualify it as "maybe in scope, but
technologically infeasible."  Likewise, Paul and I have the view that as
long as there's the demand to answer questions such as these, people will
try to map these features as areas, and maybe the best we can do is choose
the 'least worst' representation, rather than insist that all area features
must meet some idealized standard of definiteness. It's indisputable that
we've seen these features come up on the map, and we've seen edit wars
ignite as a result, with bad behaviour on both sides.

Anders has been a bit confrontational, and a bit too inclined to take
personally the fact that we have a difficult modeling problem without even
a rough consensus - and by this I mean largely a rough consensus among the
developers of editors and renderers, which really guide the mapping choices
of the rest of us, for weal or woe. (By now, I've been around long enough
to know the limitations, so I've implemented a few of my own JOSM templates
and adapted some of my own rendering, all the better to focus on 'what does
the data model allow', as opposed to 'in what direction do the editors push
me' or 'what does the main rendering display').

Truly, though, I share his frustration. I surely get the impression -
mostly from the loudest voices here - that there is a budding consensus
that indefinite area features are indeed out of scope, and that a parallel
project will be needed to coordinate efforts to develop such a beast and
(more difficult) arrange for its hosting. That's a discouraging prospect. I
don't know whether I have either the energy or the necessary gift of
diplomacy to lead such a project, and I'm surely hoping that I'm wrong
about the developer consensus.

For what it's worth, I don't share his view that it's the result of a lack
of interest.  Getting the data model 'right' for this sort of feature is
something of a daunting problem, particularly since it has to stitch into
place along with what we already have.  It's only natural to hope that we
can define the problem away. I'm, unfortunately, insufficiently clever to
see how to avoid confronting it.

-- 
73 de ke9tv/2, Kevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20201221/fd560362/attachment-0001.htm>