Broken LegendURL in WMTS GetCapabilities for styles with custom legend

Hi all,

I’ve come across an issue with broken URLs in the LegendURL element of WMTS GetCapabilities statements for styles with a custom legend. The URLs provided comprise the root URL of the service appended with the name of the image file for the custom legend, e.g.

<Style isDefault="true">
	<ows:Identifier>raster_test_custom_layer</ows:Identifier>
	<LegendURL format="image/png" xlink:href="http://localhost:8180/custom_legend.png" width="73" height="342"/>
</Style>

The URLs don’t resolve, which is causing issues with a portal application accessing our WMTS services.

The LegendURL in the WMS GetCapabilities statement provides a GetLegendGraphic URL that works:

<LegendURL width="73" height="342">
	<Format>image/png</Format>
	<OnlineResource xlink:type="simple" xlink:href="http://localhost:8180/ows?service=WMS&version=1.3.0&request=GetLegendGraphic&format=image%2Fpng&width=73&height=342&layer=nurc%3Amosaic"/>
</LegendURL>

I’m wondering if there’s a configuration in GeoServer or GeoWebCache that I’m missing, e.g. is there a way to get the WMS GetLegendGraphic URL into the WMTS GetCaps?

Tested on GeoServer 2.25.2 and 2.28.0.

Any advice would be much appreciated.

Thanks,

Aaron.

That sounds like … a bug :slight_smile:

While the GetLegendGraphic works, the actual custom_legend.png should be available directly from styles endpoint.

Something like:

  • http://localhost:8180/geoserver/styles/custom_legend.png

  • http://localhost:8180/geoserver/nurc/styles/custom_legend.png

Can you confirm and then we may have enough details to report a bug (and then seek resources to fix it).

I can confirm that the image files for the custom legends can be reached at the styles end points, in both the root styles directory and the workspace styles directories.

Thanks for pointing out that GeoServer provides a styles endpoint. It makes sense now why a URL for the image file is provided rather than a WMS GetLegendGraphic URL - just needs “styles”, and where applicable the workspace name, included in the URL path. So yes, this appears to be a bug. Unless there are objections I will log a ticket and look to resourcing a fix.

Cheers,

Aaron.

Thanks for confirming Aaron, I had a quick look and did not see any similar bug in the issue tracker so your report is welcome.