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