[MapServer-msautotest]bounding box rounding issue with wfs_filter.map in wxs

[nsavard@…]

There is a rounding issue on Windows in the calculation of the overall features
bounding box.  This happens when a WFS GetFeature request that includes some
filter parameters is performed (see below for the complete request).  The map is
wfs_filter.map in wxs directory.

This rounding error occurs with the following requests:
result\wfs_filter_greater_than_or_equalto.xml
result\wfs_filter_isbetween.xml
result\wfs_filter_isbetween_and_not_isequalto.xml
result\wfs_filter_isequalto_or_isequalto.xml
result\wfs_filter_isequalto_or_isequalto_reverse.xml
result\wfs_filter_isgreater_than.xml

Complete request:
# Verify PropertyIsGreaterThan
# RUN_PARMS: wfs_filter_isgreater_than.xml [MAPSERV] QUERY_STRING="map=[MAPFILE]
&SERVICE=WFS&VERSION=1.0.0&REQUEST=GetFeature&TYPENAME=popplace&FILTER=<Filter><
PropertyIsGreaterThan><PropertyName>POP_RANGE</PropertyName><Literal>3</Literal>
</PropertyIsGreaterThan></Filter>" > [RESULT]


Difference between Linux and Windows:

C:\proj\mapserver\msautotest\wxs>diff expected\wfs_filter_isgreater_than.xml res
ult\wfs_filter_isgreater_than.xml
14c14
<                       <gml:coordinates>2431943.750000,118985.382812 2587598.00
0000,404010.531250</gml:coordinates>
---
>                       <gml:coordinates>2431943.750000,118985.382813 2587598.00
0000,404010.531250</gml:coordinates>


Beginning of the response:

Content-type: text/xml

<?xml version='1.0' encoding="ISO-8859-1" ?>
<wfs:FeatureCollection
  xmlns:ms="http://mapserver.gis.umn.edu/mapserver"
  xmlns:wfs="http://www.opengis.net/wfs"
  xmlns:gml="http://www.opengis.net/gml"
  xmlns:ogc="http://www.opengis.net/ogc"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://www.opengis.net/wfs http://ogc.dmsolutions.ca/wfs/
1.0.0/WFS-basic.xsd
                      http://mapserver.gis.umn.edu/mapserver http://localhost/p
ath/to/wfs_simple?SERVICE=WFS&amp;VERSION=1.0.0&amp;REQUEST=DescribeFeatureType&
amp;TYPENAME=popplace&amp;OUTPUTFORMAT=XMLSCHEMA">
     <gml:boundedBy>
       <gml:Box srsName="EPSG:4269">
               <gml:coordinates>2431943.750000,118985.382813 2587598.000000,404
010.531250</gml:coordinates>
       </gml:Box>
     </gml:boundedBy>
  ...

[nsavard@…]

Assefa's comment(translated from French): 

Code that output the bounding box :
  msIO_fprintf(stream, "%.6f,%.6f %.6f,%.6f", rect->minx, rect->miny,
rect->maxx, rect->maxy ); (in mapgml.c gmlWriteBounds_GML2 or gmlWriteBounds_GML3)

Definition of msIO_printf is in mapio.c.  This function uses vsprintf on Windows
and vsnprintf on Linux.

Tests to be done:
  -make sure where this error occurs.  Is it really in the msIO_fPrintf
function?  If you modify msIO_fprintf(stream, "%f,%f %f,%f", rect->minx,
rect->miny, rect->maxx, rect->maxy ); code, do you get the same result? (or just
change %.6f to %.7 to see the value used for rounding).

[nsavard@…]

Re:  comment #1:

I modified the code as suggested by Assefa and I ran the test again.  The
results appear below.

In short onn Linux:

if decimal number is >= 6 => preceding decimal number is rounded upward
if decimal number is <= 5 => preceding decimal number is kept as is.

On Windows:
Same rules applied but there is a special case when the decimal number equal
exactly 5.  Some time the preceding decimal number is rounded sometime it is not.

For example 118985.3828125 on Windows becomes 118985.382813 but -60.2149635
becomes -60.214963.

I found something on Google that may explain this situation: 
http://support.microsoft.com/kb/184234


----------------------
diff between expected result and actual result with modified code on Linux:
[testsuite@manwe wxs]$ diff expected/wfs_filter_isgreater_than.xml
result/wfs_filter_isgreater_than.xml
14c14
<                       <gml:coordinates>2431943.750000,118985.382812
2587598.000000,404010.531250</gml:coordinates>
---
>                       <gml:coordinates>2431943.7500000,118985.3828125
2587598.0000000,404010.5312500</gml:coordinates>
21c21
<                       <gml:coordinates>-60.214963,46.123322
-60.214963,46.123322</gml:coordinates>
---
>                       <gml:coordinates>-60.2149635,46.1233220
-60.2149635,46.1233220</gml:coordinates>
52c52
<                       <gml:coordinates>-63.570040,44.682792
-63.570040,44.682792</gml:coordinates>
---
>                       <gml:coordinates>-63.5700399,44.6827916
-63.5700399,44.6827916</gml:coordinates>
83c83
<                       <gml:coordinates>-63.692011,44.615583
-63.692011,44.615583</gml:coordinates>
---
>                       <gml:coordinates>-63.6920113,44.6155826
-63.6920113,44.6155826</gml:coordinates>


diff between expected result and actual result on Windows (code not changed):
C:\proj\mapserver\msautotest\wxs>diff expected\wfs_filter_isgreater_than.xml res
ult\wfs_filter_isgreater_than.xml
14c14
<                       <gml:coordinates>2431943.750000,118985.382812 2587598.00
0000,404010.531250</gml:coordinates>
---
>                       <gml:coordinates>2431943.750000,118985.382813 2587598.00
0000,404010.531250</gml:coordinates>

[nsavard@…]

I suggest to process the actual result files to remove the last decimal number
on every floating point numbers.  We could do that on every files that do not
need demime operation (see below).  What do you think?

Something like that:

            if demime:
                demime_file( 'result/'+out_file )
            else:
                trunk_one_decimal( 'result/'+out_file )

            ...

###############################################################################
# Do windows number of decimal truncation.

def trunk_one_decimal( filename ):
    import re
    
    data = open(filename,'rb').read()

    numbers_found = re.compile('[0-9]+\.[0-9]{6}', re.M)

    start = 0
    new_data = ''
    for number in numbers_found.finditer(data):
        #print "coordinates = " + number.group()
        #print "coordinates start = " + str(number.start())
        #print "coordinates end = " + str(number.end())
        end = number.end() - 1
        new_data = new_data + data[start:end] 
        start = number.end()

    if new_data != '':
        new_data = new_data + data[start:] 


    if new_data != '' and new_data != data:
        open(filename,'wb').write(new_data)
      

    return

[nsavard]

Frank, how should I handle this particular case on Windows within the msautotest?

[warmerdam]

Norm,

Two approaches come to mind. One is a mechanism where for some tests we can have multiple acceptable results. The other is to roll out your number trimmer. I'm inclined to do the number trimmer but to make it so that RESULT_ can be followed by one or more modifiers (DEMIME, DEVERSION and TRIMDECIMAL). I'll go ahead and apply your decimal truncator in this fashion and let you know when it is complete.

[warmerdam]

Norm,

On review, I see that "fixexponent" is already applied to any RESULT_DEVERSION document, so I just added the truncate_one_decimal() method in that case. The change to mstestlib.py is committed. Can you try it out and see if it is working properly?

[nsavard]

Replying to warmerdam:

Norm,

On review, I see that "fixexponent" is already applied to any RESULT_DEVERSION document, so I just added the truncate_one_decimal() method in that case. The change to mstestlib.py is committed. Can you try it out and see if it is working properly?

Frank,

It works. Thanks.

[tomkralidis]

Bump. Update on this one?

[warmerdam]

This appears to no longer be a problem.