Accuracy of Geoserver resolution

[uniomni]

This issues was posted to geoserver-devel on 6 June 2011 under the name:
Constraints of requested bounding box and resolution

---

Dear all

We are developing an application for risk modelling based on spatial data hosted in GeoServer and accessed through REST.

We came across what at first looked like precision issues in raster resolutions when resolutions of downloaded data was different to what was requested. This causes problems not just with our numerical calculations but also for the integrity checks we have implemented (e.g. that two layers have the same geo transform up to machine precision).

However, a closer look reveals that it is probably more a matter of what GeoServer does if asked for an impossible combination of bounding box and grid resolution. The little study below would indicate that the bounding box takes precedence and that resolution will be adjusted from the requested resolution to something that is consistent.

Can someone please let us know if this assumption is correct and also how to robustly compute consistent combinations of bounding box/resolution so that the response from GeoServer is guaranteed to be as requested?

Alternatively, what are your thoughts on changing the algorithm so that the bounding box is changed to follow the grid point resolution (I believe this is what is done in tools like Arc)?

Cheers and thanks
Ole

PS - I have attached a little Python program to assist with this study

---

Downloading using native parameters

Before uploading the file, gdalinfo reports

Origin = (122.577500000000001,2.022500000000000)
Pixel Size = (0.025000000000000,-0.025000000000000)

Corner Coordinates:
Upper Left ( 122.5775000, 2.0225000) (122d34'39.00"E, 2d 1'21.00"N)
Lower Left ( 122.5775000, -2.0025000) (122d34'39.00"E, 2d 0'9.00"S)
Upper Right ( 126.6025000, 2.0225000) (126d36'9.00"E, 2d 1'21.00"N)
Lower Right ( 126.6025000, -2.0025000) (126d36'9.00"E, 2d 0'9.00"S)
Center ( 124.5900000, 0.0100000) (124d35'24.00"E, 0d 0'36.00"N)

Downloading with REST using the exact same parameters
curl "http://localhost:8001/geoserver-geonode-dev/ows?version=1.0.0&service=wcs&request=getcoverage&format=GeoTIFF&store=false&coverage=shakemap_20110505155015&crs=EPSG:4326&bbox=122.5775,-2.0025,126.6025,2.0225&resx=0.025000000000&resy=0.025000000000" > dnld.tif

gdalinfo reports the exact same numbers as expected.

---

Downloading with adjusted bounding box

However, if I change the bounding box slightly (western boundary from 122.5775 to 122.58) and download again with the revised command:

curl "http://localhost:8001/geoserver-geonode-dev/ows?version=1.0.0&service=wcs&request=getcoverage&format=GeoTIFF&store=false&coverage=shakemap_20110505155015&crs=EPSG:4326&bbox=122.58,-2.0025,126.6025,2.0225&resx=0.025000000000&resy=0.025000000000" > dnld.tif

gdalinfo reports resolution values adjusted for the change in bounding box:

Origin = (122.579999999999998,2.022500000000000)
Pixel Size = (0.024984472049690,-0.025000000000000)

Corner Coordinates:
Upper Left ( 122.5800000, 2.0225000) (122d34'48.00"E, 2d 1'21.00"N)
Lower Left ( 122.5800000, -2.0025000) (122d34'48.00"E, 2d 0'9.00"S)
Upper Right ( 126.6025000, 2.0225000) (126d36'9.00"E, 2d 1'21.00"N)
Lower Right ( 126.6025000, -2.0025000) (126d36'9.00"E, 2d 0'9.00"S)
Center ( 124.5912500, 0.0100000) (124d35'28.50"E, 0d 0'36.00"N)

So instead of the requested 0.025 we get 0.02498447204969

---

Downloading with adjusted resolution

Similarly, and this is what triggered this question, if I change the resolution slightly (from 0.025 to 0.03) but keep the original bounding box and download with the command

curl "http://localhost:8001/geoserver-geonode-dev/ows?version=1.0.0&service=wcs&request=getcoverage&format=GeoTIFF&store=false&coverage=shakemap_20110505155015&crs=EPSG:4326&bbox=122.5775,-2.0025,126.6025,2.0225&resx=0.030000000000&resy=0.030000000000" > dnld.tif

gdal info reports

Origin = (122.577500000000001,2.022500000000000)
Pixel Size = (0.030037313432836,-0.030037313432836)

Corner Coordinates:
Upper Left ( 122.5775000, 2.0225000) (122d34'39.00"E, 2d 1'21.00"N)
Lower Left ( 122.5775000, -2.0025000) (122d34'39.00"E, 2d 0'9.00"S)
Upper Right ( 126.6025000, 2.0225000) (126d36'9.00"E, 2d 1'21.00"N)
Lower Right ( 126.6025000, -2.0025000) (126d36'9.00"E, 2d 0'9.00"S)
Center ( 124.5900000, 0.0100000) (124d35'24.00"E, 0d 0'36.00"N)

So instead of the requested 0.03 we get 0.030037313432836

[uniomni]

It was agreed to pass this one on to Andrea Aime at Geosolutions for his assessment.

[uniomni]

The errors in bounding box are also reproduced by uncommenting this line:
https://github.com/AIFDR/riab/blob/master/impact/tests/test_geonode_operations.py#L84

[uniomni]

I reckon this is linked to issue #173

[uniomni]

I observed today another manifestation of this with a hazard raster layer in geographic WGS84 and a population raster layer in WGS84/UTM. Although, both are downloaded with the exact same bounding box and resolution, the number of rows (and probably also columns) differ significantly. This may be linked also to issue #40

Log output:

INFO 2011-11-27 19:47:04,994 views 24620 140460483467008 Performing requested calculation
INFO 2011-11-27 19:47:04,994 views 24620 140460483467008 - Downloading layer geonode:population_jakarta_desa_100m2 from http://localhost:8001/geoserver-geonode-dev/ows with bbox=[106.68597429495, -6.3734208271402997, 106.97391349598809, -6.0798857871831737] and res=(0.00045228819716043578, 0.00045228819716044055)
INFO 2011-11-27 19:47:05,137 views 24620 140460483467008 - Downloading layer geonode:current_flood_depth_jakarta from http://localhost:8001/geoserver-geonode-dev/ows with bbox=[106.68597429495, -6.3734208271402997, 106.97391349598809, -6.0798857871831737] and res=(0.00045228819716043578, 0.00045228819716044055)
INFO 2011-11-27 19:47:05,361 views 24620 140460483467008 - Downloading layer geonode:female_pct_jakarta_desa_100m2 from http://localhost:8001/geoserver-geonode-dev/ows with bbox=[106.68597429495, -6.3734208271402997, 106.97391349598809, -6.0798857871831737] and res=(0.00045228819716043578, 0.00045228819716044055)
INFO 2011-11-27 19:47:05,495 views 24620 140460483467008 - Calculating impact using <class 'impact.plugins.flood.HKV_flood_study.FloodImpactFunction'>
ERROR 2011-11-27 19:47:05,523 views 24620 140460483467008 Rasters are not aligned!
Raster Population_Density_Jakarta has 653 rows but raster Flood_Depth_(current)_Jakarta has 649 rows
Refer to issue #102

[uniomni]

This happens regularly....