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" <[email protected]> > Data: 09 dicembre 2009 14.03.31 GMT+01.00 > A: OSGeo Discussions <[email protected]> > Oggetto: Re: [OSGeo-Discuss] WCS/WMS accuracy tests? > Rispondi a: OSGeo Discussions <[email protected]> > > 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] [email protected] | 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, >>>> [email protected] >>>> 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 >> [email protected] >> http://lists.osgeo.org/mailman/listinfo/discuss > > > _______________________________________________ > Discuss mailing list > [email protected] > http://lists.osgeo.org/mailman/listinfo/discuss
_______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [email protected] http://lists.faunalia.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it.
