Have you tried using a 36bit (float) instead of 64bit (double) output? double is usually the default output type and has more significant digits (~16) than your source, so it's representation is "ok" in double format
see [1] for an explanation on floating-point precision the following argument would do this "-ot Float32" [1] http://en.wikipedia.org/wiki/Floating_point Etienne On Mon, Mar 10, 2014 at 2:25 PM, Jonathan Moules < jonathanmou...@warwickshire.gov.uk> wrote: > Hi List, > Bringing back an old thread but with a slight change. > > I'm now trying to get GDAL to mosaic and export from the ASCII files to a > GeoTIFF. > But the GeoTIFF writer in GDAL is doing the exact same thing as the ASCII > writer was - it's taking *50.597* (source value) and converting it into > something like *50.596895342423*. > > I've tried using both gdal_merge and going via a VRT (gdalbuildvrt - > gdal_translate). The result is the same. > > I also tried the *DECIMAL_PRECISION* trick, but gdal informs me: > >> Warning 6: Driver GTiff does not support DECIMAL_PRECISION creation option > > > How do I get GDAL to merge these into a GeoTIFF without altering the data? > > Thanks, > Jonathan > > > On 24 January 2014 16:12, Jonathan Moules < > jonathanmou...@warwickshire.gov.uk> wrote: > >> Thanks Norman. I'd already seen that page but failed to read it! >> However, having tested it, it's not functioning as the manual says. >> >> As best I can tell, DECIMAL_PRECISION=3 should give me 3 decimal places. >> But what it instead does it give me 3 significant figures. So 98.354 has >> become 98.3. >> This becomes a problem because many of my heights are hovering around >> 100. So some will either have to be 1 character too long to ensure no data >> loss for the rest. >> >> Is this a bug? The documentation on the page linked to is quite clear it >> should be decimal places. >> >> Less of an issue, but it also didn't make any difference to: >> >>> xllcorner 432000.000000000000 >>> yllcorner 242000.000000000000 >>> cellsize 2.000000000000 >> >> >> GDAL 1.10.1, released 2013/08/26 >> >> >> Cheers, >> Jonathan >> >> >> >> >> On 24 January 2014 15:11, Norman Vine <n...@cape.com> wrote: >> >>> try >>> >>> gdal_translate -of AAIGrid -co DECIMAL_PRECISION=3 abc.vrt abc.asc >>> >>> see http://www.gdal.org/frmt_various.html >>> HTH >>> Norman >>> >>> On Jan 24, 2014, at 10:01 AM, Jonathan Moules < >>> jonathanmou...@warwickshire.gov.uk> wrote: >>> >>> Hi List, >>> I'm trying to mosaic some ASCII grid tiles into a single large ASCII >>> file (which can then easily be handled). >>> >>> I'm using this process: >>> >>>> REM Create list of files >>>> dir /b /s *.asc > asc_list.txt >>>> >>> >>> >>>> REM Turn into VRT >>>> gdalbuildvrt -srcnodata "-9999" -vrtnodata "0" -a_srs "EPSG:27700" >>>> -input_file_list "asc_list.txt" abc.vrt >>>> >>> >>> >>>> REM actual mosaicing >>>> gdal_translate -of AAIGrid abc.vrt abc.asc >>> >>> >>> The input files are like: >>> >>>> ncols 500 >>>> nrows 500 >>>> xllcorner 432000.000 >>>> yllcorner 243000.000 >>>> cellsize 2 >>>> nodata_value -9999.0 >>>> 98.354 98.449 98.658 98.874 99.038 99.096 >>> >>> >>> But the outputs are like: >>> >>> fncols 500 >>>> nrows 1000 >>>> xllcorner 432000.000000000000 >>>> yllcorner 242000.000000000000 >>>> cellsize 2.000000000000 >>>> NODATA_value 0 >>>> 98.353996276855469 98.448997497558594 98.657997131347656 >>>> 98.874000549316406 >>> >>> >>> Suddenly everything has a dozen extra decimal places. Not only does this >>> induce the False Precision problem (we don't have heights to the >>> femtometer!), it also massively increases the filesize. >>> >>> How can I get this to not happen? >>> >>> Thanks, >>> Jonathan >>> >>> >>> This transmission is intended for the named addressee(s) only and may >>> contain sensitive or protectively marked material up to RESTRICTED and >>> should be handled accordingly. Unless you are the named addressee (or >>> authorised to receive it for the addressee) you may not copy or use it, or >>> disclose it to anyone else. If you have received this transmission in error >>> please notify the sender immediately. All email traffic sent to or from us, >>> including without limitation all GCSX traffic, may be subject to recording >>> and/or monitoring in accordance with relevant legislation. >>> _______________________________________________ >>> gdal-dev mailing list >>> gdal-dev@lists.osgeo.org >>> http://lists.osgeo.org/mailman/listinfo/gdal-dev >>> >>> >>> >> > > This transmission is intended for the named addressee(s) only and may > contain sensitive or protectively marked material up to RESTRICTED and > should be handled accordingly. Unless you are the named addressee (or > authorised to receive it for the addressee) you may not copy or use it, or > disclose it to anyone else. If you have received this transmission in error > please notify the sender immediately. All email traffic sent to or from us, > including without limitation all GCSX traffic, may be subject to recording > and/or monitoring in accordance with relevant legislation. > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev >
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
