[Tagging] Using multipolygons to map bays in Alaska

Kevin Kenny kevin.b.kenny at gmail.com
Sat Nov 17 17:50:42 UTC 2018

On Sat, Nov 17, 2018 at 6:29 AM Frederik Ramm <frederik at remote.org> wrote:
[longish observation blaming OSM Carto for the fact that people
were coming to map bays as areas...]

> So, long story short, a couple of "my" maps suddenly started to show
> ugly dark-blue patches e.g. across the bay of Biscay, or the Gulf of
> Bothnia. That's how I noticed and investigated what was happening, and I
> found that Daniel had added the Gulf of Bothnia polygon to accompany the
> newly-introduced OSM-Carto feature of rendering bay names depending on
> the size of the area.

In my case, OSM Carto had very little to do with it.

As I discussed in earlier messages, my motivation is that I render a fair
number of maps, moslty for my own use and my friends, on actual dead-trees
paper (or more often Tyvek, which I suppose you could call 'dead-dinosaurs
paper'). I do want my maps to show the names of significant geographic
features that appear on them, even if the region of interest of the paper
map includes only a small portion of a large feature. I could not figure
out a way to do that without defining area features as areas. Doing so runs
afoul of Christoph's pronouncement that no area features should be mapped
as areas unless every metre of a border was field-verifiable.

I found that pronouncement quite disturbing, since I live in a region where
there are significant administrative regions whose borders are indefinite.
(I recognize that there's a cultural difference here: the chaotic American
approach to such matters is, "we'll survey it if it ever becomes important
enough that someone will pay for the survey." Where is the precise boundary
in the swamps of the St. Regis River basin? Nobody much cares. The county
line is surveyed and monumented where people do care.) If that
pronouncement were carried out to the letter, a couple of counties in my
part of the world would have to be reduced to nodes.

In the case of an ugly dark-blue patch over the Gulf of Bothnia or the Bay
of Biscay, I'd definitely have directed my annoyance at the renderer. When
I've done my own rendering, I've never distinguished inland from ocean
waters by colour - precisely because it unduly emphasizes the arbitrary
lines between them, which occur at every river mouth, estuary, and yes, bay.

Whether OSM-Carto encourages, discourages or is neutral toward the style in
question is something that is of no concern to me.

 he went through the time-consuming
> exercise of combining more than 1600 coastline pieces into one huge
> polygon which is difficult to handle for data processors and editors

I have found that when anyone is advancing an argument with the word 'just'
in it, that the word is demanding a suspension of disbelief, and the
position would be more accurately stated without it. Deferring the
discussion of data processing to a later paragraph, let me translate. _He
went through that difficult and time-consuming exercise to place a label._
Can you see how that sounds different? It is not an arrogant assertion that
your assessment of the importance of the task is more valid than his. It
leaves open the possibility that the presence of the label was important
enough to him that it was worth going through that work to allow for it.

Objects in the real world have names. One of the functions of a map is to
inform its users of the names of the objects that it displays. Surely maps
have many other functions, but connecting the displayed objects to human
language and the human sense of orientation is one of them. It is hard to
find a map, anywhere, that does not have labels for named objects because
that is a critically important part of what a map does.

In my particular use case, a node label would be useless to me. I do render
large-scale maps that often contain a small piece of a much larger objects.
Having a node with the object's name somewhere far beyond the boundaries of
the region of interest is worthless to me. That is why I favour carrying
area features as areas rather than nodes, always. (It also gives a more
sophisticated renderer than Mapnik many more options for resolving
conflicting labels.)

Maps from before the OSM era did this pretty much universally.  Returning
to my Jamaica Bay example, https://caltopo.com/l/EQA0 shows the meeting
point of four sheets in the old USGS 7.5-minute topographic series. You'll
see that all four of the sheets have labeled 'JAMAICA BAY', even though the
quadrangle to the northwest has only a little triangle of it in one corner
and the one to the southwest has only a narrow strip along its eastern
margin. That's because it is a locally important feature - and assigning it
a name truly is important. It is the feature that dominates the landscape
of those who live by it. If I were to be producing almost any map of that
area by hand methods, the ocean, the bay and the airport are surely the
first three features I'd sketch in, and the labels I would least want to

It is only a matter of time until they start labelling natural=sea
> polygons and people then create relations with 100,000 members for the
> Atlantic.

Here, I think, lies the crux of the issue - the sheer size of features like
the Gulf of Bothinia overwhelms the toolchain.

I surely recognize that the technological limitations are significant, and
that we may need to surrender some of our wants because of what the
technology allows for. If querying for the Gulf of Bothnia overwhelms the
server, and at the current level of development that cannot be fixed, or if
many people who are processing the data are using tools that cannot cope
with it, then restrictions are reasonable. I'm even charitable enough to
surmise that your motivation for the revert (which you yourself admit was
badly handled) was that you saw the situation as an emergency - surely data
that are severely damaging the ability of OSM to function have to be
corrected sooner than later!

But in that case, let's simply treat it as a practical, technological
limitation - which opens up the possibility that as our tools and
techniques improve, the limitation can be lifted. I'd entirely accept a
guideline along the lines of, "multipolygons that encompass more than W kmĀ²
of land area, have borders longer than X km, comprise more than Y ways or
require more than Z nodes for their representation should be created only
in extraordinary circumstances, with advance discussion on the mailing
lists". Such a guideline would engender very little conflict, particularly
if the specific difficulties are identified, so that the clever
technologists in our midst could begin to think about how to address them.

"I'm sorry, you can't have that right now because today's technology has
trouble with it," acknowledges the user's wants. "You shouldn't even want
that!" - which is what I have heard repeatedly in this thread - is
guaranteed to elicit only the reaction of, "Who are you to tell me what I

> If you *are* interested in labels, then this is wrong because (a) it
> means that you have to go through this huge exercise just to place a
> label, and (b) the label will vanish as soon as someone breaks the
> polygon by e.g. creating a small self-intersection along one of the 1600
> coastline bits. It will probably be gone more often that it is there.

Broken coastline is broken coastline irrespective of whether it is part of
another waterbody or not. Moreover, a multipolygon that encompasses a small
stretch of coastline will not see any adverse impact from a broken
coastline a thousand miles away - those ways don't participate in the
multipolygon in question.

I surely agree that breaking the coastline is a recurring problem - and you
have most likely cleaned it up more than anyone here.

Part of the problem stems from our expansive definition of 'coastline' -
which is done in an effort to make the blue background that is the default
for the map cover as much of the world as possible.

I know that in my first couple of years as a mapper, I identified a number
of problems with various bits and pieces of shoreline in Long Island's
inland waters - including Jamaica Bay. I also left them unfixed - because
the best advice that I got was that changing the coastline was for wizards
only, that doing so was impossible to validate, and that the slightest
mistake would break it worldwide and bring the wrath of the whole community
down on my head. In the specific case of Jamaica Bay, I'd be much happier
if none of it was 'coastline'. It's part of the ocean only to avoid having
an arbitrary, indefinite line across its mouth, or to avoid having
renderers like Frederik's distractingly assign it a different colour. It is
surely different from the ocean. It is brackish, having less than half the
salinity of the ocean. It is slack water except in the worst of storms,
while the ocean side of the peninsula often has pounding surf even in fair
weather. The locals think of it as an inland water. Nevertheless, current
guidelines insist that it must be 'coastline'.

I suspect that most of the recurrent annoyance of 'broken coastline' stems
from just such areas of complex topology in the estuarine environment, and
that the real solution is to work on how to model such areas so that local
changes can be made without global effects. But that's probably a
discussion for another day. Ultimately, the answer may be to generalize the
World Ocean and move it a small distance offshore, allowing the near-shore
environment to be made up of local objects.

But that's all speculation - I don't have enough experience with mapping at
small scales to comment. Most of the paper maps that I've done are at
scales like 1:31680 or 1:25000 (depending on whether the main map scale is
in SI or Imperial measure) I'm sure that a global map, or even a 'one in a
million' map, has a different set of issues that I fail to comprehend.

Summing up, my opinion is

> (1) the OSM-Carto project and Daniel have overstepped their mandate as
> the maintainers of our style, and should have sought a wider consensus
> on this before acting;
I care very little about what OSM-Carto may or may not have decided to do,
but still want to have area features represented as areas for my own
renderings, which have nothing to do with OSM Carto. I consider this
argument a colossal distraction.

(2) the decision they have made is not a good solution for the
> cartographic problem they wanted to solve;
I have presented my own problem, which is related to the same features, but
a different problem. It appears to demand the same solution. Christoph's
answer to my question about an alternative technical approach was, in
effect, a request that I hire him to develop one, rather than to recommend
a course of action for my own development.

(3) the decision they have made will lead to people creating huge
> polygons that will often break, make coastline editing harder, and have
> at least one totally made-up edge.

Indefinite boundaries are a fact of life. Every river has an indefinite
mouth. Several townships and counties in my part of the world have
indefinite portions of their borders. Refusing to map the definite borders
because of the existence of the indefinite borders is not a viable solution.

As far as 'huge polygons that will often break' go, perhaps there is a
technological solution here. 'osm2pgsql' already has two modes for its
treatment of the coastline: import it, or presume that it will be rendered
from another source and leave it out of the database. Perhaps 'huge
multipolygon' could be modeled with another type of relation, or with some
tag on the multipolygon relation indicating "this is a multipolygon that
exceeds the size guidelines?" 'osm2pgsql' could then, by default, exclude
these features when bringing the relations into the rendering database.
That would allow people like Daniel or me, who would like to experiment
with labelling and modelling this sort of feature, to work with OSM data
independently of OSM-Carto and not fear disrupting everyone else's
rendering. If we ever want to have bays, straits, seas, and so on treated
in any other form than labels painted in their middle, then we need some
space to work in! Local .osm or shapefiles can get you only so far -
eventually, you need to try working with the real data.

North American mappers have already been pursuing this approach in creating
relations with 'route=road network=* ref=*' to model our numbered highways,
which typically belong to three or four overlaid networks and have many
route concurrences. We recognize that the main OSM renderer will never
support these - the idea has been conclusively rejected - but have hopes of
developing a continent-scale rendering for our own use that will render
these in a usable fashion. In the meantime, our relations appear not to
interfere with OSM Carto, and our experimentation proceeds.

I certainly hope that the project will continue to have some pathway that
is open to new things, and will continue to dispute the argument that
"nothing can ever be done for the first time."

(4) Frederik has been an utter dick to try and start the discussion by
> deleting the Bothany Bay polygon, instead of simply raising it here. It
> was wrong, I'm sorry.

As I said, I am willing charitably to assume that you saw the situation as
an emergency because of tool breakage.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20181117/1e64c20e/attachment-0001.html>

More information about the Tagging mailing list