[Geoserver-users] WCS GetCoverage - The smaller the bounding box, the more data you get?

GeoServer GeoServer User
1

I’m not sure what’s going on, so I’m going to describe what I’m observing.

If I make the following WCS request (using the provided Img_Sample data)

/geoserver/ows?service=wcs&version=1.1.0&request=GetCoverage&identifier=Img_Sample&format=image/tiff&boundingbox=20.7052,-130.85168,54.1141,-62.0054,urn:ogc:def:crs:EPSG::4326&RangeSubset=contents

I get roughly, an 8 MB response with the image resolution being 983x2026 pixels.

If I make the following request (narrowing the bounding box):

/geoserver/ows?service=wcs&version=1.1.0&request=GetCoverage&identifier=Img_Sample&format=image/tiff&boundingbox=54,-63,54.1141,-62.0054,urn:ogc:def:crs:EPSG::4326&RangeSubset=contents

I get roughly, a 33 MB response with the image resolution being 983x8569 pixels.

And so forth. The smaller the bounding box, the exceedingly big the response (until I start seeing clipping errors). Also, the width stays constant at 983 pixels. I’ve tried this with other data, and reproduced similar behaviour. If I do the same boundingbox extent reduction with MapServer, I get smaller responses, with a lower resolution (image size). Is GeoServer somehow upsampling the data, ignoring the grid definition of the coverage described in the Coverage Description response?

Using GDAL as a client, I’m getting ridiculous amounts of data for a 2x2 request. (See what Frank was doing here: http://jira.codehaus.org/browse/GEOS-1717)

I first noticed this with the following GeoServer instance. Here’s the first request made by GDAL. It is a 2x2 request, and it’s returning 11 GB(!!) of data.

(FYI: Replace DOT with . in the domain to try it out. I don’t want any bots triggering this while crawling this post.)
http://geodataDOTnationaalgeoregisterDOTnl/ahn2/wcs?SERVICE=WCS&VERSION=1.1.1&REQUEST=GetCoverage&IDENTIFIER=ahn2_5m&FORMAT=image%2Ftiff&BOUNDINGBOX=19242.5,506242.5,19247.5,506247.5,urn:ogc:def:crs:EPSG::28992&RangeSubset=contents

Am I forgetting something, because something doesn’t seem right to me.

Cheers,

Tim Astle

2

Hi,

I haven’t been playing with WCS for a while so I may be a bit lost but I hope I can give some help.

First, what you experience is probably wrong and service should send data by using the gridOffsets which are advertised in the describeCoverage response independently of the boundingbox used in the request.

However, if I were you I would just add &GridOffsets= to the query and tell explicitly what resolution I want to get. Actually myself I prefer to use WCS 1.0.0 because for me the BBOX= and RESX= RESY= parameters are somehow easier to remember and with raster maps and aerial images they offer all the functionality I need.

It would be fine if you can reproduce the error with some of the demo coverages listed by http://localhost:8080/geoserver/ows?service=wcs&version=1.1.1&request=GetCapabilities and file a Jira issue.

-Jukka Rahkonen-

3

Thanks Jukka,

I did reproduce the problem with the sample data sets. The first two queries were using Img_Sample.

I’ve created GEOS-6639 for this.

Cheers,

Tim

···

On 28/08/2014 6:17 PM, Rahkonen Jukka (Tike) wrote:

Hi,

I haven’t been playing with WCS for a while so I may be a bit lost but I hope I can give some help.

First, what you experience is probably wrong and service should send data by using the gridOffsets which are advertised in the describeCoverage response independently of the boundingbox used in the request.

However, if I were you I would just add &GridOffsets= to the query and tell explicitly what resolution I want to get. Actually myself I prefer to use WCS 1.0.0 because for me the BBOX= and RESX= RESY= parameters are somehow easier to remember and with raster maps and aerial images they offer all the functionality I need.

It would be fine if you can reproduce the error with some of the demo coverages listed by http://localhost:8080/geoserver/ows?service=wcs&version=1.1.1&request=GetCapabilities and file a Jira issue.

-Jukka Rahkonen-

Timothy Astle wrote:

I’m not sure what’s going on, so I’m going to describe what I’m observing.

If I make the following WCS request (using the provided Img_Sample data)

/geoserver/ows?service=wcs&version=1.1.0&request=GetCoverage&identifier=Img_Sample&format=image/tiff&boundingbox=20.7052,-130.85168,54.1141,-62.0054,urn:ogc:def:crs:EPSG::4326&RangeSubset=contents

I get roughly, an 8 MB response with the image resolution being 983x2026 pixels.

If I make the following request (narrowing the bounding box):

/geoserver/ows?service=wcs&version=1.1.0&request=GetCoverage&identifier=Img_Sample&format=image/tiff&boundingbox=54,-63,54.1141,-62.0054,urn:ogc:def:crs:EPSG::4326&RangeSubset=contents

I get roughly, a 33 MB response with the image resolution being 983x8569 pixels.

And so forth. The smaller the bounding box, the exceedingly big the response (until I start seeing clipping errors). Also, the width stays constant at 983 pixels. I’ve tried this with other data, and reproduced similar behaviour. If I do the same boundingbox extent reduction with MapServer, I get smaller responses, with a lower resolution (image size). Is GeoServer somehow upsampling the data, ignoring the grid definition of the coverage described in the Coverage Description response?

Using GDAL as a client, I’m getting ridiculous amounts of data for a 2x2 request. (See what Frank was doing here: http://jira.codehaus.org/browse/GEOS-1717)

I first noticed this with the following GeoServer instance. Here’s the first request made by GDAL. It is a 2x2 request, and it’s returning 11 GB(!!) of data.

(FYI: Replace DOT with . in the domain to try it out. I don’t want any bots triggering this while crawling this post.)
http://geodataDOTnationaalgeoregisterDOTnl/ahn2/wcs?SERVICE=WCS&VERSION=1.1.1&REQUEST=GetCoverage&IDENTIFIER=ahn2_5m&FORMAT=image%2Ftiff&BOUNDINGBOX=19242.5,506242.5,19247.5,506247.5,urn:ogc:def:crs:EPSG::28992&RangeSubset=contents

Am I forgetting something, because something doesn’t seem right to me.

Cheers,

Tim Astle

------------------------------------------------------------------------------
Slashdot TV.  
Video for Nerds.  Stuff that matters.
[http://tv.slashdot.org/](http://tv.slashdot.org/)

_______________________________________________
Geoserver-users mailing list
[Geoserver-users@lists.sourceforge.net](mailto:Geoserver-users@lists.sourceforge.net)
[https://lists.sourceforge.net/lists/listinfo/geoserver-users](https://lists.sourceforge.net/lists/listinfo/geoserver-users)

–

Tim Astle
Development Manager
Web Technologies

CARIS
115 Waggoners Lane
Fredericton, New Brunswick
Canada E3B 2L4
Tel: +1.506.458.8533 Fax: +1.506.459.3849
www.caris.com

Connect with CARIS
Twitter | LinkedIn | Facebook | Google+ | YouTube

Download your free copy of CARIS Easy View today!
www.caris.com/easyview

This email and any files transmitted with it are confidential and intended only for the addressee(s). If you are not the intended recipient(s) please notify us by email reply. You should not use, disclose, distribute or copy this communication if received in error.

Any views or opinions expressed in this email are solely those of the author and do not necessarily represent those of the company. No binding contract will result from this email until such time as a written document is signed on behalf of the company.