[Tagging] Using multipolygons to map bays in Alaska

Kevin Kenny kevin.b.kenny at gmail.com
Sat Nov 17 03:22:57 UTC 2018


On Fri, Nov 16, 2018 at 8:01 PM Christoph Hormann <osm at imagico.de> wrote:

> We all know you think bays and straits should best be mapped with
> polygons and that it is a positive thing to steer mappers to doing that
> (which by the way is against the goals of OSM-Carto even if your
> opinion on this has merit).  You can try to justify that all you want -
> this does not change anything about the argument i gave against it -
> that the polygon drawing almost never adds any verifiable information
> on the geographic reality compared to a node or a linear way
> representation.
>
> I know i will not change your opinion on this - countless non-successful
> discussions with you on much clearer and simpler matters have shown me
> that.  I can just hope most mappers will emancipate themselves from
> this and not invest their time and energy in mapping and maintining
> polygon mazes over coastal waters.
>

I think that I need to reduce the cases to something more concrete in order
to follow your argument that nodes are perfectly adequate to convey the
extent of bays, straits, estuaries and similar features well enough to map
them  - particularly on maps that have a constrained region of interest.

I'm fairly good at both mapping and rendering, and quite good indeed with
the mathematics and programming - but somehow I'm still not following how
to implement your suggestions. I am willing to be convinced, but so far you
have failed to convince me.

Let's consider a map that I actually would like someday to produce: a
large-scale map of the waterfront community of Inwood, New York.
https://www.openstreetmap.org/relation/174930 I'll want to have it on a
sheet of A4 or US Letter paper. The extents of the map will therefore
likely be west into the water, perhaps about as far as the jetty at the
airport; east nearly to the railroad station in Cedarhurst, south to
about the station in Far Rockaway, and north perhaps to the bridge in
Meadowmere Park.

By far the most significant label that must be placed on the map, given the
waterfront nature of the community, is Jamaica Bay. Only a small portion of
the main bay would appear within that box, but much of the west edge of
such a map would be the water of the bay. Jamaica Bay can be seen in its
entirety by zooming back to level 12 or 13 and panning the map to the west
- it is the large oval area from Inwood out to the Atlantic Ocean.

If the bay were an area feature, I would be able to place a label on the
area feature that is created by intersecting its extent with the region of
interest. But, because of indefinite boundaries, the use of an area feature
is denied to me.

Assume that I am willing to be flexible about the deduced extent of the bay
where it is indefinite. I do not care, for instance, whether its mouth is
placed at the narrowest part of the entrance, near the Marine Parkway
Bridge, or at the traditional start at the imaginary line that connects the
tip of the jetty that protrudes from Breezy Point to the tip of the pier at
Coney Island to its north.  I similarly don't necessarily demand absolute
precision about the boundary between Jamaica Bay and the back bays such as
the Head of Bay, Norton Basin, Motts Basin, Motts Creek, Hook Creek or
Thurston Basin - any reasonable answer is fine.

So - problem #1:  What point, line or area features do I need to place in
the OSM data base to determine that the water in question is part of
Jamaica Bay so that I can label it on that map? Given those features, what
is the computational pathway that can inform a renderer that such a label
needs to be placed?

I am not assuming that OSM-Carto, Mapnik, or indeed any other existing
rendering chain contains a complete implementation of all the logic needed.
Instead, I am seeking help to develop a detailed specification. If this,
and the questions that I plan to follow up with, are answerable in the data
model that you envision, then this sort of thing will have to be
programmed. I'm willing to try my hand at such an implementation and do any
reasonable amount of analysis and programming. I still lack a clear vision
of how to proceed - although having a clear description from you of the
objects that are required in the database may help be a start at that.

Share the insight that you claim to have that I lack. Convert me to your
way of thinking.  If you are in possession of such deep understanding, it
will surely not be difficult to demonstrate by a single example how you
solve the problem.

I anticipate answers that deflect the question. Because of that, I state:

If I cannot be given an answer to such a concrete problem, I will not
accept that the reason is that I am too stupid or unskilled to understand
your superior wisdom. Nor will I accept a bald assertion that I am asking
the wrong question. Producing a conventional map on a sheet of paper is a
reasonable thing to want to do even in our digital age: as I stated before,
a sheet of paper and a magnetic compass never have dead batteries, and
wanting to see the major features labeled is a reasonable goal. Nor am I
prepared to accept bluster about "low quality rendering" or any similar
comment. You are free to assume that I am willing to accept a low quality
rendering of the labels, or to put in the necessary work to develop a
higher-quality one. Such bluster is therefore irrelevant to the question at
hand. And I am most emphatically not prepared to accept a potential reply
that OSM is the wrong tool for the job. The bay is there. I plied its
waters in my youth. The locals all know its name, and it dominates their
landscape. A great many of my ancestors earned their living from its
waters. If we arrive at a conclusion that it has no place in OSM, then OSM
cannot carry even a reasonable description of that community.  If it is a
project that aspires to describe the whole world, it will surely have
failed in that place.

Your move.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20181116/23fc397d/attachment.html>


More information about the Tagging mailing list