Skip to main content

In the new, fantastic, InlineQuerier (2023 beta), a geometry column can be selected. Is there a way to call directly the geometry of the feature without geometryextractor? On the same topic, is there a way to define the ouptput geometry without using an ST_asText followed by a GeometryReplacer?

@antoine​ InlineQuerier has part of FME for quite a long time. InlineQuerier will return the geometry of the first table listed in the Select.

So

SELECT P.*, T.* FROM "Parks" P ...

will return the Geometry of P but

SELECT T.*, P.* FROM "Parks" P ...

will return the geometry from table T

 

The change in FME 2023 is to add a "geometry" data type in the Define Query columns. You should be able to execute any ST_ function inthe queries:

imageRegarding the Query Columns. By default this is set to all the columns on the FME Feature. But InlineQuerier creates a packed column, fme_feature_content, that contains all the feature information (attributes and geometry). So for efficient use of Inlinequerier, only keep the attributes you will use in the query, usually ID's.


@Mark Stoakes​ I wanted to know if I could access directly the geometry from the feature without extracting it into an attribute first. As fme_feature_content contains all the info, I don't know how to do something like ST_buffer(fme_feature_content.geom) and have it as my output geometry.

If I use the "geometry" data type , as far as I know, I need first to use a GeometryExtractor and to use a GeometryReplacer in the output. That is what I did in the example I included as print-screen in my first question.

Could there be a way to call the feature geometry in SQL without extracting it in an attribute beforehand?


@antoine​ Version 2 of the InlineQuerier (FME 2023 betas) allows you to set the geometry column as shown here:

imageAThen you can use the geometry in your SQL query:

SELECT C.*, B.* FROM "CellSignals" as C, "local-area-boundary" as B
WHERE
ST_Intersects(B."_geom",C."_geom") ;

I've attached an example workspace (FME 2023 beta Build 23197)

SpatiaLite spatial queries can be pretty slow apparently.


Reply