search

AIFDR / riab

Risk in a Box - main project
Other
17 stars 6 forks source link

Accuracy of Geoserver resolution #102

Open uniomni opened 13 years ago

uniomni commented 13 years ago

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 commented 13 years ago

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

uniomni commented 13 years ago

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 commented 12 years ago

I reckon this is linked to issue #173

uniomni commented 12 years ago

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 https://github.com/AIFDR/riab/issues/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 FloodDepth(current)_Jakarta has 649 rows Refer to issue #102

uniomni commented 12 years ago

This happens regularly....