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

[Etienne Tourigny]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20140310/56755b25/attachment.html>