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

Reply via email to