Hi,
Geoserver generates GetLegendGraphic-requests as the legend url. Here we stumbled upon a slight difference between
first the layer-name to which a style-element and its legend url belong (e.g. “tiger:poi” in the example below)
and second the “layer” attribute value of the GetLegendGraphic-request which is just “poi”, without a namespace/workspace prefix.
I would expect that the missing prefix could lead to ambiguities if different workspaces do have an equally named layer, correct?
Or is it on purpose, are there any reasons for this behaviour?
GetCapabilities example:
tiger:poi
Manhattan (NY) points of interest
….
burg
A small red flag
A sample of how to use an SVG based symbolizer
image/png
Best regards,
Sven
On Wed, Aug 7, 2013 at 2:22 PM, Sven Tschirner <Sven.Tschirner@anonymised.com>wrote:
Hi,****
Geoserver generates GetLegendGraphic-requests as the legend url. Here we
stumbled upon a slight difference between****
first the layer-name to which a style-element and its legend url belong
(e.g. “tiger:poi” in the example below) ****
and second the “layer” attribute value of the GetLegendGraphic-request
which is just “poi”, without a namespace/workspace prefix.****
** **
I would expect that the missing prefix could lead to ambiguities if
different workspaces do have an equally named layer, correct?****
Or is it on purpose, are there any reasons for this behaviour?
Most likely, when workspace specific styles were added (was it 2.3.x?) the
links generation in the capabilities
documents was not modified accordingly.
You can open a report on jira.codehaus.org (get an account on
xircles.codehaus.org), and then either wait,
donate a fix yourself, or look at commercial support options at
geoserver.org
Cheers
Andera
--
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
-------------------------------------------------------