WMS doesn't scale requests properly

[Dimitar Misev]

This is the coverage bbox:

  1060215.8783503  5836560.6476549  1686388.0139753  6462732.7832799

and this is the requested subset:

  1373301.9461628  5836560.6476549  1686388.0139753  6149646.7154674

in the petascope log:

{crs=EPSG:3857, visible=true, width=256, layers=ls8_tyrol_B2_3857, styles=greyscale, 
format=image/png, version=1.3.0, rasqltransformfragment=(char)($Iterator / 200), exceptions=INIMAGE, 
height=256, bbox=1373301.9461628, 5836560.6476549,1686388.0139753,6149646.7154674, 
request=GetMap, service=WMS, transparent=TRUE}

the generated rasql request:

SELECT encode((char)(SCALE(ls8_tyrol_B2_3857[7058:7927,995:8051], [0:256, 0:256]) / 200), 
              "png") FROM ls8_tyrol_B2_3857 WHERE oid(ls8_tyrol_B2_3857) = 14337

the sdom of ls8_tyrol_B2_3857 is

[0:7926,0:8052]

The rasql subset looks wrong to me, I suppose it should rather be a square?
Consequently the output is stretched (check ​here)

[Dimitar Misev]

I expect it to be a trivial fix, basically the rasql request should not be cut off to the sdom.

[Alex Dumitru]

Will look into it tomorrow, hopefully it should be simple to fix.

[Alex Dumitru]

Will look into it tomorrow, hopefully it should be simple to fix.

[Alex Dumitru]

@Dimitar, what would you consider the correct sdom here?

[Alex Dumitru]

The BBOX that you attached is wrong, please check the bbox here:

http://viseo-fusion.eu:8080/rasdaman/ows?service=WCS&version=2.0.1&request=DescribeCoverage&coverageId=ls8_tyrol_B2_3857 
and here
http://viseo-fusion.eu:8080/rasdaman/ows?service=WMS&version=1.3.0&request=GetCapabilities

The real bbox is:

1060215.87835027165 5836560.64765492325 1411829.37392353255 6193763.05459972835

The request that you are making on the x-axis:

1373301.9461628:1686388.0139753

is outside the bounds of the layer.
Normally, the standard says to throw an error and we used to do that, but most WMS clients (Openlayers 2 included) request invalid bboxes that go over the bounds. In order to allow users to use them, we decided to just check if the interval on one axis is over the bounds and if so, to trim it to the correct bound. Openlayers3 and QGIS seems to deal correctly with this, not sure how OL2 behaves.
If you want a different behavior let me know and we'll see how to accommodate it.

[Dimitar Misev]

In order to allow users to use them, we decided to just check if the interval on one axis is over the bounds and if so, to trim it to the correct bound.

The trimming is not correct in this case as you still scale to a square in the end; either 1) trim the scale as well proportionally, or 2) do not trim at all. I think OpenLayers 2 would expect 2) as it seems to generate the subset over the bounds already, so I'd prefer that solution.

[Alex Dumitru]

Ok, this seems to fit our usecases.

[Dimitar Misev]

Btw, I have a feeling [0:256, 0:256] might be wrong for the scale interval?
More probably OL2 requested a 256x256 png than a 257x257?

[Alex Dumitru]

Yes, you are right, thanks for the hint!

[Alex Dumitru]

Unfortunately I couldn't restrict the size of the output as QGIS expected a 256 by 256 image and I suspect OL2 would want the same.
I changed the default WMS behavior at the boundaries to just append nodata pixels until the desired bbox is reached. Seems to work well with all clients, OL2 included.
Furthermore, now when you add transparent=true to the request it will make all nodata pixels transparent for image/[png|gif] so it should help with your demo. Please test and let me know if the behavior fits your usecase.

[Dimitar Misev]

Perfect, that's what I thought would be the best option as well, as most clients expect a square even if most of it is nodata.