@bwasserstein I don't think it's possible to ignore the spatial column in the FME Geodb readers. But you can immediately drop the geometry using the GeometryRemover. There are two File Geodb readers - File Geodb API (does not require and esri license) and File Geodb (which uses Esri libraries and requires an Esri license). So try a different reader if you think there is a corrupt geometry that affects the read.
You could use a FeatureReader instead of the FileGDB reader, initiated by a Creator with null geometry. In the FeatureReader, set the Geometry parameter to use Initiator. I think that would return the attributes of the database records with no geometry. Although, I don't know if the FeatureReader would actually not read the database geometry column...good possibility that it does, and is then simply replacing with null. You may have the same issue as using the native reader.
You could use a FeatureReader instead of the FileGDB reader, initiated by a Creator with null geometry. In the FeatureReader, set the Geometry parameter to use Initiator. I think that would return the attributes of the database records with no geometry. Although, I don't know if the FeatureReader would actually not read the database geometry column...good possibility that it does, and is then simply replacing with null. You may have the same issue as using the native reader.
Finally had time to give this a whirl. Unfortunately @dustin, your guess seems to be right - even with the creator initiator with null geometry, the FeatureReader does in fact still seem to read in the database geometry column, so I do still have the same issue as using the native reader. It's getting hung up on a polygon feature that seemingly too complex or something. It's funny because the spatial data goes through a lot of QA/QC and passes geometry checks.
Alas, I have a small bit of python that nullifies the geometry for this particular problem layer. I can run that ahead of the ETL processing, but it'd be nice if the FGDB reader had a option to only read in attribute data.
Finally had time to give this a whirl. Unfortunately @dustin, your guess seems to be right - even with the creator initiator with null geometry, the FeatureReader does in fact still seem to read in the database geometry column, so I do still have the same issue as using the native reader. It's getting hung up on a polygon feature that seemingly too complex or something. It's funny because the spatial data goes through a lot of QA/QC and passes geometry checks.
Alas, I have a small bit of python that nullifies the geometry for this particular problem layer. I can run that ahead of the ETL processing, but it'd be nice if the FGDB reader had a option to only read in attribute data.
@bwasserstein I think we'd like to understand why FME can't read a particular geometry. If you can share teh Geodb or an export of the problem feature class that would be great: mark at safe dot com
I think the option of being able to read in just the attributes & not the geoms would be a very useful addition.
Hi @p_c_20
This enhancement would require additional motivation.
If you would like to, please create an idea on our Ideas Board and let us know what the value of this change would be for you. Hearing about how this affects our customers' workflows and use cases helps our team better prioritize enhancements like these in the product.
