#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 )
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)
Change History (13)
comment:1 by , 14 years ago
Description: | modified (diff) |
---|---|
Summary: | Add a FLOAT_FORMAT creation option to ASCII Grid writer → Change float format string for AAIGrid writer to %.20g |
Type: | enhancement → defect |
by , 14 years ago
Attachment: | gdal-ascii-grid-floatformat.patch added |
---|
comment:2 by , 12 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:3 by , 11 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
Version: | unspecified → 1.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 by , 11 years ago
Owner: | changed from | to
---|---|
Status: | reopened → new |
Hi @Chau,
What OS are you running on?
comment:6 by , 11 years ago
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 by , 10 years ago
I think I have addressed both the significant digit vs decimal precision issue, as well as the no data issue, see attached patch.
kyle
by , 10 years ago
Attachment: | 3732.patch added |
---|
comment:8 by , 10 years ago
Looks good from my quick review. An update of the driver doc + autotest would be cool
comment:10 by , 10 years ago
Cc: | added |
---|---|
Resolution: | → fixed |
Status: | new → closed |
Committed to trunk in r27033.
comment:11 by , 10 years ago
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.
Fixed in [25032]