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-de...@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, >>> warmer...@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@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/discuss _______________________________________________ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss