I would similarly observe as @todd_davis points out that the “Combine Geometry” Parameter needs to be “Result Geometry Only” , and the SQL needs to include the Geometry/Geography table field in the SELECT Field/Expression1, Field/Expression2…….Geometry/GeographyField (Eg. “SHAPE”, “geom” etc.) … statement.
Having said that, there are some SQL statements that SQLExecutor will not auto-detect the geometry field/expression as a valid feature geometry. Without extensive testing, the common types that have “failed” for me is where there are multiple/complex statements being executed like using SELECT with a preceding CTE WITH statement, or populating a Table Variable Geometry fields with VALUES() and trying to select from the declared table variable geometry field etc.
I suspect if the SELECT field name or field alias can’t be easily interpreted by SQLExecutor as parsing back to a corresponding physical table name and physical geometry/geography field name, this can also fail, but it should only be for “complex” SQL statements.
I would wish in this case for a SQLExecutor enhancement that allows the user to explicitly state which SQL SELECT Field/Expression to “Treat as the Feature Geometry”……….but in these cases where SQLExecutor does not auto-detect the geometry field/expression then the workaround is:
- Expose the geometry field/expression as an Attribute (Which will have an Eg. Binary encoded geometry value)
- Transpose this attribute to an FME Geometry with GeometryReplacer
