Hi,
It is a bug I'm reporting.....
I am being supplied with multiple SHP files, which I am trying to
convert to a single TAB as fast and simple as possible, so bringing a
3rd format into the picture really doesn't help. The DBF still has too
many digits for OGR to process them correctly.
Regards
Uffe Kousgaard
Norman Vine wrote:
When DBF files has numeric fields with values
> 2GB, processing fails and all values come out as -2147483648.
My current work-around is manually changing the fields from Numeric to
Char (changing the header of the DBF), but it is really an ugly hack
and spaces for padding are wrong (numeric fields are right-aligned,
while char-fields are left-aligned internally).
It would be nice if at least int64 was used for integers in OGR, rather
than int32. Large integers are typically used as identifiers in
databases such as TomTom, OSM etc.
Has this been reported before?
This is a well known feature
see
solution
use something like spatialite instead of shape files
_______________________________________________
gdal-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
|
_______________________________________________
gdal-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
