Kosta, Team,
Konstantin Baumann wrote:
Hi Even,
the fallback to double/real does only help if the integer could be stored in 52
bits, since the rest of the bits are reserved for the mantissa and sign =>
exact up to ~15 decimal digits.
I proposed a fix 3 years ago to change the data type to string in order to not
loose data:
Patch:
http://trac.osgeo.org/gdal/attachment/ticket/2286/gdal-shapefile-datatype.patch
Ticket: http://trac.osgeo.org/gdal/ticket/2286
which was rejected. :-(
And the introduction of 64-bit integers (also RFC31_OGR_64 is highly
appreciated) will still not help for integers with more than 19 decimal
digits... [note: e.g., TeleAtlas uses 30 digit integers as feature IDs]
Kosta
The Ordnance Survey of Great Britain use 20 digit integers for feature IDs. I
had to revert to storing these as text in the database as the compilers I use do
not support 128bit integers.
It is necessary in such situations for the programmer to take a reasonably
pragmatic approach. Feature IDs, for example, are invariant references which
are not used within mathematical computations, etc. It is not, therefore,
essential to manipulate these as numbers, even where they are numeric. I have
not yet seen data values that would exceed the storage available in a 64bit integer.
Best wishes,
Peter
--------------------------------------------------------------------------------
Peter J Halls, GIS Advisor, University of York
Telephone: 01904 323806 Fax: 01904 323740
Snail mail: IT Services, University of York, Heslington, York YO10 5DD
This message has the status of a private and personal communication
--------------------------------------------------------------------------------
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev