Skip to content

Consider also distance from centroid when calculating label position #33

Open

Description

@lazarm

In cases where there are several equally good solutions, algorithm's output is not always the most elegant one. The simplest case is a rectangle: the set of solutions lies on a line and algorithm returns a point that coincides with one of the line's endpoints. Current implementation covers such case when calculating initial best cell, however these lines can occur also in more complex polygons containing parallel edges.

I propose using a cost function when estimating cell quality, which would consider both distance from polygon and distance from centroid in such a way it would prefer points closer to centroid, e.g.:
0.5 * (distFromPoly + distFromPoly / (distFromCtr/distFromPoly+1); distFromPoly >= 0
distFromPoly; distFromPoly < 0

So for example, if pia point is very far away from centroid and its distance from polygon is not much greater than centroid's distance, we would get centroid as optimal point. Weights on both values can be manipulated by cost function. What are optimal set of weights is of course subjective.

Cost function would be then used when comparing two cells in while loop and max attribute of a cell can be then calculated in a following way (java code):
// for distance from polygon take max possible distance
// for distance from mass centre take minimal possible distance
double maxDist = dist + h*SQRT2;
if (maxDist < 0) {
return maxDist;
}
double distFromCtr = Math.max(distance(this, massCentreCell) - h*SQRT2, 0);
return costFunction.compute(distFromCtr, maxDist);

I've implemented this in Java and I'm very satisfied with the results.

Activity

  1. talaj commented on Nov 30, 2017

    @talaj

    mapycz@a51fe7a is a modification of Polylabel preferring solutions closer to centroid I made for mapnik/mapnik#3811.

  2. SBRK commented on Oct 18, 2018

    @SBRK

    @talaj any chance you could port your solution to the js version ? :)

  3. curran commented on Jun 17, 2020

    @curran
    Contributor

    This would be an amazing improvement.

    I see some cases for this with a US map:

    image

    image

    Center of bounding rect might be a better thing to gravitate towards than the centroid. I think that would be more performant, and at least it would addres these cases here. Not sure - maybe the centroid is already being computed.

  4. curran commented on Jun 17, 2020

    @curran
    Contributor

    I sketched out a solution here #63

  5. curran commented on Jun 18, 2020

    @curran
    Contributor

    @kevflood What does "F. R" mean?

  6. kevflood commented on Jun 18, 2020

    @kevflood

    @curran sorry, no idea what happened there. I didn't mean to comment. It's possible my kid mashed the keyboard when I was away from desk.

  7. curran commented on Jun 18, 2020

    @curran
    Contributor

    lol thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions