[Geoserver-users] Labelling - why are they only showing intermittently?

Hi List,
I’m getting some weird labelling behaviour (using GS 2.5.1).

As you can see here:
http://maps.warwickshire.gov.uk/gs/wms?LAYERS=z_OS_Vector_Basemap&STYLES=&FORMAT=image%2Fpng&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&SRS=EPSG%3A27700&BBOX=428428.71093752,264954.34570313,428618.8964844,265128.17382813&WIDTH=779&HEIGHT=712

The entire large street is unlabelled. It’s supposed to have two separate labels from two attributes of the same feature coming from one rule with two TextSymbolisers. One places a road number (Like the “A445” at the top) and the other places the road name (like the “castle hill” in the bottom left).

But for some reason neither is appearing here. If I pan around a bit, sometimes one of them shows and sometimes the other one but rarely both. Zooming in/out has similar effects.

This is what the line feature looks like (four components):

Inline images 1

I’m using these vendor options for both labels:
<se:VendorOption name=“group”>yes</se:VendorOption>
<se:VendorOption name=“followLine”>true</se:VendorOption>

I’ve tried adding a “repeat” option, but that didn’t seem to have the desired effect.

It’s no less random via a TMS (4*4 meta tiling).

Doe anyone have any suggestions? I know labelling can be something of a dark art, but this one has me stumped.

Thanks,
Jonathan

This transmission is intended for the named addressee(s) only and may contain confidential, sensitive or personal information and should be handled accordingly. Unless you are the named addressee (or authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else. If you have received this transmission in error please notify the sender immediately. All email traffic sent to or from us, including without limitation all GCSX traffic, may be subject to recording and/or monitoring in accordance with relevant legislation.

On Fri, Jul 11, 2014 at 6:48 PM, Jonathan Moules <
jonathanmoules@anonymised.com> wrote:

Hi List,
I'm getting some weird labelling behaviour (using GS 2.5.1).

As you can see here:

http://maps.warwickshire.gov.uk/gs/wms?LAYERS=z_OS_Vector_Basemap&STYLES=&FORMAT=image%2Fpng&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&SRS=EPSG%3A27700&BBOX=428428.71093752,264954.34570313,428618.8964844,265128.17382813&WIDTH=779&HEIGHT=712

The entire large street is unlabelled. It's supposed to have two separate
labels from two attributes of the same feature coming from one rule with
two TextSymbolisers. One places a road number (Like the "A445" at the top)
and the other places the road name (like the "castle hill" in the bottom
left).

But for some reason neither is appearing here. If I pan around a bit,
sometimes one of them shows and sometimes the other one but rarely both.
Zooming in/out has similar effects.

This is what the line feature looks like (four components):
!image.png|601x376

I'm using these vendor options for both labels:
            <se:VendorOption name="group">yes</se:VendorOption>
            <se:VendorOption name="followLine">true</se:VendorOption>

I've tried adding a "repeat" option, but that didn't seem to have the
desired effect.
It's no less random via a TMS (4*4 meta tiling).

Doe anyone have any suggestions? I know labelling can be something of a
dark art, but this one has me stumped.

Have you tried with:
* setting followLine to false, to see where it's trying to put the labels?
* adding maxDisplacement (
http://docs.geoserver.org/latest/en/user/styling/sld-reference/labeling.html#maxdisplacement
)

Cheers
Andrea

--

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------

Hi Andrea,
Thanks for the thoughts.

followLine makes no difference as to whether the text shows. It simply makes the text misplaced when set to false:
Inline images 1

maxDisplacement however did resolve the issue - I’ve ended up using a setting of 150. Sometimes it still only shows one of the labels rather than both of them (i.e., just the road number not the road name), even though I’ve only panned a couple of pixels and the feature has tons of space to place the label. Any potential reason for that?

You can see how little of the street the labels actually take up here:
Inline images 2

This transmission is intended for the named addressee(s) only and may contain confidential, sensitive or personal information and should be handled accordingly. Unless you are the named addressee (or authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else. If you have received this transmission in error please notify the sender immediately. All email traffic sent to or from us, including without limitation all GCSX traffic, may be subject to recording and/or monitoring in accordance with relevant legislation.

image.png

···

I’ve also tested with “conflictResolution” = false. In that case the labels always show up, albeit overlapping (so the road name is under the street number). So this appears to be purely a conflict/overlap decision-tree issue.

I get how maxDisplacement works from reading that page, however, when it was unset surely it should have shown at least one of the labels in such a conflict situation? Would this be a potential bug?

Cheers,
Jonathan

On 13 July 2014 08:19, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Fri, Jul 11, 2014 at 6:48 PM, Jonathan Moules <jonathanmoules@anonymised.com> wrote:

Hi List,
I’m getting some weird labelling behaviour (using GS 2.5.1).

As you can see here:
http://maps.warwickshire.gov.uk/gs/wms?LAYERS=z_OS_Vector_Basemap&STYLES=&FORMAT=image%2Fpng&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&SRS=EPSG%3A27700&BBOX=428428.71093752,264954.34570313,428618.8964844,265128.17382813&WIDTH=779&HEIGHT=712

The entire large street is unlabelled. It’s supposed to have two separate labels from two attributes of the same feature coming from one rule with two TextSymbolisers. One places a road number (Like the “A445” at the top) and the other places the road name (like the “castle hill” in the bottom left).

But for some reason neither is appearing here. If I pan around a bit, sometimes one of them shows and sometimes the other one but rarely both. Zooming in/out has similar effects.

This is what the line feature looks like (four components):

Inline images 1

I’m using these vendor options for both labels:
<se:VendorOption name=“group”>yes</se:VendorOption>
<se:VendorOption name=“followLine”>true</se:VendorOption>

I’ve tried adding a “repeat” option, but that didn’t seem to have the desired effect.

It’s no less random via a TMS (4*4 meta tiling).

Doe anyone have any suggestions? I know labelling can be something of a dark art, but this one has me stumped.

Have you tried with:

Cheers
Andrea

==

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.

==

Ing. Andrea Aime

@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it


On Mon, Jul 14, 2014 at 2:18 PM, Jonathan Moules <
jonathanmoules@anonymised.com> wrote:

Hi Andrea,
Thanks for the thoughts.

followLine makes no difference as to whether the text shows. It simply
makes the text misplaced when set to false:
!image.png|96x42

maxDisplacement however did resolve the issue - I've ended up using a
setting of 150. Sometimes it still only shows one of the labels rather than
both of them (i.e., just the road number not the road name), even though
I've only panned a couple of pixels and the feature has tons of space to
place the label. Any potential reason for that?

You can see how little of the street the labels actually take up here:
!image.png|189x131

I've also tested with "conflictResolution" = false. In that case the
labels *always* show up, albeit overlapping (so the road name is under the
street number). So this appears to be purely a conflict/overlap
decision-tree issue.

I get how maxDisplacement works from reading that page, however, when it
was unset surely it should have shown at least one of the labels in such a
conflict situation? Would this be a potential bug?

It may be, it may be not... why don't you open a ticket on jira, and attach
data, style and request that
makes it fail, so that we can have a look at what the issue might be?

Cheers
Andrea

--

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------

Hi Andrea,
Well, after exhaustive testing it turns out it seems to be an issue of interacting labelling layers.

Within its own group it works just as I’d expect given the default of maxDisplacement:

http://maps.warwickshire.gov.uk/gs/wms?LAYERS=OS_VML_ROADCENTRELINE&STYLES=&FORMAT=image%2Fpng&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&SRS=EPSG%3A27700&BBOX=428428.71093752,264954.34570313,428618.8964844,265128.17382813&WIDTH=779&HEIGHT=712

This transmission is intended for the named addressee(s) only and may contain confidential, sensitive or personal information and should be handled accordingly. Unless you are the named addressee (or authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else. If you have received this transmission in error please notify the sender immediately. All email traffic sent to or from us, including without limitation all GCSX traffic, may be subject to recording and/or monitoring in accordance with relevant legislation.

image.png

image.png

image.png

···

But throw in the other text layer:

http://maps.warwickshire.gov.uk/gs/wms?LAYERS=OS_VML_ROADCENTRELINE,OS_MM_CARTOGRAPHIC_TEXT&STYLES=&FORMAT=image%2Fpng&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&SRS=EPSG%3A27700&BBOX=428428.71093752,264954.34570313,428618.8964844,265128.17382813&WIDTH=779&HEIGHT=712

Of course, the weird thing again is as you can see, there’s plenty of space for the label to be placed down the middle of the street (which is where it’s placed much of the time):
Inline images 1

Is it still worth opening a JIRA or is this just some bad-luck with centroids and placement of text in relation to other text? (the other text only has “conflictResolution = true” as its vendorParameter).

Assuming my understanding of layer render ordering is valid, the road text is rendered first, though I seem to remember labelling is something of a special case.
Thoughts? I can open a JIRA if you think it’s worth it.

Cheers,
Jonathan

On 14 July 2014 14:17, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Mon, Jul 14, 2014 at 2:18 PM, Jonathan Moules <jonathanmoules@…4942…> wrote:

Hi Andrea,
Thanks for the thoughts.

followLine makes no difference as to whether the text shows. It simply makes the text misplaced when set to false:
Inline images 1

maxDisplacement however did resolve the issue - I’ve ended up using a setting of 150. Sometimes it still only shows one of the labels rather than both of them (i.e., just the road number not the road name), even though I’ve only panned a couple of pixels and the feature has tons of space to place the label. Any potential reason for that?

You can see how little of the street the labels actually take up here:
Inline images 2

It may be, it may be not… why don’t you open a ticket on jira, and attach data, style and request that

makes it fail, so that we can have a look at what the issue might be?

Cheers
Andrea

==

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.

==

Ing. Andrea Aime

@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it


I’ve also tested with “conflictResolution” = false. In that case the labels always show up, albeit overlapping (so the road name is under the street number). So this appears to be purely a conflict/overlap decision-tree issue.

I get how maxDisplacement works from reading that page, however, when it was unset surely it should have shown at least one of the labels in such a conflict situation? Would this be a potential bug?

On Mon, Jul 14, 2014 at 5:03 PM, Jonathan Moules <
jonathanmoules@anonymised.com> wrote:

But throw in the other text layer:

http://maps.warwickshire.gov.uk/gs/wms?LAYERS=OS_VML_ROADCENTRELINE,
*OS_MM_CARTOGRAPHIC_TEXT*
&STYLES=&FORMAT=image%2Fpng&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&SRS=EPSG%3A27700&BBOX=428428.71093752,264954.34570313,428618.8964844,265128.17382813&WIDTH=779&HEIGHT=712

Of course, the weird thing again is as you can see, there's plenty of
space for the label to be placed down the middle of the street (which is
where it's placed much of the time):
!image.png|563x326

Ah, there is plenty of space yes, but the labelling engine has a space
reservation system that is pretty simple,
it uses the axis aligned bounding box of the label to reserve and check
so... a diagonal label takes
a _lot_ of extra space

This is done for performance reasons, as checking intersections between
randomly rotated bounding
boxes (and for curved labels, funny curved worms) would be much more
intensive.

I had some thoughts about switching from rectangle based to "raster" based,
to account more or less
for the actual space used by the labels, but the funding to do this kind of
switch never materialized

Cheers
Andrea

Is it still worth opening a JIRA or is this just some bad-luck with
centroids and placement of text in relation to other text? (the other text
only has "conflictResolution = true" as its vendorParameter).

Assuming my understanding of layer render ordering is valid, the road text
is rendered first, though I seem to remember labelling is something of a
special case.

Yes, all labels are rendered at the end, so if you assign a high priority
to some labels, they should be rendered
before the others regardless of the layer order.
One little known thing is that the default priority is 1000, so you have to
go above it. Don't know why 1000 was chosen,
that was done by, I believe, David Blasby, many many years ago

Cheers
Andrea

--

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------

Hi Andrea,
Thanks for the explanation, it’s interesting stuff and does make sense about the bounding boxes; approximations are almost always faster after all.

For now I’ll just stick with using SLD 1.0 for the styles where I require prioritisation. There aren’t many.

One little known thing is that the default priority is 1000, so you have to go above it.

This transmission is intended for the named addressee(s) only and may contain confidential, sensitive or personal information and should be handled accordingly. Unless you are the named addressee (or authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else. If you have received this transmission in error please notify the sender immediately. All email traffic sent to or from us, including without limitation all GCSX traffic, may be subject to recording and/or monitoring in accordance with relevant legislation.

image.png

···

I did pick that up (why I’m using 2000 and 10,000) - it’s neatly documented though I guess not everyone reads them. :wink:

Thanks again,
Jonathan

On 17 July 2014 05:34, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Mon, Jul 14, 2014 at 5:03 PM, Jonathan Moules <jonathanmoules@anonymised.com> wrote:

Ah, there is plenty of space yes, but the labelling engine has a space reservation system that is pretty simple,
it uses the axis aligned bounding box of the label to reserve and check so… a diagonal label takes
a lot of extra space

This is done for performance reasons, as checking intersections between randomly rotated bounding
boxes (and for curved labels, funny curved worms) would be much more intensive.

I had some thoughts about switching from rectangle based to “raster” based, to account more or less
for the actual space used by the labels, but the funding to do this kind of switch never materialized

Cheers
Andrea

Yes, all labels are rendered at the end, so if you assign a high priority to some labels, they should be rendered
before the others regardless of the layer order.
One little known thing is that the default priority is 1000, so you have to go above it. Don’t know why 1000 was chosen,
that was done by, I believe, David Blasby, many many years ago

Cheers

Andrea

==

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.

==

Ing. Andrea Aime

@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it


But throw in the other text layer:

http://maps.warwickshire.gov.uk/gs/wms?LAYERS=OS_VML_ROADCENTRELINE,OS_MM_CARTOGRAPHIC_TEXT&STYLES=&FORMAT=image%2Fpng&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&SRS=EPSG%3A27700&BBOX=428428.71093752,264954.34570313,428618.8964844,265128.17382813&WIDTH=779&HEIGHT=712

Of course, the weird thing again is as you can see, there’s plenty of space for the label to be placed down the middle of the street (which is where it’s placed much of the time):
Inline images 1

Is it still worth opening a JIRA or is this just some bad-luck with centroids and placement of text in relation to other text? (the other text only has “conflictResolution = true” as its vendorParameter).

Assuming my understanding of layer render ordering is valid, the road text is rendered first, though I seem to remember labelling is something of a special case.