[gdal-dev] Extra Decimal places added to ASCII gdal_translate mosaic

Mon Mar 10 12:46:20 PDT 2014

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.rouault at 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.dev at 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 <
>> >
>> > jonathanmoules at 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 <
>> >>
>> >> jonathanmoules at 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 <nhv at 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 <
>> >>>> jonathanmoules at 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 at 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 at 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 at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev

-- 
Kyle