[Tagging] coastline v. water

Kevin Kenny kevin.b.kenny at gmail.com
Mon Nov 23 23:44:25 UTC 2020


On Mon, Nov 23, 2020 at 2:57 PM Frederik Ramm <frederik at remote.org> wrote:

> Now, you might smirk and say "let's fix the tools then", but until the
> tools are fixed - which might take years -, you've made life a hell of a
> lot harder for anyone editing or quality monitoring in the whole area.
>
> And all for what - a nice blue label in the bay?
>

TL;DR: I understand the technical problems. Don't let the technical
problems block the discussion for people who might be able to develop
technical solutions.



Back when this discussion started, it started because you deleted a
relation for the Gulf of Bothnia, entirely without warning, without
discussion, and without mentioning it in public even afterward until it was
noticed and you were called on it in public. Generally speaking, it was
accepted, ex post facto, as an emergency measure needed to rescue the
servers from a performance trap, and most of us were willing to accept a
temporary moratorium on creating large area relations because of the
technical complications.

That issue became complicated because others chimed in and started to argue
that, rather than being a measure to rescue the servers from trouble, it
was actually a reflection of a universally accepted policy that every
millimetre of an area feature's boundary must be unambiguously defined and
visible on the ground, and the discussion rapidly deteriorated because that
definition, taken to its logical extreme, would exclude virtually all
rivers, lakes and streams from being distinct bodies of water, would
entirely exclude features such as bays, isthmi, peninsulae, and so on from
ever being mapped regardless of size or obvious closure, and in general
would dismiss topology as being entirely unimportant. The arguments went as
far as to have one user advance the claim that a number of counties and
townships north of me should not be mapped, despite having well-defined
borders in the inhabited regions, because portions of their boundaries have
never been successfully surveyed.

But somehow, those voices never gained entirely the upper hand.  If so,
features like `bay`, `peninsula`, `strait`, `isthmus`, `ridge`, `valley`
and so on would all bear prominent warnings on the Wiki that it is
inappropriate to map them. Somehow, the people who loudly proclaim that
objectivity and observability require that every feature be bright-line
observable in the field cannot bring themselves to do that, or know that
the community would reject it.

For myself, I've deferred to you on the matter - including refraining from
mapping even small features like Jamaica Bay (
https://www.openstreetmap.org/#map=12/40.6125/-73.8082) - despite the fact
that the specific feature is reasonably sized, local, quite different from
the Atlantic Ocean (calm water, much lower salinity, much greater tidal
range, and a very different ecosystem) and that I would very much like at
some point to produce a detailed paper map of my boyhood home town (
https://www.openstreetmap.org/relation/174930) including, of course,
labeling the waterways that lie only partially within its neatline. I'm
willing to accept for now that OSM cannot cope with that requirement and
I'll have to develop another system alongside OSM and manage multiple map
layers to produce such a thing.

That sort of desire - wishing to include some information about long routes
or about area features that are large, diffuse, imprecisely defined, or
otherwise difficult - appears to be fairly commonplace, given the number of
words that have been expended on the subject here and elsewhere. Those of
us to whom the topology of area features is important - for instance,
because we produce paper maps and wish to produce normal rendering,
including labeling, of area features that extend outside the neatline -
rapidly grew frustrated, and eventually the discussion died from
exhaustion, as discussions on this list usually do. Meanwhile, there's no
indication to mappers (for example, warnings in the popular editors) that
creating enormous area features is inappropriate because of inability of
the tools to deal with them.

Moreover, those who actually have the technical expertise to experiment
with solutions to the problem feel stymied at every turn by the gatekeepers
- who may also have the technical expertise, but have a different opinion
of the problem's importance. I've talked off-list with several skilled
programmers and data analysts who definitely believe that even if a
solution were to be developed, it would be rejected. There is certainly
zero interest from the gatekeepers in maintaining a discussion of the
requirements for such a thing - it turns into 'I haven't seen a good enough
solution yet, and I'll know it when I see it,' without an answer to, 'in
what way is a given proposal unsatisfactory and how might it improve?'
There's a natural temptation to transform, 'this problem is too hard for me
to solve in the time I have available' into 'this problem is too hard in
relation to its importance', to 'this problem is unimportant to me, and you
shouldn't work on it either.'

The gatekeepers do good enough work in general that I'm even willing to
accept, 'this problem is too hard in relation to its importance and we will
not consider solutions that are offered and prefer not to address it,' but
then the project really ought to define these objects as being out of
scope.  In that case, though, I think that the tool developers really have
to be open to the concept of layers. When mappers are going to the effort
of doing these things, it's because they want to have them. A directive of,
"you should not want to map this feature," will be controversial to say the
least.

People map complex features such as the huge one in Alaska that kicked off
the current round of this discussion, or smaller but still troublesome ones
like https://www.openstreetmap.org/relation/6360587#map=10/43.3696/-74.0561,
because they're actually there in the field. All of the small parcels that
make up the latter are signed, at the very least where they front along a
road, trail or waterway. The large whole is united by a name, an officer
who manages it, a management plan, a web site, and so on - and the locals
think of it as a single object despite its diffuse structure. Objects with
that complex a topology present management problems. Agreed. But I don't
know _how_ many arguments I've been in where someone who really has the
management problems on his mind instead argues that the object in some way
doesn't exist or isn't deserving of mapping.  It's really important to keep
the two arguments separate, or it starts to come across as, 'the data model
is fine. Fix your country, or fix your world view (or the world view of
your users).'

At the very least, document that the creation of large multipolygons for
indefinite features is considered inappropriate, and why, and enlist the
aid of the maintainers of the editors to warn about the issue.  Otherwise,
you'll continue to see that people do it because they want to see the
features on the map and are ignorant of the possible effects.


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


More information about the Tagging mailing list