[WMS] Problem with BBOX precision

[dmorissette]

On May 24, 2004, at 4:40 AM, Jean-Henry Berevoescu wrote:
>
> Hi,
> I am experiencing a problem in the WMS module and I wonder
> if there is are others who know about it.
> Accessing MMS as a WMS Server the request gets parsed in
> mapwms.c: msWMSLoadGetMapParams(...)
>
> ....
>      map->extent.minx = atof(tokens[0]);
>      map->extent.miny = atof(tokens[1]);
>      map->extent.maxx = atof(tokens[2]);
>      map->extent.maxy = atof(tokens[3]);
> ....
>
> I send the WMS request with a BBOX having 10-11 digits after the decimal
> points for the coordinates. Just before this part of the code I added a log
> print and the BBOX coordinates are still all right (altough still as strings)
> Doing the same with the value that get into the "extent", I get all the
> coordinates truncated to 6 digits after the decimal point. It is as if
> a double gets downsized to a float.
> The extent structure has doubles so the problem is not that.
> I also tried to replace "atof" with calls to strod or sscanf and the
> results are identical.
>
> Thanks in advance for any insights on how to solve this problem.
>
> Jean 



Sean Gillies wrote:
> 11 decimal places? What are you doing, Dermatology?
> Did you try strtold (long double)?
>
> According to my standard C library (on BSD), atof is not thread safe
> and has been deprecated in favor of strtod. That was news to me. No
> mention of deprecation on my Linux system (RH9).
>
> Sean


Jean-Henry Berevoescu wrote:
> 
> For one: I see a problem with this when I try to align 6' (or less)
> imagery with a layer of vectors (streets for example).
> 
> And yes, I tried strtold too (when I tried the lesser strtod).
> (I run on Mandrake 10 - but I don't think that should be an
> issue. After all Mandrake is a Linux and it originally started
> as an RH clone)
> 
> Jean
>

[dmorissette]

I'm not sure what to suggest, even K&R (the ultimate C reference) says that
atof() should return a double:

  double atof(const char *s)
      atof converts s to double; it is equivalent to
      strtod(s, (char**)NULL).

Jean, could you please add yourself to the CC of the bug, and add an example of
a GetMap request (at least the BBOX part) where the digits are truncated...

[dmorissette]

The following C program shows that atof() maintains the same number of digits of
precision as a double value hardcoded in the source, that is 17 digits of
precision on RH9:

v1=1234567890.12345671653747558594, v2=1234567890.12345671653747558594,
v1-v2=0.00000000000000000000


#include <stdlib.h>
#include <stdio.h>

int main()
{
    double v1, v2;

    v1 = 1234567890.1234567890123456;
    v2 = atof("1234567890.1234567890123456");

    printf("v1=%.20lf, v2=%.20lf, v1-v2=%.20lf\n", v1, v2, v1-v2);

    return 0;
}

[dmorissette]

Jean-Henry Berevoescu wrote:
>>
> Tested this and you are right. The problem is indeed in the way the URL 
> string
> is built for the WMS Layer access and not as I said, in the parsing (I 
> actually
> added logging in the parsing that was similar to the way the URL was 
> built, therefore
> the confusion).
> The bug still is, as you note, in the WMS Layer URL construction and for 
> now I have
> modified my MMS code to do "%.12lf" instead of just "%f".
> 
> Jean

[assefa]

%lf should be enough ? The change will only affect bbox values in 
msBuildWMSLayerURL and msBuildWFSLayerGetURL

[dmorissette]

I'm not sure that %lf will give us enough digits on all platforms, but you could
test that if you want. What we need is a way to guarantee that we use 17
significant digits all the time which is more or less the precision of a double.
After a few tests on Linux, it seems that "%.17g" (or %15g) would be the way to go:

    printf("%.15g\n", 1234.12345678901234);
1234.12345678901

    printf("%.15g\n", 1234567890.12345678901234);
1234567890.12346

[assefa]

Used "%.17g" for bbox values in mapwmlayer.c mapwfslayer.c.