Opened 7 years ago

Closed 3 years ago

Last modified 3 years ago

#3732 closed defect (fixed)

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

Reported by: cdestigter Owned by: Robert Coup
Priority: normal Milestone:
Component: GDAL_Raster Version: 1.10.1
Severity: normal Keywords: asciigrid
Cc: Kyle Shannon

Description (last modified by 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.

Attachments (2)

gdal-ascii-grid-floatformat.patch (1003 bytes) - added by cdestigter 7 years ago.
3732.patch (4.6 KB) - added by Kyle Shannon 3 years ago.

Download all attachments as: .zip

Change History (13)

comment:1 Changed 7 years ago by cdestigter

Description: modified (diff)
Summary: Add a FLOAT_FORMAT creation option to ASCII Grid writerChange float format string for AAIGrid writer to %.20g
Type: enhancementdefect

Changed 7 years ago by cdestigter

comment:2 Changed 4 years ago by Robert Coup

Resolution: fixed
Status: newclosed

Fixed in [25032]

comment:3 Changed 4 years ago by Chau

Resolution: fixed
Status: closedreopened
Version: unspecified1.10.1

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.

comment:4 Changed 4 years ago by Robert Coup

Owner: changed from warmerdam to Robert Coup
Status: reopenednew

Hi @Chau,

What OS are you running on?

comment:5 Changed 4 years ago by Chau

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

comment:6 Changed 3 years ago by 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.

comment:7 Changed 3 years ago by 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

Changed 3 years ago by Kyle Shannon

Attachment: 3732.patch added

comment:8 Changed 3 years ago by Even Rouault

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

comment:9 Changed 3 years ago by Kyle Shannon

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

comment:10 Changed 3 years ago by Kyle Shannon

Cc: Kyle Shannon added
Resolution: fixed
Status: newclosed

Committed to trunk in r27033.

comment:11 Changed 3 years ago by 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.

Note: See TracTickets for help on using tickets.