[postgis-devel] Re: dbfopen numeric fields handling broken ?

strk strk at keybit.net
Thu May 13 01:20:08 PDT 2004


I've made shp2pgsql always read dbf attributes as strings, letting
postgres do appropriate transformation. This seems a good workaround
for the 64bit integers missing support in shapelib.

Dumping, on the other hand, is not so easy, since shapelib does 
require a number for a field of numeric type, and then does string
conversion internally, discarding higher bits.
A solution would be to call DBFWriteAttributeDirectly, but then
the dumper should care about formatting NULL values in the way
the dbf expect that...

--strk;

On Wed, May 12, 2004 at 04:10:25PM +0200, strk wrote:
> On Wed, May 12, 2004 at 09:56:41AM -0400, Frank Warmerdam wrote:
> > strk wrote:
> > > On Wed, May 12, 2004 at 08:27:38AM -0400, Frank Warmerdam wrote:
> > > 
> > >>strk wrote:
> > >>
> > >>>Hello again Frank.
> > >>>I got a .dbf containing a Numeric field with lenght=12 and
> > >>>decimal places=0.
> > >>>DBFGetFieldInfo() tells me it's a FTInteger (because of 0 decimals).
> > >>>DBFReadIntegerAttribute() casts the value to an integer, but this
> > >>>conversion seems to be inadeguate, since I get always -2147483648.
> > >>>Values goes from 10010001000 to 51580035000 (viewing with dbview),
> > >>>so it does not seem to be a corrupted dataset.
> > >>>
> > >>>dbfopen.c is Revision 1.52  2003/07/08 15:20:03  warmerda.
> > >>>
> > >>>Any hint on how to fix this ?
> > >>
> > >>Strk,
> > >>
> > >>Can you provide the .dbf file?  I have heard other reports of problems with
> > >>large integer values and I would like to try and resolve the issue.
> > > 
> > > 
> > > I've checked and fixed the bug already. 
> > > What is needed is have DBFReadIntegerAttribute return an int with 64bits,
> > > or directly return a double if an int64 is not enough to contain the 
> > > maximum lenght for a dbf field of type N with no digits.
> > > For sure returning 'int' (signed) does not allow numbers higher 
> > > then 2147483647 or -2147483648, whih is 9 digits guaranteed. No more.
> > 
> > Strk,
> > 
> > Can you provide a sample dbf file demonstrating the problem?
> 
> Sorry, but I can't. 
> I dunno how.
> I tried exporting a postgis table, but it seems that the same
> problem with Reading is there when Writing, probably
> DBFWriteIntegerAttribute...
> If you have tools to produce a dbf should be really straightforward
> to reproduce the bug: create a field of type N with 12 digits and 0
> decimal places. Put the value 620570012000 in the field.
> Read it.
> Write it in a new dbf.
> Check the new dbf.
> 
> I've included postgis-devel in the recipient list since this bug
> makes both postgis loader and dumper bogus as well.. 
> 
> --strk;
> 
> > 
> > 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    | Geospatial Programmer for Rent
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel



More information about the postgis-devel mailing list