Selon Volker Wichmann <wichm...@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.wichm...@uibk.ac.at> > To: gdal-dev <gdal-dev@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 > > > _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev