[Geoserver-devel] GeoServer's accuracy when using WCS and Geotiffs.

Hello list,

We recently hit a roadblock while writing unit tests for an
application that uploads data to GeoServer, the problem we
encountered was that there were important differences between the data
uploaded to GS and then downloaded via WCS.

Specifically:
The bounding box by something in the order of 10%
The number of rows and columns of the array (i.e. the shape) by +/- 1.
This means that the original array cannot be compared directly to the
downloaded array as they are not aligned.
The origin and pixel size by a few % (This means that the
georeferencing of the grid is changed)
The grid values themselves are also not exact showing some quite large
spikes in some places although viewing the TIF files (before and after
passing through GeoServer) shows that they are overall qualitatively
similar.

I submitted a bug report [1], but I am raising the issue here to get
input from people familiar with the WCS codebase, first to verify if
it's a real limitation in GeoServer, and second to ask for pointers
about places in the code to inspect for possible optimizations.

Thanks in Advance,
Ariel Núñez

[1] http://jira.codehaus.org/browse/GEOS-4372

On Fri, Feb 11, 2011 at 9:40 PM, Ariel Nunez <ingenieroariel@anonymised.com> wrote:

Hello list,

We recently hit a roadblock while writing unit tests for an
application that uploads data to GeoServer, the problem we
encountered was that there were important differences between the data
uploaded to GS and then downloaded via WCS.

Specifically:
The bounding box by something in the order of 10%
The number of rows and columns of the array (i.e. the shape) by +/- 1.
This means that the original array cannot be compared directly to the
downloaded array as they are not aligned.
The origin and pixel size by a few % (This means that the
georeferencing of the grid is changed)
The grid values themselves are also not exact showing some quite large
spikes in some places although viewing the TIF files (before and after
passing through GeoServer) shows that they are overall qualitatively
similar.

I submitted a bug report [1], but I am raising the issue here to get
input from people familiar with the WCS codebase, first to verify if
it's a real limitation in GeoServer, and second to ask for pointers
about places in the code to inspect for possible optimizations.

For sure one of the differences is the half a pixel shift that happens
because of the different pixel interpretation (area vs point, OGC mandates
point, GDAL uses area). That is a GDAL bug that has been fixed in 1.8.0:
http://trac.osgeo.org/gdal/wiki/rfc33_gtiff_pixelispoint

The issue with the different number of pixels might be of different nature,
but WCS on 2.0.x won't be touched anymore since the code base on 2.1.x
is quite a bit different (making any back port an expensive time sink)
so I suggest you first try out 2.1RC1 and eventually update the bug
report with your findings

Cheers
Andrea

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 333 8128928

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-------------------------------------------------------

Andrea,

Thanks for your suggestion, the situation in trunk is much better (I
will have to check if 2.1.x works for me too, but since it got
branched just a bit ago I am very positive about that). I reported the
new findings and the script I am using to reproduce it on the issue
tracker [1] and I am glad to report it seems to be much more accurate
and although it can be improved, it may be enough for our application
now.

Thanks,
Ariel

[1] http://jira.codehaus.org/browse/GEOS-4372