WCS Coverage Description Numeric Precision

[warmerdam]

Steve,

I think that there is a bug in the MapServer code that generates
responses to the DescribeCoverage request.  These are excerpts from the
demo.map file that you are using (and that we downloaded and are using
locally for testing our WCS client):

-----------------------------------------------
MAP
...
 EXTENT 159707.000000 4597395.000000 1400707.000000 5501395.000000 ...
 LAYER
   NAME "ndvi"
...
   METADATA
...
     ows_extent "159707 4597895 1400207 5501395"
     wcs_resolution "500.0 500.0"
...
 LAYER
   NAME "fpar"
...
   METADATA
...
     ows_extent "159707 4597895 1400207 5501395"
     wcs_resolution "1000.0 1000.0"
...
 LAYER
   NAME "modis"
...
   METADATA
...
     ows_extent "159707 4597895 1400207 5501395"
     wcs_resolution "500.0 500.0"
...
-----------------------------------------------

So, everything has an extents of "159707 4597895 1400207 5501395".  Now
here is an excerpt from the DescribeCoverage response for the "ndvi"
layer, from your server:

http://maps.dnr.state.mn.us/cgi-bin/mapserv43?map=/usr/local/www/docs/ma
pserver_demos/wcs/demo.map&service=WCS&version=1.0.0&request=DescribeCov
erage&coverage=ndvi

-----------------------------------------------
<CoverageDescription ...>
...
   <gml:Envelope srsName="EPSG:26915">
       <gml:pos>159707 4.5979e+06</gml:pos>
       <gml:pos>1.40021e+06 5.5014e+06</gml:pos>
   </gml:Envelope>
...
   <gml:origin>
       <gml:pos>159707 5.5014e+06</gml:pos>
   </gml:origin>

-----------------------------------------------

The problem is that the <gml:pos> element contents are all printf-d with
"%g", which, by default, only has 6 digits of decimal precision.  So
"5501395" in demo.map becomes "5.5014e+06" which is parsed by us as
"5501400".  The result is a mis-match between the <gml:Envelope>, the
<gml:GridEnvelope> (size in pixels) and the <gml:offsetVector> (size of
a pixel).

I've checked the 4.4.0, 4.4.1, and nightly build code, and they are all
using "%g" where "%.15g" might be more appropriate.  "grep \.[0-9]g *.c"
on the MapServer code shows some fairly exciting results, including the
first "%.17g" that I have ever seen!  It is a close contest between
those and the plain "%g"-s:

"grep \.[0-9]g *.c | wc -l" ----> 41
"grep %g *.c | wc -l" ----> 50

Also, "fpar" layer in demo.map file has ows_extent-s that, when divided
by the wcs_resolution-s, do not give an integer result.  Is that
deliberate?

Regards,
Martin


...

I may be to blame for the "%.17g"-s, or some of them anyway. What's the
problem with them? Is it that I should have known that doubles only
provide 15 digits of precision? I knew it was somewhere in the 15-17
digits range, but I didn't do much research before using "%.17g".

Daniel

...

Guys,

The typical format string to preserve essentially all "real" precision in
a double is %.15g.   The problem with %.17g is that it can end up 
reporting meaningless noise beyond the real precision of the double. 

I would agree with Martin that we should be using %.15g essentially
everywhere we use %g. 

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent

[sdlime]

What do we want to do with geographic coordinates? %.15g gives you a heck of a
lot of decimal places when the lat/lon bbox is computed (which is often). I've
committed (4.5) mapwcs.c with %.15g replacing all %g. Will not close yet though...

Steve 

[dmorissette]

You are talking about the <LatLonBoundingBox> element in capabilities, right?
It's nearly impossible to know how many digits to use without knowing the
precision of the data we're dealing with. Since we have no way to make a smart
decision on the numer of digits at runtime, it seems to me that the only option
is to go with full precision all the time? Does anyone have a better suggestion?

BTW, did you also replace all the %.17g-s with %.15g-s?

[sdlime]

> BTW, did you also replace all the %.17g-s with %.15g-s?

Yup, just got 'em. Marking this as fixed for now. However, Martin had a question
about exact computations with extent and resolution. That should be filed as a
seperate issue.

Steve