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

[Jonathan Moules]

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