[OSGeo-Discuss] WCS/WMS accuracy tests?

Wed Dec 9 05:03:31 PST 2009

Hi all,

I've finished my tests.
The conclusion:
Geoserver has a bug which offsets all the results by half a pixel, this is a known issue with the definition of the location of a pixel. Added to this there’s the no-data border which appears with non-native, non-multiple requests. I presume that will be gone once the pixel issue is resolved.

Mapserver doesn’t offset the data unless it is physically impossible (non-native, non-multiple resolutions, extents which don’t snap to source data) but produces a multi-band geotiff where the source data is single band.

Deegree has a bug which offsets some of the results, but I don’t know what causes it and although it is resolution-related I don’t see a pattern. It also produces a multi-band geotiff instead of a single band.

The full report can be found at:
http://blog.minst.net/2009/12/09/perceived-wcs-inaccuracy (slow site warning)

The issue for Geoserver can be found at http://jira.codehaus.org/browse/GEOS-3702
The issue for Deegree can be found at http://wald.intevation.org/tracker/index.php?func=detail&aid=1216&group_id=27&atid=212
For mapserver I didn't file a bug since I'm not entirely sure if the GeoTiff multi-band image is me or mapserver and I didn't inverstigate it any further.

If there are any questions or remarks let me know

regards,
Steven

On Dec 8, 2009, at 9:31 AM, Judit Mays wrote:

> Hello Steven,
> 
> the deegree crowd would also be interested in a description of your test
> cases and the results. If you could send an email either here or,
> preferably, to the deegree developer list [1], this would be much
> appreciated.
> I talked to one of the main deegree WMS developers and he told me that
> deegree-wms passes all the OGC CITE tests of CITE 1.3.0, and that there
> are specific tests which check whether the returned tiff contains the
> expected pixels. So it would indeed be interesting to see, what is
> different in your tests to cause the offset.
> 
> Kind regards,
> Judit
> 
> [1] deegree-devel at lists.sourceforge.net | register at:
> https://lists.sourceforge.net/lists/listinfo/deegree-devel
> 
> Steven M. Ottens schrieb:
>> On Dec 7, 2009, at 7:04 PM, Frank Warmerdam wrote:
>> 
>>> Steven M. Ottens wrote:
>>>> On Dec 7, 2009, at 6:48 PM, Frank Warmerdam wrote:
>>>>> Steven M. Ottens wrote:
>>>>>> Hi all, Working with Geoserver as a WCS we discovered that requesting a
>>>>>> GeoTIFF in the same projection as the original GeoTIFF produces a
>>>>>> shifted dataset. (http://jira.codehaus.org/browse/GEOS-3702) The shift
>>>>>> is small, less than one pixel of the original dataset, but with a coarse
>>>>>> dataset of 100m/pixel it can be 70meters. The Geoserver people are aware
>>>>>> of the problem and at some point in time will fix it I'm sure, but it
>>>>>> prompted me to test other OSS WCS servers (mapserver and deegree). Both
>>>>>> of them showed a shift of the data as well. Deegree has about the same
>>>>>> error as Geoserver, while Mapserver does a better job but is still off. I know there have been speed tests between different WMS services, but
>>>>>> I'm wondering has there been any data-quality/accuracy test been done
>>>>>> between WMS and/or WCS services?
>>>>> Steven,
>>>>> I would appreciate your filing a detailed ticket on this issue against MapServer.  Please be specific about the exact request made, provide the data and mapfile, and explain why you think the results are wrong.
>>>> Will do once the tests are completed. Currently we overlay the original
>>>> GeoTiff with the result of the request in QGIS. Other ways of testing are
>>>> welcome. (I was thinking gdal-info output, overlay in uDig and ArcMap to
>>>> rule out bias of QGIS)
>>> Steve,
>>> 
>>> Are you requesting the data at greater than the natural resolution of the
>>> image?  Is it the DescribeCoverage extent details that are wrong?  If
>>> you request the imagery supersampled (at higher resolution than the underlying
>>> image) then there is a known issue with MapServer that can be fixed by
>>> setting adding the following line to the LAYER at some cost in processing
>>> speed:
>>> 
>> I will test both the same resolution and a greater resolution to be sure. Currently we request a greater resolution since that's what we need.
>> 
>>> PROCESSING "RESAMPLE=NEAREST"
>>> 
>> I discovered that already and included it in my mapfile. The trouble is that the image from Mapserver (and the other services) is shifted to the South East. I only did a quick test before the office closed so the exact shift is still to be determined, but it was noticeable smaller than with Geoserver and Deegree. 
>> For Geoserver we tested it both by defining a resolution of the output image and with a width and height with the same BBOX. For Mapserver I only tried the resolution request (&resx=#&resy=#)
>> 
>>> If that is the issue then a ticket might still be appropriate, but I will
>>> take a different approach which is to force use of the more precise resampler
>>> when any raster draw request is made at supersampled resolution.
>>> 
>>> Best regards,
>>> -- 
>>> ---------------------------------------+--------------------------------------
>>> I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
>>> light and sound - activate the windows | http://pobox.com/~warmerdam
>>> and watch the world go round - Rush    | Geospatial Programmer for Rent
>>> 
>>> 
> 
> -- 
> Judit Mays
> l a t / l o n  GmbH
> Aennchenstrasse 19               53177 Bonn, Germany
> phone ++49 +228 18496-0          fax ++49 +228 18496-29
> http://www.lat-lon.de            http://www.deegree.org
> 
> _______________________________________________
> Discuss mailing list
> Discuss at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/discuss