On GeoServer I have two layers, both cascading a remote WMS. Both layers work fine in the layer preview.

Now I am putting both into one group layer and open the preview, which shows an empty response. When trying to query the group layer in the browser with


I get the following response:

Rendering process failed Argument "bgColor" should not be null.

When I add &bgColor=0xFFFFFF to the request, I still get the same error response.

The same happens, when I call the underlying layers within the layers parameter, without using the group layer.

I thought, it might be about different WMS implementations on the remote WMS side, but even when I switch to different remote WMS services, the problem persists.

When Googling, I didn't find a response that seems to solve the problem. Do I miss something?


The WMS services I am using are

  • can you share the WMS you are cascading so we can test?
    – Ian Turton
    Oct 19 '16 at 11:21
  • @iant Yes, of course. I added the WMS as update to the question. Thanks.
    – ulrich
    Oct 19 '16 at 15:22
  • For Info the WMS 1.1.1 spec (section 6.2.2) says that a GET request has the following syntax ` host[:port]/path?{name[=value]&}` so to specify bgcolor you would use bgColor=0xFFFFFF& and not &bgColor=0xFFFFFF. However bgcolor is optional and doesn't have to be specified (default is 0xFFFFFF). So if a service is requiring bgcolor then that would appear to be a bug.
    – nmtoken
    Nov 30 '16 at 20:25
  • @nmtoken What's the exact difference between &bgColor=0xFFFFFF and bgColor=0xFFFFFF&? The sense is just to separate parameters, no? I usually omit the ampersand after the last kvp for manual requests...
    – ulrich
    Dec 14 '16 at 17:27
  • 1
    The exact difference is the location of the ampersand, which closes the name=value pairing. Strictly speaking this means that all WMS 1.1.1 URLs should end in an ampersand. The regex shows us that if we want to show a null value for bgcolor (to get the default) we should use bgColor& and not &bgcolor. If we keep this in mind (that the ampersand comes at the end) then we'll end up with URLs like: ...wms?service=WMS&version=1.1.1&request=GetMap&bgcolor& rather than something like ...wms?&service=WMS&version=1.1.1&request=GetMap&bgcolor, but obviously specifications are there to be ignored
    – nmtoken
    Dec 14 '16 at 20:00

This problem seems to be a bug in my current GeoServer 2.8 installation. I upgraded to the latest 2.8 build and the request works now.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.