[Geoserver-users] GetLegendGraphic issue in GS 2.3-beta1

GeoServer GeoServer User
1

Hi everyone,

I’ve installed latest 2.3-beta1 geoserver and found out that I’m not getting layer legend images in GeoExplorer. URL that I use is:

localhost:8080/geoserver/wms?request=GetLegendGraphic&format=image/png&width=20&height=20&layer=restricted&transparent=true&format=image/png&legend_options=fontAntiAliasing:true;fofntSize:11;fontName:Arial&SCALE=136494.76705452034

Geoserver complains about format, so if I remove format=image/png key/value it works fine. Is this is a bug or format values were changed?

Thanks Alex

2

Its a bug, but not the obvious one.

Your URL has two “format=image/png” in it. Remove either one and it works fine. Leave them both in and I get:

“Invalid graphic format: [Ljava.lang.String;@d9275d”

With more testing it seems that that some fail in those circumstances (two “&layer” fails too) and some don’t. I’ll report it on JIRA as its inconsistent.

Jonathan

On 7 February 2013 02:11, Alexandre Djioev <djioev@anonymised.com> wrote:

Hi everyone,

I’ve installed latest 2.3-beta1 geoserver and found out that I’m not getting layer legend images in GeoExplorer. URL that I use is:

localhost:8080/geoserver/wms?request=GetLegendGraphic&format=image/png&width=20&height=20&layer=restricted&transparent=true&format=image/png&legend_options=fontAntiAliasing:true;fofntSize:11;fontName:Arial&SCALE=136494.76705452034

Geoserver complains about format, so if I remove format=image/png key/value it works fine. Is this is a bug or format values were changed?

Thanks Alex

Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb

Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

This transmission is intended for the named addressee(s) only and may contain sensitive or protectively marked material up to RESTRICTED 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.

3

On Thu, Feb 7, 2013 at 1:45 PM, Jonathan Moules <jonathanmoules@anonymised.com.4942…> wrote:

Its a bug, but not the obvious one.

Your URL has two “format=image/png” in it. Remove either one and it works fine. Leave them both in and I get:

“Invalid graphic format: [Ljava.lang.String;@d9275d”

With more testing it seems that that some fail in those circumstances (two “&layer” fails too) and some don’t. I’ll report it on JIRA as its inconsistent.

This is the result of adding support for WCS 2.0 in the general KVP parser, in WCS having two times the same parameter has
a meaning of its own, they cannot be ignored.

Cheers
Andrea

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it 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

4

Another spec that does odd things. :slight_smile:

Looking at the specs, WMS 1.1.0 doesn’t appear to have an opinion on duplicate parameters:

Parameters in a request may be specified in any order.

An OGC Web Service shall be prepared to encounter parameters that are not part of this

specification. In terms of producing results per this specification, an OGC Web Service

shall not require such parameters.

But WMS 1.3.0 is clearer:

When request parameters are duplicated with conflicting values, the response from the server may be undefined.

This International Standard does not mandate which of the duplicated values sent by the client are to be used by

the server.

However, these aren’t conflicting values, they’re identical values. Also, the second line strongly implies (to me anyway), that the WMS should still work with duplicate values, otherwise why specify that the server gets to choose which of the parameters to use? And that the server can perform “undefined” behaviour if they’re conflicting?
Just a thought.
Jonathan

On 7 February 2013 13:04, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Thu, Feb 7, 2013 at 1:45 PM, Jonathan Moules <jonathanmoules@anonymised.com> wrote:

Its a bug, but not the obvious one.

Your URL has two “format=image/png” in it. Remove either one and it works fine. Leave them both in and I get:

“Invalid graphic format: [Ljava.lang.String;@d9275d”

With more testing it seems that that some fail in those circumstances (two “&layer” fails too) and some don’t. I’ll report it on JIRA as its inconsistent.

This is the result of adding support for WCS 2.0 in the general KVP parser, in WCS having two times the same parameter has
a meaning of its own, they cannot be ignored.

Cheers
Andrea

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it 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

This transmission is intended for the named addressee(s) only and may contain sensitive or protectively marked material up to RESTRICTED 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.

5

On Thu, Feb 7, 2013 at 4:11 PM, Jonathan Moules <jonathanmoules@anonymised.com.4942…> wrote:

Another spec that does odd things. :slight_smile:

Looking at the specs, WMS 1.1.0 doesn’t appear to have an opinion on duplicate parameters:

Parameters in a request may be specified in any order.

An OGC Web Service shall be prepared to encounter parameters that are not part of this

specification. In terms of producing results per this specification, an OGC Web Service

shall not require such parameters.

But WMS 1.3.0 is clearer:

When request parameters are duplicated with conflicting values, the response from the server may be undefined.

This International Standard does not mandate which of the duplicated values sent by the client are to be used by

the server.

However, these aren’t conflicting values, they’re identical values. Also, the second line strongly implies (to me anyway), that the WMS should still work with duplicate values, otherwise why specify that the server gets to choose which of the parameters to use? And that the server can perform “undefined” behaviour if they’re conflicting?

If the response is undefined the server can do whatever it wants, including sending back an exception.

However GeoServer by tradition tries to to be backrwards incompatible, so apps that used to work against
version 2.2.x should keep on working in 2.3.x
I’m afraid the fix won’t be simple though…

Cheers
Andrea

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it 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

6

If the response is undefined the server can do whatever it wants, including sending back an exception.

Agreed; I fully expect conflicting values to end very badly. :slight_smile:
But my point was, the spec explicitly only says that “conflicting values” may lead to the undefined behaviour. These are non-conflicting, hence my inference they’re allowed (though of course, that is an inference).

Jonathan

On 7 February 2013 15:15, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Thu, Feb 7, 2013 at 4:11 PM, Jonathan Moules <jonathanmoules@anonymised.com> wrote:

Another spec that does odd things. :slight_smile:

Looking at the specs, WMS 1.1.0 doesn’t appear to have an opinion on duplicate parameters:

Parameters in a request may be specified in any order.

An OGC Web Service shall be prepared to encounter parameters that are not part of this

specification. In terms of producing results per this specification, an OGC Web Service

shall not require such parameters.

But WMS 1.3.0 is clearer:

When request parameters are duplicated with conflicting values, the response from the server may be undefined.

This International Standard does not mandate which of the duplicated values sent by the client are to be used by

the server.

However, these aren’t conflicting values, they’re identical values. Also, the second line strongly implies (to me anyway), that the WMS should still work with duplicate values, otherwise why specify that the server gets to choose which of the parameters to use? And that the server can perform “undefined” behaviour if they’re conflicting?

If the response is undefined the server can do whatever it wants, including sending back an exception.

However GeoServer by tradition tries to to be backrwards incompatible, so apps that used to work against
version 2.2.x should keep on working in 2.3.x
I’m afraid the fix won’t be simple though…

Cheers

Andrea

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it 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

This transmission is intended for the named addressee(s) only and may contain sensitive or protectively marked material up to RESTRICTED 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.