Bug report #20091

WCS request for a GeoServer ImageMosaic reports invalid layer provider

Added by Nikola Jankovic about 6 years ago. Updated over 5 years ago.

Status:Open
Priority:Normal
Assignee:-
Category:Web Services clients/WCS
Affected QGIS version:3.4.1 Regression?:No
Operating System:Ubuntu 18.04 Easy fix?:No
Pull Request or Patch supplied:No Resolution:
Crashes QGIS or corrupts data:No Copied to github as #:27913

Description

I have published temporal tiff files as an ImageMosaic with GeoServer and tested with normal GET requests and everything seems to be working fine.

When I make a WCS request in QGIS for a certain date some of the data are fetched and for another date report 

Raster layer Provider is not valid 
java.io.IOException: No raster data found in the request (it may be that the request bbox is outside of the coverage area, or that the filters used match no portions of it. No raster data found in the request (it may be that the request bbox is outside of the coverage area, or that the filters used match no portions of it

Looking closer at the requests received by GeoServer I am noticing two requests (in both cases where the request is complete and and for an error) for bounding boxes.
First bounding box (which is equal to the extent of the mosaic): 

929433.98,5700809.91,2039919.94,6436953.01

Second bounding box (a small bounding box in the centre of the mosaic): 
1484629.37,6068853.86,1484724.55,6068909.07

in EPSG:3857

The second bounding box confuses me because this bbox doesn't cover the data (in a lot of cases) in the irregular mosaic and doesn't end up fetching the data.

Secondly the behavior of loaded files with QGIS is a bit strange. PNG files seem to be cropped differently and GeoTIFF files only show up on a certain zoom level, zooming in and out doesn't display with error

WARNING    Received coverage has wrong extent 1251247.5183903556317091,5818562.1712298281490803 : 2017636.4035082703921944,6372138.3935530157759786 (expected 1314151.5152331423014402,5900839.9587073447182775 : 1986936.3522644806653261,6287315.0823438772931695)

Still not sure if it is a QGIS problem, GeoServer problem or data problem though. I will post a couple of pictures with more info for reference. If you need more information I'll try to provide.

1.png - the mosaic that is fetched in PNG and the red dot represents the second extent. The black isn't actually NODATA I think its because i requested a png (1.48 MB) Nikola Jankovic, 2018-10-12 02:17 PM

2.png - another mosaic that is fetched in geotiff and renders only for this extent, there is no black background here (2.17 MB) Nikola Jankovic, 2018-10-12 02:21 PM

1.png - The mosaic rendered properly when zooming to layer and extent is fully contained in the window (1.08 MB) Nikola Jankovic, 2018-11-28 10:13 AM

2.png - The mosaic not rendering properly when panned to the side (228 KB) Nikola Jankovic, 2018-11-28 10:14 AM

3.png - Not rendering properly again when zoomed in (228 KB) Nikola Jankovic, 2018-11-28 10:15 AM

History

#1 Updated by Giovanni Manghi about 6 years ago

  • Status changed from Open to Feedback

An URL we can use would be great.

#2 Updated by Nikola Jankovic about 6 years ago

I am currently testing it locally. I will see if I can provide it externally or send some data after the weekend.

#3 Updated by Nikola Jankovic almost 6 years ago

  • Assignee set to Giovanni Manghi
  • File 3.png added
  • File 2.png added
  • File 1.png added

Sorry for the wait. The test server is up and running at https://geoserver.eodc.eu/geoserver/ows

If you look at the layer fapar, you will see that it can be requested properly for the date 2017-04-01 as GeoTIFF in EPSG:3857. However for the date 2017-04-04 the request fails as no layer is in the bounding box that QGIS is sending, but a normal GET or POST request with a different bbox works. Also when panning the layer 2017-04-01 out of the window or when zooming in so that the extent is outside of the window it fails to render properly.

I am attaching some more screenshots.

I have tried this originally with 3.2.3 but it also fails with version 3.4.1.

#4 Updated by Giovanni Manghi almost 6 years ago

  • Affected QGIS version changed from 3.2.3 to 3.4.1
  • Assignee deleted (Giovanni Manghi)
  • Status changed from Feedback to Open

#5 Updated by Nikola Jankovic almost 6 years ago

Any progress? I was required to lock down the server, but if the devs email me I'll provide an account.

#6 Updated by Nikola Jankovic over 5 years ago

I have a bit of an update. Tried providing the same data in EPSG:3857 through Geoserver and it rendered properly within qgis, so it seems that it might be a custom crs issue.

The WKT of the CRS is below.

PROJCS["Azimuthal_Equidistant",GEOGCS["GCS_WGS_1984",DATUM["D_WGS_1984",SPHEROID["WGS_1984",6378137.0,298.257223563]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.017453292519943295]],PROJECTION["Azimuthal_Equidistant"],PARAMETER["false_easting",5837287.81977],PARAMETER["false_northing",2121415.69617],PARAMETER["central_meridian",24.0],PARAMETER["latitude_of_origin",53.0],UNIT["Meter",1.0]]

Currently we are going through some more geoserver tests so the previous link will not be available.

Also available in: Atom PDF