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 <o...@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@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging >
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
