Change float format string for AAIGrid writer to %.20g

[cdestigter]

The AAIGrid float format string is "%6.20g"

Firstly, the 6 doesn't really add anything, and when writing small integers it causes them to be space-padded, which is a waste of bytes.

At present AAIGrid supports "-co DECIMAL_PRECISION=10" which changes the formatstring to "%.10f".

This is a little inconsistent, and the %f causes integers to be written as "9.000000000" which is a horrible waste of bytes.

I'll attach a minimal patch shortly which fixes these.

[Robert Coup]

Fixed in [25032]

[Chau]

What is the intension of DECIMAL_PRECISION?

Before this change the value of 330.51 with DECIMAL_PRECISION=1 resulted in the value 330.5. After this change the same value turns into 3e+02, which means a loss of 30.5. Is this what DECIMAL_PRECISION is about? I would expect the old behavior. Maybe the term should be renamed to SIGNIFICANT_DIGITS instead?

Personally though, I would like the old behavior of DECIMAL_PRECISION to return and if anyone wants to use the new behavior, make it available through SIGNIFICANT_DIGITS.

[Robert Coup]

Hi @Chau,

What OS are you running on?

[Chau]

I'm running Windows 7 x64 and GDAL 1.10(.1?) x64.

[cleo]

We have just updated to 1.10.1 and this is causing an inconsistency in how the no-data-value is stored compared to other values in the dataset.

As mentioned by Chau, the change means that no-data-value are still stored in the old format, but data in the data set is using the new format. This means that no-data-value can no longer be detected. I think this is a flaw.

Here is an example. Most of our datasets use very large numbers for the no-data-value.

ncols        3
nrows        3
xllcorner    -2.500000000000
yllcorner    -2.500000000000
cellsize     5.000000000000
NODATA_value 3.4028234663852886e+038
 -70 -80 -90
 -40 3.4e+038 -60
 -10 -20 -30

As you can see, the center element should have been a no-data-value. But with 3 significant digits when used with printf's 'g' specifier is not used with the no-data-value. The values are no longer equal when outputting these files.

g specifier is significant digits while f specifier is digits after the decimal point.

I really like Chau's suggestion about having another creation option for significant digits though I would recommend that the no-data-value use the same formatting as the data.

[Kyle Shannon]

I think I have addressed both the significant digit vs decimal precision issue, as well as the no data issue, see attached patch.

kyle

[Even Rouault]

Looks good from my quick review. An update of the driver doc + autotest would be cool

[Kyle Shannon]

No problem, I'll update the docs and autotests and commit.

[Kyle Shannon]

Committed to trunk in r27033.

[hamish]

I'd point out that for IEEE double precision floating point you don't gain anything by going past %.17g. No more bits to feed it after you go past epsilon.