Opened 20 years ago
Closed 20 years ago
#678 closed defect (fixed)
[WMS] Problem with BBOX precision
Reported by: | dmorissette | Owned by: | mapserverbugs |
---|---|---|---|
Priority: | high | Milestone: | 4.4 release |
Component: | WMS Server | Version: | 4.2 |
Severity: | normal | Keywords: | |
Cc: |
Description
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 >
Change History (7)
comment:2 by , 20 years ago
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; }
comment:3 by , 20 years ago
Milestone: | → 4.4 release |
---|
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
comment:4 by , 20 years ago
Cc: | removed |
---|
comment:5 by , 20 years ago
%lf should be enough ? The change will only affect bbox values in msBuildWMSLayerURL and msBuildWFSLayerGetURL
comment:6 by , 20 years ago
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
comment:7 by , 20 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Used "%.17g" for bbox values in mapwmlayer.c mapwfslayer.c.
Note:
See TracTickets
for help on using tickets.