Fwd: [gdal-dev] problem with decimal precision (SAGA driver)

[Even Rouault]

Selon Volker Wichmann <wichmann at laserdata.at>:

Well, is this really a problem... ? I mean 12181.299999999999 = 12181.3 for most
purposes. Sometimes you can have different decimal representations for the same
IEEE number... I'm not sure this is really something adressed in GDAL drivers.

But if you are really annoyed with this, you could look at OGRFormatDouble()
(ogr/ogrutils.cpp) that has some ugly and fragile (needed tweaking because MSVC
or GCC don't behave the same when printing a floating point number) logic to
detect and remove trailing 999999x or 000000x. It is used when outputting
coordinates into WKT, GML or KML.

> Hi Even,
>
> since you helped so much to implement the SAGA driver, I'm writing to
> you directly (I got no reply on the mailing list yet). Do you have an
> idea on how to circumvent this problem?
>
> Thanks,
> Volker
>
>
>
>
> -------- Original Message --------
> Subject: 	[gdal-dev] problem with decimal precision (SAGA driver)
> Date: 	Mon, 04 Apr 2011 15:11:21 +0200
> From: 	Volker Wichmann <Volker.Wichmann at uibk.ac.at>
> To: 	gdal-dev <gdal-dev at lists.osgeo.org>
>
>
> Hi,
>
> we encountered a problem with decimal precision when converting a SAGA
> grid to ESRI ASCII.
>
> I expect the problem arising from ASCII to double conversion by atof()
> and/or from the Geotransform (pixel as point to pixel as area).
>
> The SAGA header looks like
>
> POSITION_XMIN   = 12181.8000000000
> POSITION_YMIN   = 219184.8800000000
> CELLSIZE        = 1.0000000000
>
> The final ESRI ASCII header looks like
>
> xllcorner    12181.299999999999
> yllcorner    219184.380000000005
>
> instead of
> xllcorner    12181.3
> yllcorner    219184.38
>
> How is this problem handled in other drivers (using strtod(),
> stringstream, ...)?
>
> The relevant lines of code in sagadataset.cpp
> (http://trac.osgeo.org/gdal/browser/trunk/gdal/frmts/saga/sagadataset.cpp)
> are:
>
> 406            dXmin = atof(papszTokens[1]);
> 408            dYmin = atof(papszTokens[1]);
> 410            dCellsize = atof(papszTokens[1]);
>
> 601        padfGeoTransform[0] = poGRB->m_Xmin - poGRB->m_Cellsize / 2;
> 602        padfGeoTransform[3] = poGRB->m_Ymin + (nRasterYSize - 1) *
> poGRB->m_Cellsize + poGRB->m_Cellsize / 2;
>
>
>
> Thanks,
> Volker
>
>
>