[GEOT-5502] First implementation of Pole of inaccessibility. #1287
Conversation
| * | ||
| */ | ||
| public class PolyLabeller { | ||
| private static final Logger LOGGER = Logging.getLogger(PolyLabeller.class.getName()); |
|
Casper will sign CLA on Monday when he has checked his contract |
|
Thinking out loud and without having checked the pull request.... is this worth turning into a text symbolizer vendor option too? If it's fast enough it could become the default poly center implementation, with the vendor option still allowing it to turn it off and get the old behavior, but most of the people would get the benefit without needing to alter all their SLDs. |
|
Once we've tried this out on a some realistic polygons we could consider moving it into the main styling package and making it the default. |
|
OK nitpicks addressed. Looks good. |
|
A bit late to the party here.... is this algorithm in use at all? There's a few places where it can be sped up dramatically:
I have implemented a version like this and the performance goes from 153 s to 680 ms on a world polygon dataset. Will be posting it soon. |
|
We tried it out hoping it would lead to better label points, the results have not been very satisfactory to our cartographers (and we verified implementation making QGIS compute the same using its pole of inaccesibility implementation, which returned the same points). Looks like MapBox is using something else now, as their maps have the labels in better positions than the pole. Still, good to have it improved, in some cases it's better than the built-in one we have. |
|
And oh, one thing, don't expect valid polygons to go into the algorithm, the code has been already modified (just recently) to allow it working on non valid ones, and the check for polygon validity is gone. I'd suggest checking the latest version on master. |
|
Thanks for pointing out the updated version. That should be a lot better (not requiring validity, and should be faster). Interesting that this isn't considered ideal labelling. I did notice that sometimes the point is far from the centre of the polygon, when there's still enough room there for a label. Perhaps a combination of trying the centre and the furthest point would be better. |
|
Testing indicates the latest version of PolyLabeller is indeed a lot faster. A version using indexed Point-in-Polygon and Distance is still faster, but only about 3x on a "typical" dataset. So probably not worth the (much) greater complexity (in terms of dependencies). |
|
@aaime etc: Following up on this... It looks like Mapnik is now using a modified PolyLabeller algorithm, which provides some weighting from the polygon centroid to stop the compute point being too far away. See this: |
|
Nice the centroid fix approach. It's something we also were thinking about to improve the PolyLabel efficacy for labeling. Indeed, from our experience, the pole of inaccessibility often doesn't give great visual results (and most of map services don't employ it straight). |
|
I found a bug in the master version of this code. The code uses getCoordinates() on polygon geometries. This is incorrect if the polygon contains holes, since it merges all coordinates from all rings into a single let. (It's also slow for polygons with many holes). The fix is to add a 3rd level to the loop to handle polygon shell and hole rings separately. Even better, use IndexdFacetDistance to make it much faster. |
|
Thanks for the report @dr-jts |
|
Sure, if no-one else picks up on this I will open a new issue. For the record, I have an implementation using indexing here. (I also have ideas about how to constrain the point to a rectangle as well, which might be more effective for labelling, as well as being faster again). |
Vladimir Agafonkin came up with an algorithm for calculating poles of inaccessibility to give good labelling points for odd shaped polygons.
See https://www.mapbox.com/blog/polygon-center/ for a discussion of algorithm
This implements this functionality and makes it available as a function so it could be added to GeoServer SLD files.