Aspose.GIS FileGdb driver fails to open a dataset containing a BigInteger (GDB field type 13) field

Aspose.GIS Product Family
1

Hi,

I ran into a blocking issue with the FileGdb driver. I have a File Geodatabase delivered to me by a third party, and one feature class in it has an attribute field of Esri’s BigInteger type (a 64-bit integer, GDB field type code 13 in the FileGDB binary format). When I try to open that layer, Aspose.GIS throws instead of reading it.

using Aspose.Gis;

using (var dataset = Dataset.Open(filePath, Drivers.FileGdb))
using (var layer = (VectorLayer)dataset.OpenLayer(layerName))
{
foreach (var feature in layer)
{
// never reached
}
}

This throws:

System.InvalidOperationException: Unknown GDB field type 13.
at Aspose.Gis.Common.Formats.GdbTable.GdbFieldDescription.(Byte )
at Aspose.Gis.Common.Formats.GdbTable.GdbFieldDescription.(BinaryReader )
at Aspose.Gis.Common.Formats.GdbTable.GdbTableFile.()
at Aspose.Gis.Common.Formats.GdbTable.GdbTableFile.Open(AbstractPathInternal path)

I tested this on our production version, 24.10.0, and also just installed the newest package, 26.8.0, to check, same exception on both.

As far as I can tell, BigInteger was added by Esri in ArcGIS Pro 3.2, together with field type codes 14 (DateOnly), 15 (TimeOnly) and 16 (DateTimeWithOffset), see FGDB Spec · rouault/dump_gdbtable Wiki · GitHub for the spec. GDAL’s OpenFileGDB driver already reads these fine, so it looks like Aspose.GIS’s field type parser was never updated for this.

What makes this annoying in practice is that it is not a minor/cosmetic issue, the whole layer fails to open, even though every other field is fine. And BigInteger is not some exotic edge case, ArcGIS Pro switches a field to it automatically once a value no longer fits in a classic 32-bit Long Integer, so I expect to run into this more often going forward, not less. These files are delivered to us by third parties using their own Esri/ArcGIS setup, so we have no control over which field types they end up using.

This is blocking real work for me right now, so I’d rather not wait for the next scheduled release. Would it be possible to get a hotfix for field type 13 specifically (14/15/16 would be nice too, but 13 is the one hurting me today)? If a hotfix isn’t an option, please let me know if there’s a workaround I’m missing on the API side, or at least a rough timeline for when this would be picked up.

Hope you can guide.
Regards,
MC

2

Dear Mehmet Canavar!

Thank you for the detailed report.
Based on the exception you provided, it appears that the current Aspose.GIS FileGDB reader does not recognize GDB field type 13 (Esri BigInteger). We need to reproduce the issue with an actual FileGDB before we can confirm the limitation and register it for investigation.
Could you please provide a small sample FileGDB containing a feature class with a BigInteger field that reproduces the exception? If you also have a sample containing field types 14–16 (DateOnly, TimeOnly, and DateTimeWithOffset), you may include it as well, although field type 13 can be investigated separately.
Since the exception occurs while the layer schema is being read, there does not appear to be an Aspose.GIS API option to skip the unsupported field before opening the layer. As a temporary workaround, you can use another tool, such as GDAL/OpenFileGDB, to convert the dataset to a format supported by Aspose.GIS while preserving the required attribute values.
Once we have a reproducible sample, we can investigate the issue and provide information about possible fix availability and release timing.

Best regards,
GIS support team

3

Hi,

Thanks for the quick reply.
Attached is a minimal, fully synthetic sample (BigIntegerRepro.gdb.zip (10.8 KB) ) that reproduces the exact same exception, one fake polygon, one BigInteger field. I confirmed it throws the identical stack trace as our real file:

System.InvalidOperationException: Unknown GDB field type 13.
at Aspose.Gis.Common.Formats.GdbTable.GdbFieldDescription.(Byte )
at Aspose.Gis.Common.Formats.GdbTable.GdbFieldDescription.(BinaryReader )
at Aspose.Gis.Common.Formats.GdbTable.GdbTableFile.()
at Aspose.Gis.Common.Formats.GdbTable.GdbTableFile.Open(AbstractPathInternal path)

I didn’t attach the original production file since it contains third-party business data I’m not able to share, this sample should be enough to reproduce it though.

I don’t have a sample with field types 14-16 handy, but happy to make one the same way if that would help.

Thanks for confirming there’s no API-level option to skip the unsupported field, that matches what I found.

We’ll use the GDAL/OpenFileGDB conversion route as a stopgap in the meantime, as you suggested.

Regards,
MC.

4

Dear Mehmet Canavar!

We’ve received the BigIntegerRepro.gdb sample and will try to reproduce the “Unknown GDB field type 13” exception on 26.8.0; we’ll notify you as soon as a version containing the fix is available. In the meantime, the GDAL/OpenFileGDB conversion path you’re using is the recommended workaround.

If there’s anything else we can help with while you’re waiting (e.g., scripting the conversion or handling the data after conversion), just let us know.

Best regards,
GIS support team