Hi, I restored DECIMAL_PRECISION and added SIGNIFICANT_DIGIT and also reformatted the NODATA_value, although that may or may not be correct as per Even's remarks. See:
http://trac.osgeo.org/gdal/ticket/3732 for a review. On Mon, Mar 10, 2014 at 1:21 PM, Even Rouault <even.roua...@mines-paris.org> wrote: > Le lundi 10 mars 2014 18:55:36, Jonathan Moules a écrit : >> Hi Etienne, >> I was looking for something like that but the >> http://www.gdal.org/frmt_gtiff.html page didn't list it explicitly. >> >> That said, looking at the gdalinfo now (a little late) I see that it's >> already defaulting to Float32. I also tested with the "-ot Float32" >> arguement, but there was no change. I'm counting 16 significant figures; I >> only want 5 or 6. > > TIFF stores floating point values as IEEE754 floats. Talking about significant > figures doesn't make much sense. You could test using Float64 with the hope > that 50.597 can be exactly represented as a Float64. Otherwise you'll have to > do the rounding when reading back from TIFF. > >> >> Cheers, >> Jonathan >> >> On 10 March 2014 17:49, Etienne Tourigny <etourigny....@gmail.com> wrote: >> > 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 > > -- > Geospatial professional services > http://even.rouault.free.fr/services.html > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Kyle _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
