[Geoserver-users] proposal: improve polygon label placement

GeoServer GeoServer User
1

Correct me if I'm wrong, but I think geoserver always places polygon labels at the polygon centroids? This leads to the following, imho unwanted, behaviour: if a polygon's centroid falls outside the current rendered bbox, but still a large part of the polygon is visible, the label is not rendered. Consider rendering country polygons with their names inside. You'd want the label to appear when their is enough space in the rendered part of the polygon, not only if the polygon's centroid is in the rendered part.

For an live example, see http://www.sarvision.nl/vision2/ies/greatlakes/demo5/index.html. This will load a custom mapbuilder app with a part of Africa. You'll see country name labels for Uganda, Rwanda and Burundi, but not for the Congo (country at the left half of the bbox).

I think a viable solution could be to use the centroid of the intersection of the polygon and the wms bbox envelope as the label position. This would ensure that the label gets rendered when (part of) the polygon is inside the rendering area.

I thought I'd suggest this on the list first, before opening a jira issue. I might have overlooked some sld label options that solve this, though I did some searches first...

Please let me know your thoughts on this.

Cheers
Vincent.

2

Vincent Schut ha scritto:

Correct me if I'm wrong, but I think geoserver always places polygon labels at the polygon centroids? This leads to the following, imho unwanted, behaviour: if a polygon's centroid falls outside the current rendered bbox, but still a large part of the polygon is visible, the label is not rendered. Consider rendering country polygons with their names inside. You'd want the label to appear when their is enough space in the rendered part of the polygon, not only if the polygon's centroid is in the rendered part.

For an live example, see http://www.sarvision.nl/vision2/ies/greatlakes/demo5/index.html. This will load a custom mapbuilder app with a part of Africa. You'll see country name labels for Uganda, Rwanda and Burundi, but not for the Congo (country at the left half of the bbox).

I think a viable solution could be to use the centroid of the intersection of the polygon and the wms bbox envelope as the label position. This would ensure that the label gets rendered when (part of) the polygon is inside the rendering area.

Unfortunately thats what the renderer is doing now :frowning:
It takes the polygon and cuts it by the rendering bbox, computes the
centroid of what is left, and places the label there. Which means it
may fall outside depending on what is the shape of the remaining polygon
part, indeed. An algorithm that tries to fit the label rectangle in the
polygon geometry would be nicer for sure.

The Congo label is not displayed in your sample because after placing it
in the specified area, it goes outside of the rendering box (the label,
I mean). Every time a label crosses the rendering bounds it's removed
from the rendering area.
When zooming in in the red square you added, the Congo label is
displayed because the new centroid is closer to the map center and
as result the big label does not cross the rendering bounds anymore...

I thought I'd suggest this on the list first, before opening a jira issue. I might have overlooked some sld label options that solve this, though I did some searches first...

No overlook unfortunately. Just the label is too long.
We would need some kind of dynamic anchorpoint, were the software decides the best anchor point trying to fit the label in the rendering
bounding box. That would open a can of worms thought, because this would
interact with label collision as well (when two labels collide, can I move one, and how?).

Cheers
Andrea

3

Andrea Aime wrote:

Vincent Schut ha scritto:

Correct me if I'm wrong, but I think geoserver always places polygon labels at the polygon centroids? This leads to the following, imho unwanted, behaviour: if a polygon's centroid falls outside the current rendered bbox, but still a large part of the polygon is visible, the label is not rendered. Consider rendering country polygons with their names inside. You'd want the label to appear when their is enough space in the rendered part of the polygon, not only if the polygon's centroid is in the rendered part.

For an live example, see http://www.sarvision.nl/vision2/ies/greatlakes/demo5/index.html. This will load a custom mapbuilder app with a part of Africa. You'll see country name labels for Uganda, Rwanda and Burundi, but not for the Congo (country at the left half of the bbox).

I think a viable solution could be to use the centroid of the intersection of the polygon and the wms bbox envelope as the label position. This would ensure that the label gets rendered when (part of) the polygon is inside the rendering area.

Unfortunately thats what the renderer is doing now :frowning:
It takes the polygon and cuts it by the rendering bbox, computes the
centroid of what is left, and places the label there. Which means it
may fall outside depending on what is the shape of the remaining polygon
part, indeed. An algorithm that tries to fit the label rectangle in the
polygon geometry would be nicer for sure.

Hey, you've beaten me by about 10 seconds :slight_smile:
I just found that out too, not by looking at the code but because I'm gradually adding 'zoom to layer' functionality to my layers in the mb client. I was adding the zoom functionality to the study area layer (the red square), and tried it, and whoops there the Congo label magically appears. Then after some thinking I concluded what you just told me. Just wanted to send that to the list when I saw your response.

The Congo label is not displayed in your sample because after placing it
in the specified area, it goes outside of the rendering box (the label,
I mean). Every time a label crosses the rendering bounds it's removed
from the rendering area.
When zooming in in the red square you added, the Congo label is
displayed because the new centroid is closer to the map center and
as result the big label does not cross the rendering bounds anymore...

I thought I'd suggest this on the list first, before opening a jira issue. I might have overlooked some sld label options that solve this, though I did some searches first...

No overlook unfortunately. Just the label is too long.
We would need some kind of dynamic anchorpoint, were the software decides the best anchor point trying to fit the label in the rendering
bounding box. That would open a can of worms thought, because this would
interact with label collision as well (when two labels collide, can I move one, and how?).

OK, so 1 workaround possible and 2 fixes? In order of difficulty:
1. use a shorter label;
2. have an sld option that geoserver forces to draw labels, even if they fall partly outside of the bbox (probably the 'partly' is important, performance-wise). I don't know if the label renderer is able to render labels that fall partly outside of the image?;
3. improve the polygon label placement algorithm.

I'll obviously go for option 1 now, but you might like me to file a jira issue about this, for the record and possible future improvement?

Cheers,
Vincent.

Cheers
Andrea

4

Vincent Schut ha scritto:

Andrea Aime wrote:

No overlook unfortunately. Just the label is too long.
We would need some kind of dynamic anchorpoint, were the software decides the best anchor point trying to fit the label in the rendering
bounding box. That would open a can of worms thought, because this would
interact with label collision as well (when two labels collide, can I move one, and how?).

OK, so 1 workaround possible and 2 fixes? In order of difficulty:
1. use a shorter label;
2. have an sld option that geoserver forces to draw labels, even if they fall partly outside of the bbox (probably the 'partly' is important, performance-wise). I don't know if the label renderer is able to render labels that fall partly outside of the image?;

Labels that fall partly outside are not rendered not because of performance issue, but because the label would be cut in any tiling
client such as OpenLayers or MapBuilder with the tiling engine activated. This is because labels do change position from one tile
and the other, and also because you would have issues with the
collision algorithm.
We could add an option for non tiling clients, of course, but it
seems to me in 2007 a good client should use tiling :slight_smile:
Feel free to open a request anyways.

3. improve the polygon label placement algorithm.

I'll obviously go for option 1 now, but you might like me to file a jira issue about this, for the record and possible future improvement?

Yeah, please file an issue about better label in polygon placement
(rectangle in polygon problem), this would be good for both Geoserver
and udig.

Cheers
Andrea

5

Andrea Aime wrote:

Vincent Schut ha scritto:

Andrea Aime wrote:

No overlook unfortunately. Just the label is too long.
We would need some kind of dynamic anchorpoint, were the software decides the best anchor point trying to fit the label in the rendering
bounding box. That would open a can of worms thought, because this would
interact with label collision as well (when two labels collide, can I move one, and how?).

OK, so 1 workaround possible and 2 fixes? In order of difficulty:
1. use a shorter label;
2. have an sld option that geoserver forces to draw labels, even if they fall partly outside of the bbox (probably the 'partly' is important, performance-wise). I don't know if the label renderer is able to render labels that fall partly outside of the image?;

Labels that fall partly outside are not rendered not because of performance issue, but because the label would be cut in any tiling
client such as OpenLayers or MapBuilder with the tiling engine activated. This is because labels do change position from one tile
and the other, and also because you would have issues with the
collision algorithm.
We could add an option for non tiling clients, of course, but it
seems to me in 2007 a good client should use tiling :slight_smile:
Feel free to open a request anyways.

Ah, of course. Should have know this, while following the mapbuilder/openlayers merge discussions... I'm awaiting mb and openlayers integration being more polished before switching though...

3. improve the polygon label placement algorithm.

I'll obviously go for option 1 now, but you might like me to file a jira issue about this, for the record and possible future improvement?

Yeah, please file an issue about better label in polygon placement
(rectangle in polygon problem), this would be good for both Geoserver
and udig.

Should I file this for geoserver or geotools? I guess the latter?

Cheers
Andrea

6

Vincent Schut ha scritto:

Andrea Aime wrote:

I'll obviously go for option 1 now, but you might like me to file a jira issue about this, for the record and possible future improvement?

Yeah, please file an issue about better label in polygon placement
(rectangle in polygon problem), this would be good for both Geoserver
and udig.

Should I file this for geoserver or geotools? I guess the latter?

The latter indeed, renderer module :slight_smile:
Cheers
Andrea

7

Andrea Aime wrote:

Vincent Schut ha scritto:
  

Andrea Aime wrote:
    

I'll obviously go for option 1 now, but you might like me to file a jira issue about this, for the record and possible future improvement?
        

Yeah, please file an issue about better label in polygon placement
(rectangle in polygon problem), this would be good for both Geoserver
and udig.
      

Should I file this for geoserver or geotools? I guess the latter?
    
The latter indeed, renderer module :slight_smile:
  

GEOT-1128
Please review my wording of the issue, I guess someone who knows the code better migh want to rephrase it.

Cheers
Andrea

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users
  

8

Vincent Schut wrote:

Andrea Aime wrote:
  

Vincent Schut ha scritto:
    

Andrea Aime wrote:
      

No overlook unfortunately. Just the label is too long.
We would need some kind of dynamic anchorpoint, were the software decides the best anchor point trying to fit the label in the rendering
bounding box. That would open a can of worms thought, because this would
interact with label collision as well (when two labels collide, can I move one, and how?).
        

OK, so 1 workaround possible and 2 fixes? In order of difficulty:
      

Hey, just thought of another option for a workaround for long labels, someting I've used with mapserver: have the ability to render labels over more than one line. Mapserver solved this by allowing to configure a character that represented a line break. So you could have a label like 'very long/country name' and it would render:

very long
country name

Idea? Or probably not worth the effort...

Cheers
Vincent

9

Vincent Schut ha scritto:

Vincent Schut wrote:

Andrea Aime wrote:
  

Vincent Schut ha scritto:
    

Andrea Aime wrote:
      

No overlook unfortunately. Just the label is too long.
We would need some kind of dynamic anchorpoint, were the software decides the best anchor point trying to fit the label in the rendering
bounding box. That would open a can of worms thought, because this would
interact with label collision as well (when two labels collide, can I move one, and how?).
        

OK, so 1 workaround possible and 2 fixes? In order of difficulty:
      

Hey, just thought of another option for a workaround for long labels, someting I've used with mapserver: have the ability to render labels over more than one line. Mapserver solved this by allowing to configure a character that represented a line break. So you could have a label like 'very long/country name' and it would render:

very long
country name

Idea? Or probably not worth the effort...

I think a nice one, the trouble is just finding the time to implement it since it requires a few changes in the label manager.
Anyways, feel free to open another issue :slight_smile:
Cheers
Andrea

10

Andrea Aime wrote:

Vincent Schut ha scritto:
  

Vincent Schut wrote:
    

Andrea Aime wrote:
  

Vincent Schut ha scritto:
    

Andrea Aime wrote:
      

No overlook unfortunately. Just the label is too long.
We would need some kind of dynamic anchorpoint, were the software decides the best anchor point trying to fit the label in the rendering
bounding box. That would open a can of worms thought, because this would
interact with label collision as well (when two labels collide, can I move one, and how?).
        

OK, so 1 workaround possible and 2 fixes? In order of difficulty:
      

Hey, just thought of another option for a workaround for long labels, someting I've used with mapserver: have the ability to render labels over more than one line. Mapserver solved this by allowing to configure a character that represented a line break. So you could have a label like 'very long/country name' and it would render:

very long
country name

Idea? Or probably not worth the effort...
    
I think a nice one, the trouble is just finding the time to implement it since it requires a few changes in the label manager.
Anyways, feel free to open another issue :slight_smile:
  

Hey, I'll set priority to super-minor :slight_smile:
Feels like I should learn more java and familiarize with the geoserver/geotools codebase <shiver>eclipse...</shiver>...
By the way, did I hear someone say there was a trophee for most issues opened per week? :smiley:

Cheers
Andrea

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users