[Geoserver-devel] Why GetLegendGraphic call in layer publishing tab doesn't use the onlineResource legend?

Hi list,
I have a couple of questions on the subject since I’m not too familiar with that and I’m trying to understand how it works.

I have configured a style with a RasterSymbolizer containing a colorMap.
Then, I have set a static legend for that style, referring to a colormap.png in the GEOSERVER_DATA_DIR/style folder, by configuring the Online Resource field.
Then, I have configured a raster layer, by specifying that style as default style.
However, I have noticed that the rendered legend isn’t the static one but it’s still the one dynamically computed from the style’s colormap.

Is it a bug or is it the expected behaviour?

Taking a look at the code:
https://github.com/geoserver/geoserver/blob/master/src/wms/src/main/java/org/geoserver/wms/legendgraphic/GetLegendGraphicKvpReader.java#L438

It seems like the external legend is only “retrieved” in case the InfoObj is an instance of a LayerInfo. Debugging there, it is a null object so no legend is retrieved.

Should the internal getLegendGraphic also provide the LAYER parameter (since we are in the Publishing tab of a Layer we should know that, right?)?

So, out of curiosity, I have tried passing the LAYER parameter to that getLegendGraphic but I’m still getting the computed legend instead of the static one.

Taking a look at the code, I see this:
This line fill the LegendRequest details
https://github.com/geoserver/geoserver/blob/master/src/wms/src/main/java/org/geoserver/wms/legendgraphic/GetLegendGraphicKvpReader.java#L155

This results into calling this:
https://github.com/geoserver/geoserver/blob/master/src/wms/src/main/java/org/geoserver/wms/legendgraphic/GetLegendGraphicKvpReader.java#L234

which setup a FeatureType here:
https://github.com/geoserver/geoserver/blob/master/src/wms/src/main/java/org/geoserver/wms/legendgraphic/GetLegendGraphicKvpReader.java#L235

Note that this line will set the name of the layer as “GridCoverage”
due to using the FeatureUtilities.wrapGridCoverageReader method.
https://github.com/geotools/geotools/blob/master/modules/library/coverage/src/main/java/org/geotools/resources/coverage/FeatureUtilities.java#L221

Long story short, when trying to get the LegendInfo at this line:
https://github.com/geoserver/geoserver/blob/master/src/wms/src/main/java/org/geoserver/wms/legendgraphic/GetLegendGraphicKvpReader.java#L441

will resolve the LegendInfo object but at line 445 it won’t get the LegendRequest:
since the name of the layer doesn’t match (being set by the wrapper to http://www.opengis.net/gml:GridCoverage.)

So I’m lost :slight_smile:

Does it represents a set of bugs or did I missed something?
Do you have any feedbacks on the topic?
Please, let me know.

Cheers,
Daniele

···

==

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

Ing. Daniele Romagnoli
Senior Software Engineer

GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272

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


AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.

Hi Daniele

I was under the impression that the custom legend graphic was primarily intended for use external to geoserver (e.g. client side). Consequently, I am not sure if this is intended functionality, or a bug; one could make an argument either way.

The changing of the name does seem to be a bug, and getLayerFeatureType should probably be modified so that the correct name is preserved. You can probably just save the name before calling FeatureUtilities and then set it after.

Torben

···

---------- Forwarded message ----------
From: Daniele Romagnoli <daniele.romagnoli@anonymised.com>
Date: Tue, Mar 15, 2016 at 12:54 PM
Subject: Why GetLegendGraphic call in layer publishing tab doesn’t use the onlineResource legend?
To: Geoserver-devel <geoserver-devel@lists.sourceforge.net>

Hi list,
I have a couple of questions on the subject since I’m not too familiar with that and I’m trying to understand how it works.

I have configured a style with a RasterSymbolizer containing a colorMap.
Then, I have set a static legend for that style, referring to a colormap.png in the GEOSERVER_DATA_DIR/style folder, by configuring the Online Resource field.
Then, I have configured a raster layer, by specifying that style as default style.
However, I have noticed that the rendered legend isn’t the static one but it’s still the one dynamically computed from the style’s colormap.

Is it a bug or is it the expected behaviour?

Taking a look at the code:
https://github.com/geoserver/geoserver/blob/master/src/wms/src/main/java/org/geoserver/wms/legendgraphic/GetLegendGraphicKvpReader.java#L438

It seems like the external legend is only “retrieved” in case the InfoObj is an instance of a LayerInfo. Debugging there, it is a null object so no legend is retrieved.

Should the internal getLegendGraphic also provide the LAYER parameter (since we are in the Publishing tab of a Layer we should know that, right?)?

So, out of curiosity, I have tried passing the LAYER parameter to that getLegendGraphic but I’m still getting the computed legend instead of the static one.

Taking a look at the code, I see this:
This line fill the LegendRequest details
https://github.com/geoserver/geoserver/blob/master/src/wms/src/main/java/org/geoserver/wms/legendgraphic/GetLegendGraphicKvpReader.java#L155

This results into calling this:
https://github.com/geoserver/geoserver/blob/master/src/wms/src/main/java/org/geoserver/wms/legendgraphic/GetLegendGraphicKvpReader.java#L234

which setup a FeatureType here:
https://github.com/geoserver/geoserver/blob/master/src/wms/src/main/java/org/geoserver/wms/legendgraphic/GetLegendGraphicKvpReader.java#L235

Note that this line will set the name of the layer as “GridCoverage”
due to using the FeatureUtilities.wrapGridCoverageReader method.
https://github.com/geotools/geotools/blob/master/modules/library/coverage/src/main/java/org/geotools/resources/coverage/FeatureUtilities.java#L221

Long story short, when trying to get the LegendInfo at this line:
https://github.com/geoserver/geoserver/blob/master/src/wms/src/main/java/org/geoserver/wms/legendgraphic/GetLegendGraphicKvpReader.java#L441

will resolve the LegendInfo object but at line 445 it won’t get the LegendRequest:
since the name of the layer doesn’t match (being set by the wrapper to http://www.opengis.net/gml:GridCoverage.)

So I’m lost :slight_smile:

Does it represents a set of bugs or did I missed something?
Do you have any feedbacks on the topic?
Please, let me know.

Cheers,
Daniele

==

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

Ing. Daniele Romagnoli
Senior Software Engineer

GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272

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


AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.

==

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

Ing. Daniele Romagnoli
Senior Software Engineer

GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272

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


AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.

On 15 March 2016 at 04:54, Daniele Romagnoli <
daniele.romagnoli@anonymised.com> wrote:

Hi list,
I have a couple of questions on the subject since I'm not too familiar
with that and I'm trying to understand how it works.

I have configured a style with a RasterSymbolizer containing a colorMap.
Then, I have set a static legend for that style, referring to a
colormap.png in the GEOSERVER_DATA_DIR/style folder, by configuring the
Online Resource field.
Then, I have configured a raster layer, by specifying that style as
default style.
However, I have noticed that the rendered legend isn't the static one but
it's still the one dynamically computed from the style's colormap.

Is it a bug or is it the expected behaviour?

One more thing to check ...can you review the GetCapabilities document
produced - does it list the static legend, or does it reference a
GetLegendGraphic request?

Taking a look at the code:

https://github.com/geoserver/geoserver/blob/master/src/wms/src/main/java/org/geoserver/wms/legendgraphic/GetLegendGraphicKvpReader.java#L438

It seems like the external legend is only "retrieved" in case the InfoObj
is an instance of a LayerInfo. Debugging there, it is a null object so no
legend is retrieved.

That is unfortunate, do we need to be more specific than getStyleByName?
What is the styleName and are we expecting something back?

Should the internal getLegendGraphic also provide the LAYER parameter

(since we are in the Publishing tab of a Layer we should know that, right?)?

On the publishing tab we have a design decision to make ... show the icon
that would be advertised in the capabilities document, or show a visual
representation of the SLD. SLD 1.1 also allows external legend graphics to
be listed in the SLD (giving us a third option).

So, out of curiosity, I have tried passing the LAYER parameter to that

getLegendGraphic but I'm still getting the computed legend instead of the
static one.

What do the test cases for this functionality cover? They may provide a
clue on how it is supposed to be used.

will resolve the LegendInfo object but at line 445 it won't get the

LegendRequest:
since the name of the layer doesn't match (being set by the wrapper to
http://www.opengis.net/gml:GridCoverage.)

So I'm lost :slight_smile:

Okay, so we have a bug - the code was tested with vector layers - and makes
the bad assumption that the name of the published layer is the same name as
the internal "feature type".

Does it represents a set of bugs or did I missed something?

You have at least one bug, with it looking up by the "GridCoverage" name,
and if you could check the GetCapabilities document and test case to see
expected functionality for vector.

Do you have any feedbacks on the topic?

I am not sure the test-cases covered a raster layer so you may of broken
new ground.

Jody

Hi,

(attachments)

publishingtab.png

···

On Mon, Mar 21, 2016 at 11:04 PM, Jody Garnett <jody.garnett@anonymised.com…403…> wrote:

On 15 March 2016 at 04:54, Daniele Romagnoli <daniele.romagnoli@anonymised.com> wrote:

geosolutions:Temperature_height_above_ground

Temperature_height_above_ground ..... temperature temperature image/png; charset=UTF-8

It seems it’s referring the static map.png legend.

Right now I can see the visual representation of colorMap in the style (the dynamic legend).

I see WMS LegendCapabilitiesTests testing the getCapabilities is containing the OnlineResource.
The GetLegendGraphicKvpReaderTest tests requests for lakes and pond layers (I assume they are vector layers) by also checking that the layer name is specified.

Thanks for your (Torben and Jody) feedbacks so far.

Hi list,
I have a couple of questions on the subject since I’m not too familiar with that and I’m trying to understand how it works.

I have configured a style with a RasterSymbolizer containing a colorMap.
Then, I have set a static legend for that style, referring to a colormap.png in the GEOSERVER_DATA_DIR/style folder, by configuring the Online Resource field.
Then, I have configured a raster layer, by specifying that style as default style.
However, I have noticed that the rendered legend isn’t the static one but it’s still the one dynamically computed from the style’s colormap.

Is it a bug or is it the expected behaviour?

One more thing to check …can you review the GetCapabilities document produced - does it list the static legend, or does it reference a GetLegendGraphic request?

Taking a look at the code:
https://github.com/geoserver/geoserver/blob/master/src/wms/src/main/java/org/geoserver/wms/legendgraphic/GetLegendGraphicKvpReader.java#L438

It seems like the external legend is only “retrieved” in case the InfoObj is an instance of a LayerInfo. Debugging there, it is a null object so no legend is retrieved.

That is unfortunate, do we need to be more specific than getStyleByName? What is the styleName and are we expecting something back?

Should the internal getLegendGraphic also provide the LAYER parameter (since we are in the Publishing tab of a Layer we should know that, right?)?

On the publishing tab we have a design decision to make … show the icon that would be advertised in the capabilities document, or show a visual representation of the SLD. SLD 1.1 also allows external legend graphics to be listed in the SLD (giving us a third option).

So, out of curiosity, I have tried passing the LAYER parameter to that getLegendGraphic but I’m still getting the computed legend instead of the static one.

What do the test cases for this functionality cover? They may provide a clue on how it is supposed to be used.

will resolve the LegendInfo object but at line 445 it won’t get the LegendRequest:
since the name of the layer doesn’t match (being set by the wrapper to http://www.opengis.net/gml:GridCoverage.)

So I’m lost :slight_smile:

Okay, so we have a bug - the code was tested with vector layers - and makes the bad assumption that the name of the published layer is the same name as the internal “feature type”.

Does it represents a set of bugs or did I missed something?

You have at least one bug, with it looking up by the “GridCoverage” name, and if you could check the GetCapabilities document and test case to see expected functionality for vector.

Do you have any feedbacks on the topic?

I am not sure the test-cases covered a raster layer so you may of broken new ground.

Jody

Cheers,
Daniele

==

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

Ing. Daniele Romagnoli
Senior Software Engineer

GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272

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


AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.

One more thing to check ...can you review the GetCapabilities document

produced - does it list the static legend, or does it reference a
GetLegendGraphic request?

<Layer queryable="1" opaque="0">
<Name>geosolutions:Temperature_height_above_ground</Name>
<Title>Temperature_height_above_ground</Title>
<Abstract/>
.....
<Style>
<Name>temperature</Name>
<Title>temperature</Title>
<LegendURL width="70" height="1082">
<Format>image/png; charset=UTF-8</Format>
<OnlineResource xmlns:xlink="http://www.w3.org/1999/xlink&quot; xlink:type="
simple" xlink:href="http://localhost:8092/geoserver/map.png&quot;/&gt;
</LegendURL>
</Style>
</Layer>

It seems it's referring the static map.png legend.

Good so one thing is working as expected!

Taking a look at the code:

https://github.com/geoserver/geoserver/blob/master/src/wms/src/main/java/org/geoserver/wms/legendgraphic/GetLegendGraphicKvpReader.java#L438

It seems like the external legend is only "retrieved" in case the
InfoObj is an instance of a LayerInfo. Debugging there, it is a null object
so no legend is retrieved.

That is unfortunate, do we need to be more specific than getStyleByName?
What is the styleName and are we expecting something back?

Should the internal getLegendGraphic also provide the LAYER parameter

(since we are in the Publishing tab of a Layer we should know that, right?)?

On the publishing tab we have a design decision to make ... show the icon
that would be advertised in the capabilities document, or show a visual
representation of the SLD. SLD 1.1 also allows external legend graphics to
be listed in the SLD (giving us a third option).

Right now I can see the visual representation of colorMap in the style
(the dynamic legend).

I think this is what we would like - since it is a visual representation of
the SLD being configured. I remember struggling with what to show here -
perhaps we could show both (there is room).

So, out of curiosity, I have tried passing the LAYER parameter to that

getLegendGraphic but I'm still getting the computed legend instead of the
static one.

What do the test cases for this functionality cover? They may provide a
clue on how it is supposed to be used.

I see WMS LegendCapabilitiesTests testing the getCapabilities is
containing the OnlineResource.
The GetLegendGraphicKvpReaderTest tests requests for lakes and pond layers
(I assume they are vector layers) by also checking that the layer name is
specified.

So GetLegendGraphicKvpReaderTest is reporting the static image if the layer
name lookup is successful (since the layer name and type name agree). This
difference of layer name vs type name was the main reason I refactored the
code (since they were getting hopelessly muddled). I trust we will have an
easier time sorting this out with all the request components broken out
into a data structure.

Thanks for digging into this!

(attachments)

publishingtab.png