We're working with a SQL Server database, and using the FID as a fixed record reference. And although the FID in SQL Server may be a 64-bit integer value, Ogr2Shape conversion always creates the FID as an Integer field. I believe that this is because the Shapefile source code only defines a 32-bit INTEGER data type - there is currently no 64-bit integer type defined.
The Xbase definition includes a Numeric data type field (code N) that holds up to 17 characters, including a sign and decimal point, that makes no distinction between integer or floating point. And in fact, this field is currently used by the open source Shapefile code for both Integers and Floating point values. However, the determination of data type is based on the following conditions:
IF Precision > 0 OR FieldWidth >= 10, THEN it is considered a floating point, else an integer.
I am recommending that we change the condition such that it is based solely on Precision > 0, independent of the length of the number. This would allow for values high into the 64-bit integer range. For backward compatibility, we could add a global setting indicating whether or not to support the 64-bit integer interpretation. Or, rather than globally, we could perhaps allow/apply the change on a per-Table basis (with a new OgrLayer property?). We could also propose an update to GDAL so that the codebase would be the same.
Please provide your thoughts.
1. Has this been an issue for anyone in the past?
2. Do you agree with the proposed solution?
I’ve not used MapWindow much with spatial databases and have not come across this issue.
It might be wise to post your findings on the GDAL-dev mailing list. It might be this is a deliberate restriction. They can advise us.
I can post it if you don't have access to it.
That makes sense. I will write something up. Thanks.
Ok. Before submitting a question to GDAL, I did a little more review, and here’s what I’ve learned.
The GDAL Shapefile driver DOES support 64-bit integers and FIDs - it is our internal handling of Shapefiles that does not.
Although we share the same Shapefile code, the wrapper classes differ in how they handle the data. So we would have to modify our Table class, Ogr2Shape class, etc., to accommodate 64-bit integers.
The customer I am working with has decided (for now) to stay with 32-bit FIDs, so at least for now, there is not a pressing need to make the change. I think it is still worth keeping open, though, as an enhancement request.
Thanks for diving into this. I agree we can look at this in the near future.