[Gfoss] Fwd: [OSGeo-Discuss] WCS/WMS accuracy tests?

Mer 9 Dic 2009 14:58:57 CET

come da titolo : Test di accuratezza su wcs/wms 

http://blog.minst.net/2009/12/09/perceived-wcs-inaccuracy

Inizio messaggio inoltrato:

> Da: "Steven M. Ottens" <steven a minst.net>
> Data: 09 dicembre 2009 14.03.31 GMT+01.00
> A: OSGeo Discussions <discuss a lists.osgeo.org>
> Oggetto: Re: [OSGeo-Discuss] WCS/WMS accuracy tests?
> Rispondi a: OSGeo Discussions <discuss a 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 a 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 a 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 a lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/discuss
> 
> 
> _______________________________________________
> Discuss mailing list
> Discuss a lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/discuss

-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.faunalia.it/pipermail/gfoss/attachments/20091209/6caa3a52/attachment.htm>