opengeospatial / ets-wms13

Repository for the Exectutable Test Suite for WMS 1.3.0
Apache License 2.0
2 stars 4 forks source link

Test getmap:transparent-default fails due to invalid width and height in GetMap request #22

Closed dstenger closed 8 years ago

dstenger commented 8 years ago

Test getmap:transparent-default type Mandatory default result Passed (s0002/d711e387_1/d1794e56_1/d1794e339_1)

Assertion: When a GetMap request is made with no TRANSPARENT parameter and a FORMAT that supports transparency over a layer that is not opaque, then the response contains no transparent pixels.

Context: Label: Value: WMS_Capabilities element

Request d1794e5681_1: Method: get URL: http://myserver/wms?&BbOx=-0.0025,-0.0025,0.0025,0.0025&ReQuEsT=GetMap&StYlEs=&LaYeRs=map_map_lakes&VeRsIoN=1.3.0&FoRmAt=image%2Fpng&CrS=CRS%3A84&HeIgHt=100100&WiDtH=100100 Response from parser parsers:ImageParser:

Messages from parser parsers:ImageParser:
     No image handlers available for the data stream. null

Result: Failed

dstenger commented 8 years ago

We analysed why your service is requested with "100100" for width and height instead of "100". When you take a look at the capabilites (http://myserver/wms?request=GetCapabilities&service=WMS) you can see that each layer name is present twice. This leads to the fact that the width and height are evaluated twice for these layers. Due to this the value "100" is added twice to the request parameters.

I guess that you previously had a more simple layer structure. On the other hand, why does the "category" layer have the same name as the child layer? This could lead to confusion when requesting a layer via GetMap (is the "category" layer or the child layer requested then?).

So, your service will pass again if the "category" layer and child layer have different names.