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

strk strk at keybit.net
Thu May 13 05:23:35 PDT 2004


On Thu, May 13, 2004 at 10:20:08AM +0200, strk wrote:
> 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...

I've checked, and actually current behaviour is not to handle NULL
values specially. They are just transformed to 0 if number and
empty string if strings. So I've changed pgsql2shp.c to use
DBFWriteAttributeDirectly(), which does not attempt at any
conversion. As before NULL numbers are transformed to 0.

--strk;

> 
> --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
> _______________________________________________
> 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