[Tagging] Using multipolygons to map bays in Alaska

[Joseph Eisenberg]

Re: really huge relations.

The Great Lakes are mapped (and rendered) with multipolygon relations.

Also, the even bigger island of New Guinea has all of its coastline
included in a multipolygon. I don’t know about Greenland or Madagascar, but
I believe it would be considered correct to map them in this way.

The key difference for OSM is that an island is verifiable as a landmass
surrounded by water, while a bay is indefinite on one side.
On Sun, Nov 18, 2018 at 8:36 PM Joseph Eisenberg <joseph.eisenberg at gmail.com>
wrote:

> Christoph, I was really looking forward to hearing how we can render good
> labels for bays and seas, based on a node and the coastline.
>
> Is there any possible solution the would work with Mapnik and CartoCSS?
>
> Perhaps computing the shortest distance between the bay node and coastline
> would somehow work for a rough label size on low zoom levels?
>
> Or could this data be included in the generalized water polygons at
> openstreetmapdata, or the shapefiles used by openstreetmap-carto, somehow?
>
> On Sun, Nov 18, 2018 at 8:06 PM Christoph Hormann <osm at imagico.de> wrote:
>
>> On Sunday 18 November 2018, Eugene Alvin Villar wrote:
>> > [...]
>> >
>> > As a sort of compromise at least for bays (gulfs, inlets, fjords,
>> > coves), how about we just map them as a single way across the mouth
>> > of the bay and not as a way-polygon nor type=multipolygon relation?
>> > And then we set the direction of the way such that the right-hand
>> > side of the way points to the bay-side (just like the right-hand side
>> > of natural=coastline ways point to the seaward side).
>>
>> While this obviously has the same verifiability issues as the polygon
>> drawing in general (you already say that) this is actually a great
>> demonstration for the core of the problem.
>>
>> It can be explained with the following formula:
>>
>>
>> polygon mapping of bays/straits using the coastline as components
>>
>> *equals*
>>
>> coastline data already mapped anyway
>>
>> *plus*
>>
>> completely subjective data about a non-verifiable limit of the
>> bay/strait
>>
>>
>> Mapping only the last part should satisfy all those who disagree that
>> there is no additional verifiable information in the polygon mapping of
>> bays (because whatever is in there would be contained in this form of
>> mapping - see the above formula).
>>
>> It will however likely not satisfy most because:
>>
>> * The "map designers who want to outsource label drawing to the mappers"
>> and "mappers who want to draw labels" will have difficulties acutally
>> performing above addition (because as mentioned: coastline data is not
>> in the database and the operation to select and assemble the data as
>> needed is not cheap).
>> * The "everything is to be mapped with a polygon" proponents will not
>> like this because it is not a readily assembled polygon, just a
>> component of it, therefore insufficient for a purist.
>> * The verifiability proponents (like me) will dislike adding
>> non-verifiable data to the database but this is much less harmful than
>> the polygon drawing so i clearly see it as the lesser of two evils.  It
>> nicely separates the verifiable data from the non-verifiable data so it
>> definitely is the most acceptable form of non-verifiable mapping in OSM
>> (if there is such a thing).
>>
>> As a data user - while this is more difficult to process than a node
>> based mapping it would be manageable.
>>
>> Long story short:  What i like about this proposal is that its rejection
>> will bring clarification on the motives for the different opinions
>> pursued here.  What arguments you have against this suggestion will
>> decide which of the above groups you belong to. ;-)
>>
>> --
>> Christoph Hormann
>> http://www.imagico.de/
>>
>> _______________________________________________
>> 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/20181118/caec7089/attachment.html>