Skip to main content

Goal: Use the KLIC Transformer output to produce a FileGDB. I have used Esri Geodatabase (File Geodb Open API) as the writer. 

What the workspace does: Reads raw KLIC output, Builds dynamic layer name, GeometryValidatorGeometryCoercerAttributeKeeper keeps only required attributes, (Latest attempt) GeometryFilter to keep only Line geometry to avoid mixed-geometry, FileGDB FeatureWriter with Feature Class or Table Name = dynamic layer name, Dynamic Schema Definition = OFF, Table Handling = Create If Needed (sometimes Overwrite If Exists while testing), No dynamic schema port connected. 

What happens: Translation reports success, In the output GDB, I get only one feature class (the first encountered). For all other values in the dynamic layer name field, the writer logs warnings and doesn’t create those classes.

What I’ve tried: Narrowed the schema with AttributeKeeper. Verified in an Inspector that dynamic layer name field has many correct, distinct values (not just one). Deleted the output GDB between runs and refreshed ArcGIS Pro. Tried filtering to Line only (GeometryFilter) to avoid mixed geometry per layer. Earlier I hit the classic FileGDB “The field already exists” error due to auto-renaming collisions, which AttributeKeeper resolved. Current blocker is only one class created, others rejected with geometry/schema warnings.

Questions

  1. With dynamic per-feature table names and Dynamic Schema OFF, is the FileGDB Writer expected to create multiple feature classes on the fly, or do I need to supply a dynamic schema (Schema port)?

  2. If dynamic schema is required, is this the correct pattern?

    • SchemaScanner (Group By = dynamic layer name attribute, Scan Mode = Union/First Feature) → connect its Schema output to the writer’s schema port, and the line-only data stream to the main writer port

  3. Alternatively, is it better practice to avoid the schema port and instead encode geometry into the name, so each feature class is guaranteed a single geometry type?

  4. Any FileGDB-specific gotchas here that explain why only the first class is created and the rest are rejected?

Hi ​@roghayeh What warnings are you seeing in the log?
 

 


Hi ​@crutledge , warnings are like this (for every feature type that it sould create): Cannot find a matching schema named 'datatransport_Vitens' in the known set of schemas: 'datatransport_DELTA_Fiber_Netwerk_B_V_'. Known schema sources are: ''. Please verify writer feature type configuration
  |FileGDB Writer: A feature with feature type `datatransport_Vitens' could not be written
 |FileGDB Writer: A feature with feature type `datatransport_Vitens' could not be written

following by these warnings: GeometryCoercer: Cannot coerce from IFMEPoint to fme_line
 |... Last line repeated 158 times ...
  |FileGDB Writer: A feature with feature type `water_Vitens' could not be written

 

It can create only one feature class (the first encountered), for the rest i got these warnings.

 

 


What version FME do you use? In the early versions of 2025 is a bug with these symptoms.

I tried to reproduce what you want by changing FeatureWriter_2 from geopackage to Esri Geodatabase (File Geodb Open API) and it just works for me. A lot of warnings because the attributenames in a gdb are limited, for example "nominalVoltage (V)" is not valid in gdb because of the space and the parentheses.

I’m using 2025.1.2


Hi ​@nielsgerrits,

Thanks for your reply.

I’m using FME 2025.1.1.0.

I don’t want to use the Styled Output option of the KLIC transformer, because that transformer produces feature classes with fixed names.

Instead, I’m working with the Raw Output of the KLIC transformer, since I need to generate dynamic layer names.

In my workflow, I’ve created a new attribute called out_feature_type. For each KLIC dataset, I combine (concatenate) the values from the attributes beheerder and thema to populate this field.

My goal is for the File Geodatabase Writer to use that out_feature_type attribute to create separate feature classes—one for each unique value found in that field.

However, when I run the translation, the writer only creates one feature class (the first one encountered, with the correct name). For all the remaining features, I receive warnings, and no additional feature classes are created.

I suspect it has something to do with how the dynamic feature class naming or schema handling is configured, but I haven’t been able to pinpoint it yet.


Yeah please try again using 2025.1.3. This bug was fixed for featurewriters in 2025.1.2 and I believe but have not checked for classic writers in 2025.1.3.