[gdal-dev] GDAL precision for Geometry object

[Hermann Peifer]

On 2015-10-11 19:20, Dimitrianos Savva wrote:
>
> I just wondering if GDAL make use of any kind of custom-user-defined type that provides higher precision from a double.
> My question wasn’t so clear. The problem started comparing GDAL’s and GeoTools’ (Java) WKT representations of the same geometries that has been read from the same Shapefile.
> I noticed that GDAL provides higher accuracy than GeoTools. So I asked this question here, wondering whether GDAL is using something else than just doubles in memory.
> But I also concluded that in fact JAVA  and C doubles have the same representation in memory by running some minimal tests.
> However in Java, when converting a double into string, it even with (“.15f”) format, it does not give the same string value as doing so in C.
>

Hmm. I'm not a programmer of any kind and only know doubles and their 
siblings as defined by IEEE 754. I doubt that any serious programming 
language could have an interest in ignoring this standard.

 > GDAL provides higher accuracy..

Hmm. My observation is rather that when exporting into text formats 
(AAIGrid, WKT, etc.), GDAL seems to print more "numbers" (actually: 
longer string values) than meaningful in the given context. A double is 
a double is a double, and can only be as accurate as defined by IEEE 
754. I am quoting hamish once again: "I'd point out that for IEEE double 
precision floating point you don't gain anything by going past %.17g."

Just to quote another source (Wikipedia): If an IEEE 754 double 
precision is converted to a decimal string with at least 17 significant 
digits and then converted back to double, then the final number must 
match the original.[1]

I assume it is clear now that the conclusion "I see many numbers", so 
this format "must have higher accuracy" can indeed be wrong.

Hermann