Re: [OSGeo-Discuss] WCS/WMS accuracy tests?
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
Re: [OSGeo-Discuss] WCS/WMS accuracy tests?
Steven M. Ottens wrote: 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. Ah hem, are you sure it's correct to call it a bug? My impression is that we are respecting the OGC specs to the letter and that, as it often happens, the real world is actually working differently, but I need to double check with Simone that dealt with this issue more in detail Cheers Andrea ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] WCS/WMS accuracy tests?
Ciao Steven, I think there has been a misunderstanding here. There is no known issue for GeoServer with repsect to the location of a pixel, we always try to adhere to the standards, expecially with geotiff where there is this area vs corner pixel placement. Of course we might be missing something inside our processing chain, but this is not due to a known issue. I am going to spend some time next week investigating your data and requests; btw, thanks for the detailed report on the GeoServer JIRA. Simone. On Wed, Dec 9, 2009 at 2:03 PM, Steven M. Ottens wrote: > 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=N
Re: [OSGeo-Discuss] WCS/WMS accuracy tests?
Steven M. Ottens wrote: 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. Steven, Thanks for the excellent post. I'd be interested in following up on the singleband / multiband issue with MapServer WCS when you have time. I vaguely recall there being an issue with this at one point but I thought it was solved quite a while ago. So if it persists in 5.6.0 I'd love a chance to fix it. Andrea Aime wrote: > Steven M. Ottens wrote: >> 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. > > Ah hem, are you sure it's correct to call it a bug? > My impression is that we are respecting the OGC specs to the letter and > that, as it often happens, the real world is actually working > differently, but I need to double check with Simone that dealt with > this issue more in detail Andrea / Simone, I have set myself to watch GEOS-3702. I'd like to be sure we all reach the same understanding of the specification. 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 ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] WCS/WMS accuracy tests?
On Dec 9, 2009, at 3:44 PM, Frank Warmerdam wrote: > Steven M. Ottens wrote: >> 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. > > Steven, > > Thanks for the excellent post. I'd be interested in following up on the > singleband / multiband issue with MapServer WCS when you have time. I > vaguely recall there being an issue with this at one point but I thought it > was solved quite a while ago. So if it persists in 5.6.0 I'd love a chance > to fix it. I'm happy to help, the map file and source data can be found here: http://dl.dropbox.com/u/175548/data.zip and the server itself is accessible through http://research.geodan.nl/cgi-bin/mapserver56/mapserv.exe?map=maps/corine.map&; If you need anything else let me know. Regards, Steven ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] WCS/WMS accuracy tests?
Steven M. Ottens wrote: On Dec 9, 2009, at 3:44 PM, Frank Warmerdam wrote: Steven M. Ottens wrote: 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. Steven, Thanks for the excellent post. I'd be interested in following up on the singleband / multiband issue with MapServer WCS when you have time. I vaguely recall there being an issue with this at one point but I thought it was solved quite a while ago. So if it persists in 5.6.0 I'd love a chance to fix it. I'm happy to help, the map file and source data can be found here: http://dl.dropbox.com/u/175548/data.zip and the server itself is accessible through http://research.geodan.nl/cgi-bin/mapserver56/mapserv.exe?map=maps/corine.map&; If you need anything else let me know. Steven, I believe you would want to change this: OUTPUTFORMAT NAME GTiff DRIVER "GDAL/GTiff" MIMETYPE "image/tiff" IMAGEMODE RGB EXTENSION "tif" END to: OUTPUTFORMAT NAME GTiff DRIVER "GDAL/GTiff" MIMETYPE "image/tiff" IMAGEMODE BYTE EXTENSION "tif" END IMAGEMODE RGB essentially tells MapServer to produce a normal 24bit RGB image result using the normal painting mechanisms. Using IMAGEMODE BYTE tells mapserver to produce a BYTE raster result and incidentally will match the number of bands to the source image. BYTE (and INT16 and FLOAT) are often more appropriate for WCS when you want to preserve original pixel values exactly rather than visually. 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 ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] WCS/WMS accuracy tests?
On Dec 9, 2009, at 6:02 PM, Frank Warmerdam wrote: >> > > Steven, > > I believe you would want to change this: > > OUTPUTFORMAT > NAME GTiff > DRIVER "GDAL/GTiff" > MIMETYPE "image/tiff" > IMAGEMODE RGB > EXTENSION "tif" > END > > to: > > > OUTPUTFORMAT > NAME GTiff > DRIVER "GDAL/GTiff" > MIMETYPE "image/tiff" > IMAGEMODE BYTE > EXTENSION "tif" > END Thanks, I figured it was a configuration issue, but didn't look into it, was busy testing something else ;) The change does fix the 'problem' and now I do get single band images. Regards, Steven ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
[OSGeo-Discuss] Re: Marketing Meeting 9/10-Dec
Hi all, just a general note to mention that in about an hour and a half the OSGeo Marketing Committee is meeting using IRC. All are welcome to stop by and comment on topics of discussion. This group has several opportunities for folks to help out in meaningful way (no programming required). You're welcome to email me directly with questions or ideas too. Info below... - Original Message - From: "Tyler Mitchell (OSGeo)" Date: Tuesday, December 8, 2009 7:32 pm Subject: [Marketing] Marketing Meeting 9/10-Dec To: market...@lists.osgeo.org > FYI - Marketing Meeting scheduled for this week! > > Timing: http://tinyurl.com/yzjbtmu > Agenda: http://wiki.osgeo.org/wiki/Marketing_Meeting_2009.12.10 > > If you can't make it, please let me know so we don't wait for > you :) > > Cc'ing Webcom just in case anyone there is also available to > share ideas about > the website related parts of the agenda, trying to pick up where > we left off > back in February meeting. I'll still ferry main points back to > Webcom of > course. > ___ > Marketing mailing list > market...@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/marketing > ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
