Hi all,
If you’ve used FME2011 – or attended any of our FME World Tour events – then you may have noticed a new transformer called the FeatureReader. It’s not often a single transformer gets a whole FME Evangelist post to itself, but this remarkable piece of functionality is going to be very popular with power users, besides simple enough for anyone to understand.

Ladies and gentlemen, I give you the FeatureReader!

What Does it Do?
Well, we like to give our FME transformers names that are self-explanatory, and it doesn’t get much simpler than this. The FeatureReader transformer, reads features!

When the parameters dialog is opened, the standard FME Reader parameters are there to be entered:

When the workspace is run, each feature that enters the transformer triggers reading from this dataset. Therefore, instead of reading data with a Reader like this:

A Creator transformer can be used to trigger the FeatureReader to read that data, like this:

OK, so there’s a little more to it than that; otherwise we could just rely on Readers in the workspace. The FeatureReader benefits because it has a number of useful parameters. Let’s take a look at some, and a use for each of them (or skip a few sections if you like, to see some examples).

Feature Type List
Firstly, there is the possibility to specify the Feature Types to read using a string stored in an attribute:

With this, a workspace author could get the list of tables/layers to read from anywhere, and pass it through to the ‘reader’. In effect it’s a “feature types to read” parameter that can be defined by an attribute created within the workspace. Reader parameters can only be set at runtime, by user input.

For example, say a list of layers to read was stored in a text file. The workspace could read the text file, concatenate the list of layers into a single attribute, then use that attribute to define the layers to read in the FeatureReader.

WHERE Clause
A second FeatureReader parameter is a WHERE clause.

Again, the benefit here is that a workspace author can construct the WHERE clause using existing transformers. They don’t have to do it outside of FME, using a scripting language.

Spatial Interaction
The transformer also includes a built-in filter for spatial interaction (click to enlarge):

In other words, only features that pass a certain spatial test – in relation to the trigger feature – will be read. This is what really opens up the possibilities.

For example, the trigger feature could be a polygon, and the author only wants to read features that fall inside that polygon. This is very simple to achieve with the FeatureReader.

Compare this to a Reader, which has only the capability to clip to a min/max bounding box, and you should begin to see the benefits of this transformer.

Examples
It’s probably best to demonstrate this transformer with the aid of a few examples.

Example 1: Grid Square Filtering
Here an organisation has a set of address data covering a city (in a Spatial Database), and a set of grid squares. They want to be able to read just one grid-square of addresses at a time. Note, however, that the grid isn’t exactly rectangular; so min/max x/y coordinates couldn’t be used as a clip boundary in a Reader:

So, the first action is to query the user as to the required grid square. Into an empty workspace are added two published parameters (Row and Column) so the grid square can be defined from user input.

When the workspace is run (Prompt + Run) the user is prompted for a grid square like this:

So the first part of the workspace looks like this:

The grid features are read, the published parameter values fetched and concatenated, and then a Tester is used to filter out all grids except the chosen one.

Now the FeatureReader is used to find addresses within that grid:

The selected grid is used as a trigger for a spatial query, where only addresses inside the grid polygon are returned:

For good measure, a WHERE clause is added, so that inactive addresses aren’t part of the output:

When run, only active addresses in the chosen grid are returned:

Obviously, the alternate way would be to read both grid and addresses with a workspace, then use a Clipper transformer (or SpatialFilter) to get the required addresses. However, the FeatureReader is so much better because it doesn’t require that all addresses be read – just ones in the chosen grid – and also makes better use of the native functionality of the spatial database.

Example 2: FME Server Data Distribution
This example can be found as a live demonstration hosted on fmeserver.com – in actual fact the workspace there was created in 2010 and illustrates perfectly why a FeatureReader is now the better option!

The web page is a Data Distribution interface – powered by FME Server – with a number of options available:

The user can select a predefined boundary (as in the previous example, but using a neighborhood, rather than a grid square) or use the Draw option to define a completely custom area of interest. Finally, the “Layers to Download” setting allows the user to pick which are the layers of interest.

Assuming the user decides to draw the area of interest, the coordinates of the area are recorded as XML by the web site, which then calls a workspace and passes the XML string as a published parameter.

In the workspace it would look like this; a published parameter to receive the geometry:

…and a Creator transformer to turn that XML string into a proper FME geometry (click to enlarge):

Now we have the query feature, it’s simple to have it trigger a FeatureReader transformer to read that area of data from the database. At the risk of harping on the same theme, FME2010 would have needed to read ALL of the database data, then clip it to size using a Clipper transformer.

The Layers to Download setting makes use of the “Feature Types to Read” parameter in the FeatureReader. This requires a list of feature types separated by a colon character. This list could be either created by the web application and passed to FME, or creating within Workbench using a StringConcatenator transformer.

Assuming the web site creates the list, again it passes it to FME using a Published Parameter:

…which is read into an attribute with a ParameterFetcher, and used in the FeatureReader:

Conclusion
Hopefully this information and examples have shown you exactly what the FeatureReader is capable of. I predict that we will be seeing much more of this transformer in many scenarios.

Regards,

About FME Data Distribution Data Transformation Databases FME Desktop Parameters Spatial Analysis Tester Usability XML

Mark Ireland

Mark, aka iMark, is the FME Evangelist (est. 2004) and has a passion for FME Training. He likes being able to help people understand and use technology in new and interesting ways. One of his other passions is football (aka. Soccer). He likes both technology and soccer so much that he wrote an article about the two together! Who would’ve thought? (Answer: iMark)

Comments

Comments are closed.

Related Posts