problem with units in mapserver
Ben Tuttle
funkbucket at GMAIL.COM
Wed Nov 15 13:42:30 PST 2006
Hi Frank-
First off thanks for your interest. I've still been spending a lot of
time looking at this and I think I understand what is happening now.
Perhaps you could go through my reasoning (and look at my server if
you like) and see if you agree or if you have an alternate
explanation. So to recap we have a near gloabl 30 arcsecond dataset
(-180 to 180 and -65 to 65). We want to output Geotiffs using WCS. So
if I run gdalinfo on the original image (I have it in both geotiff and
ENVI format) I get Pixel Size = (0.00833333,-0.00833333), for both the
geotiff and the ENVI file. When I make a WCS request using
resx=0.00833333 and resy=0.00833333 the output image returned by
mapserver does not register correctly and gdalinfo returns Pixel Size
= (0.00836820,-0.00836820). You can see an example of this at:
http://67.172.150.199/cgi-bin/mapserv?map=/data/dmsp4.map&SERVICE=WCS&REQUEST=GetCoverage&Coverage=F152003_tiff&STYLES=&CRS=EPSG:4326&BBOX=-119,33,-117,35&resx=0.00833333&resy=0.00833333&Format=geotiff
Additionally, the returned image is 240x240 pixels.
So the issue I was trying to explain was why does the pixel size
change (By the way, the geotiff does not have a world file, it has an
internal header).
If I crop the original image to -119,33,-117,35 in IDL using seconds
instead of degrees I get back an image that is 241x241 pixels and
matches the original data exactly. If I use GDAL to crop the image to
-119,33,-117,35 I get back an image that is 240x240 and matches the
orginal data exactly. The explanation for the difference in pixel size
is that IDL routine we use is inclusive when dealing with the last
line in the bounding box and GDAL is not. So the coordinates are
correct in both, but IDL has one additional line on the east and south
of the image while GDAL does not.
Mapserver seems to use a third logic. It tries to use 240x240 and be
inclusive of all the pixels in the bounding box, which leads to the
241 pixels being squished into 240 pixels.
Once we noticed this we tried using width=241 and height=241 instead
of resx resy and got back an image that matched our original data
exactly. You can see a sample of this at:
http://67.172.150.199/cgi-bin/mapserv?map=/data/dmsp4.map&SERVICE=WCS&REQUEST=GetCoverage&Coverage=F152003_tiff&STYLES=&CRS=EPSG:4326&BBOX=-119,33,-117,35&width=241&height=241&Format=geotiff
I have put crops of the original data to 240x240 and 241x241 that
match the above requests at: ftp://ftp.ngdc.noaa.gov/DMSP/test
in case you would like to compare for yourself. I'd also be happy to
make the whole image or other subsets available. So if this is correct
my question would be is this a bug or a feature. If you don't think it
is correct do you have any other thoughts? Thanks again for your help
and interest.
On 11/14/06, Frank Warmerdam <warmerdam at pobox.com> wrote:
> Ben Tuttle wrote:
> > Hi-
> > I have a a near global 30 arcsecond dataset I would like to serve
> > through WMS and WCS. However, it seems that no matter what I try it is
> > being dealt with in degrees (0.00833333) and not seconds. Is there a
> > way to specify seconds in the mapfile are use gdal to do this? I
> > notice in the mapfile reference that seconds is not an option for
> > Units. The problem I am having with using degrees is serious rounding
> > errors in the pixel sizes of the returned images. It seems that
> > mapserver is doing a string to float conversion on 0.0833333 and then
> > doing math with that float and this is causing the output image to
> > have incorrect pixel sizes. It seems that if I could use seconds
> > (which would mean I'd have a round number for my units instead of a
> > repeating decimal) that this problem would be solved. I haven't found
> > a way to do this though.
>
> Ben,
>
> There is no way to operate in arcseconds with mapserver - sorry.
>
> I'd be interested in knowing more about what is getting rounded
> improperly, and how you are specifying the values. Are you using
> a world file? Is it the DescribeCoverage that is coming back
> rounded improperly?
>
> 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 | President OSGeo, http://osgeo.org
>
More information about the MapServer-users
mailing list