[deegree-devel] Fwd: [OSGeo-Discuss] WCS/WMS accuracy tests?
Judit Mays
mays at lat-lon.de
Fri Dec 11 03:06:58 PST 2009
Dear Steven,
thank you very much for the good work you put into the WCS testing.
I have already talked to some of the other deegree developers, but as
they are all extremely busy at the moment, they did not find the time
yet to follow up on your test scenario and see what the reasons are for
the deegree2.3-rc1 WCS behaviour. I am not sure yet that it should be
called a bug, but if it is, we will see to get it fixed eventually.
I will make sure to let you know about the outcome.
Info for the deegree-devel list readers:
The full thread on OSGeo-discuss may be found here:
http://lists.osgeo.org/pipermail/discuss/2009-December/006442.html
Steve's test scenario outcome is posted in this blog:
http://blog.minst.net/2009/12/09/perceived-wcs-inaccuracy
Kind regards,
Judit
Steven M. Ottens schrieb:
> as requested by Judit Mays
>
> A slight update since this mail was sent to the OSGeo list: According to the Geoserver people their behavior is correct and Mapserver and QGIS might be wrong, see http://jira.codehaus.org/browse/GEOS-3702
>
> This leaves the difference between deegree-wcs and both Geoserver and Mapserver to your discretion.
>
> Regards,
> Steven
>
> Begin forwarded message:
>
>> From: "Steven M. Ottens" <steven at minst.net>
>> Date: December 9, 2009 2:03:31 PM GMT+01:00
>> To: OSGeo Discussions <discuss at lists.osgeo.org>
>> Subject: Re: [OSGeo-Discuss] WCS/WMS accuracy tests?
>> Reply-To: OSGeo Discussions <discuss at lists.osgeo.org>
>>
>> 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
>>
>> _______________________________________________
>> Discuss mailing list
>> Discuss at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/discuss
>
--
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
URL: <http://lists.osgeo.org/pipermail/discuss/attachments/20091211/cf3f64b1/attachment.sig>
More information about the Discuss
mailing list