2020-12-15 08:48 Anders Torger a écrit:
However I'll soon go through these edits again and then I will add multipolygon
for the split, and if your renderer takes that into account we should end up
with a single multipolygon. I think in the case of Muddus it will work in all
cases, ie we won't hit the corner case described above which should be very
rare. So I think this naming concept is okay as a stepping stone until we can
move forward on this issue. I hope we can make a point though that this is not
a acceptable as a long-term solution.
I'm drifting away from tagging into renderer implementation territory
now, but this thread is large anyway, so what the heck... :-)
Your last edits actually caused some headaches for my renderer, because
you added in some "satellite" bits of bog that were not (I think)
previously included. The renderer insists on putting a label on each
disjoint area, so I ended up with a handful of them.
So I resorted to the old "buffer and join" hack, adding a 100-meter
buffer around each area and ST_Union:ing the result (isn't it fun when
you realize you have all the plumbing in place and can do new things by
just adding a few lines of code?). Now the map looks like this:
http://lab3.turepalsson.se/~ture/rijmmoahpe-20201216.pdf . The red
outlines show the areas that the renderer is actually considering when
placing the labels.
The label placement for Aleldusáhpe near the top of the map looks...
less than ideal. I suspect that this is because I use (an implementation
of) the Mapbox polylabel [1] algorithm, and it gets derailed by the
small holes inside the areas. Maybe it would be better to use a convex
hull... or just a bigger buffer. Label placement is a black art...
Links:
------
[1] https://github.com/mapbox/polylabel
_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
