GeometryExtractor WKT geometry not the same as source data

​@so_much_more Hi there, thanks for the question, and great catch on the geometry discrepancy. I have a hunch this discrepancy has something to do with how FME is reading in this circular arc feature. If the format used to read in the arc features does not support arcs, FME will tend to bring these features in as paths / polylines. According to the help documentation for the GeometryExtractor,

The OGC variants are useful if interaction with other OGC supporting systems is required. However, some characteristics of geometries may be lost in these modes; for instance, any path will be flattened into a single linestring.

The above help doc info is found by expanding the General section under Parameters, and then peeking through the Geometry Encoding information.

So, my first hunch on what is happening is FME is reading your circular arcs in as paths, and then the GeometryExtractor is flattening the paths into linestrings. That’s if I’m understanding the workflow correctly.

If you’re looking to check the geometry of your features, you could consider using the GeometryFilter set to Detailed Mode, instead of the GeometryExtractor. Then, for the GeometryFilter’s Output Ports, just Select All, and run your features through the GeometryFilter to see what type of geometry you have. Just note, if FME is indeed reading you circular arc features in as paths, they’ll be output via the IFMEPath output port of the GeometryFilter.

Let us know here if the GeometryFilter offers what you’re looking for!