[Gdal-dev] OGR returns wrong floating values for shapefiles (and integer as real, in error)

[Frank Warmerdam]

Maciej Sieczka wrote:
> Frank Warmerdam wrote:
>> Maciej Sieczka wrote:
>>> Hmm, this looks wrong (?) - my CAT and LCAT *do* have a zero precision.
>>> So I'd expect them to be treated as integer. And the other 4 columns
>>> have 15 decimal places precision, not 2. Open the dbf in a spreadsheet
>>> to see that:
>>>
>>> CAT,N,11,0
>>> LCAT,N,11,0
>>> Z,N,24,15
>>> Z_BREACH,N,24,15
>>> Z_BREACH1,N,24,15
>>> LENGTH,N,24,15
> 
>> Because Shapelib does not have a 64bit integer type, it automatically
>> treats integer fields that are potentially to large to fit in a 32bit
>> integer as floating point.  This isn't a great approach and causes a
>> number of problems,
> 
> One of which is that after v.out.ogr->v.in.ogr one gets his previous
> integer fields imported as double floating point.
> 
>> but it isn't completely without reason.
> 
> But is that planned to be fixed?

Maciek,

It is a known problem that I hope to address eventually but there is no
timeline for a fix.

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo, http://osgeo.org