#1223 closed defect (fixed)

WMS doesn't scale requests properly

Reported by: dmisev Owned by: mdumitru
Priority: critical Milestone: 9.2
Component: petascope Version: development
Keywords: Cc:
Complexity: Medium

Description

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)

Change History (12)

comment:1 Changed 20 months ago by dmisev

  • Priority changed from major to critical

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

comment:2 Changed 19 months ago by mdumitru

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

comment:3 Changed 19 months ago by mdumitru

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

comment:4 Changed 18 months ago by mdumitru

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

comment:5 Changed 18 months ago by mdumitru

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.

comment:6 Changed 18 months ago by dmisev

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.

comment:7 Changed 18 months ago by mdumitru

Ok, this seems to fit our usecases.

comment:8 Changed 18 months ago by dmisev

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?

comment:9 Changed 18 months ago by mdumitru

Yes, you are right, thanks for the hint!

Last edited 18 months ago by mdumitru (previous) (diff)

comment:10 Changed 18 months ago by mdumitru

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.

comment:11 Changed 18 months ago by dmisev

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.

comment:12 Changed 17 months ago by dmisev

  • Resolution set to fixed
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.