FeatureWriter and geometry type handling with GeoPackages

Hi ​@chau!

This is an expected behavior when writing to GeoPackages. You're correct; it's mapping to the broadest geometry type rather than the narrowest. This is because the Writer’s Automatic Schema Definition (<from first feature>) inherits the geometry from the first incoming feature, which in your case comes from the Creator’s generic <all> geometry source. This causes the writer to map to the broadest matching type (3D Measured Multi Curve). 

A workaround is to specify the geometry type by switching the Schema Definition to Manual and selecting "geopackage_linestring" under the Geometry Definition (shown below).

[Internal Reference: FMEENGINE-88364]

Hi ​@chau!

This is an expected behavior when writing to GeoPackages. You're correct; it's mapping to the broadest geometry type rather than the narrowest. This is because the Writer’s Automatic Schema Definition (<from first feature>) inherits the geometry from the first incoming feature, which in your case comes from the Creator’s generic <all> geometry source. This causes the writer to map to the broadest matching type (3D Measured Multi Curve). 

A workaround is to specify the geometry type by switching the Schema Definition to Manual and selecting "geopackage_linestring" under the Geometry Definition (shown below).

 

[Internal Reference: FMEENGINE-88364]

Hi ​@abbyatsafe 

So does this mean that the geometry of the Creator object has multipart, 3D and measures by default (even though the GeometryExtractor only reports 2D linestring) or does the FeatureWriter only determine the basic geometry type (point, line, area, ...) and applies the most broad definition?

Hi ​@chau, great question! 

By default, the geometry of the Creator object doesn’t have multipart, 3D, or measures. The Creator only knows it will emit some geometry based on the input. So when a Creator reports a generic <all> geometry source, it's not describing the geometry it's about to produce, but rather labeling what format it can hold.

We’re looking into enhancing our documentation to explain this behavior further, so thank you for bringing this to our attention!

In terms of the FeatureWriter, you’re correct, and this is specific to GeoPackages. With Automatic Schema Definition, the FeatureWriter determines the basic geometry type (point, line, area) from the first feature. It then selects the broadest possible definition to label the GeoPackage column type. That is why it assigns 3D Measured Multi Curve as the label, even though the geometry remains unchanged (2D linestring).  

By switching the Schema Definition to Manual and selecting "geopackage_linestring" under the Geometry Definition, you should have more control over how the GeoPackage column type is labeled.

Hi ​@abbyatsafe 

If the FeatureWriter always selects the broadest definition it looks like we are going to need a GeometryScanner transformer. This can create a geometry type object which can be used by the FeatureWriter to dynamically select the correct geometry type. 

I do feel we had this already and that something has changed creating this issue.

Hi ​@abbyatsafe ,

Is it also possible to specify the geometry type in combination with the Automatic Schema Definition?

And is this new behaviour? I have suddenly the same issue (multipoints created instead of points) with a workspace that I used several times before without having this problem. 

Hi ​@chau and ​@carolinev!

Sorry this has caused friction in your workflows. The <from first feature> geometry mapping, which maps features to the most general geometry type (such as multipoint or multiline) was introduced around FME 2023.0.

That said, if the behavior of your existing workflows appears to have changed after upgrading, please open a case with us using this link: Support Case. This will allow our team to investigate the change more closely, identify a possible workaround, and determine whether there is an opportunity for a future product enhancement.

If possible, please include your current and previous FME build numbers, along with a Workspace Template (FMWT) containing data caches. That information would be very helpful for our investigation.