FME2010 Special: New Transformers

Hi FME’ers,
Perhaps the most useful part of our FME Desktop training course is where we cover different transformers and how to find the one you want. Let’s face it: there are lots. And in FME2010 there are a whole bunch more. So in this post I’ll highlight which new transformers the best-dressed workspaces will be showing off in 2010!

AttributeRangeMapper and AttributeRangeFilter
The AttributeRangeMapper is similar to the ValueMapper but is used to map ranges of values rather than individual values. This makes it good for classifying data into groups based on attribute values (eg 0-10 = Group1, 10-20 = Group2, 20-30 = Group3, etc. As this example shows, it’s very useful for when you want to use the output data for thematic mapping.

What’s extra special is the ability to have Workbench generate ranges for you based on predefined numbers:

Of course, the ultimate would be to do this sort of thing dynamically (depending on the data which enters the transformer) which is something we’ll think carefully about implementing.

And in some cases you might want to divide the data up inside the workspace (rather than assigning a new attribute to it) in which case you would want to use the similar AttributeRangeFilter transformer.

So the AttributeRangeFilter is like the AttributeFilter, but with ranges instead of individual values. The best thing about the AttributeRangeFilter is that you can even rename the output ports according to the values you are filtering by (above).

TestFilter
On the subject of Filter transformers (transformers which test features and route them to different destinations based on the outcome) another useful new transformer is the TestFilter.

As you can see in this example, the TestFilter is the perfect solution when you need to do a series of tests (as opposed to a single test) on some data.

So, in programming terms, the TestFilter is very much like a multipath branch operation such as a CASE or SWITCH command.

And one of the really great things about the TestFilter is that it has the new (for 2010) test interface, which lets you implement composite conditions with ANDs and ORs.

PDFStyler and KMLStyler
These are two examples of transformers which help you to manipulate data in a specific way for a specific destination format. The KMLStyler transformer obviously helps you style data for use in KML. This is not a new transformer, but it has undergone some major updates in FME2010, including being augmented by  companion transformers such as the KMLViewSetter, KMLPropertySetter, KMLTimeSetter and KMLTourBuilder.

The PDFStyler is new for FME2010. It is used to create a style for features which are going to be written out to Adobe 2D or 3D PDF formats.

Above: Key parameters on the PDFStyler allow you to set a name, tooltip and URL link. Color and linestyle settings are also available

DensityCalculator
I think the DensityCalculator transformer is my favourite new transformer for FME2010; I can just think of so many uses for it. In brief, it calculates the density of one set of features inside the boundary of another. For example, it’s original function was to calculate the density of rivers and streams within a river basin. You might also use it to calculate the density of public facilities (eg parks) within specific neighborhoods, or the density of customers within defined shopping areas.

You can calculate density on the length of candidate lines (which is what you’d do for streams), the size of area (which is what you would probably use for parks), or on the basis of number of features within the master area (what you would do for customer density).

In the example on fmepedia, the transformer is used to calculate the density of a bus network within different zones in the city; so it is a calculation on the basis of line length, with a group-by to examine each tile separately.

Twitter Transformers
There are four new transformers in FME2010 designed specifically for communicating with Twitter. In case you weren’t aware(!), Twitter is a web site for posting 140 character messages – micro-blogging they call it – as a form of social interaction. However, many users of the service are companies looking to provide status updates, and this is where FME might come in.

With the Tweeter transformer you would be able to “tweet” a message about the results of a translation; so you could, for example, start a process running and check the status of it later from home. You might tweet a user to let them know that their FME Server translation is now complete, or you might actually tweet the geometry of a feature using Well-Known Text (a feature built into the transformer).

In other words, wherever you need to alert someone about an event inside a workspace, then the Tweeter transformer is a very simple way to do this.

Below: Twitter is kind enough to advertise which application I used to tweet this message:

Of course, some folk ask why you don’t send an email instead. The answer is that email is a lot harder to set up and send messages with. You’d need the server name, username, password, etc, none of which is information you would usually have to hand (I haven’t a clue what my email server is called). It’s a little easier with clients like Gmail, but still not as easy as sending tweets via Twitter.

And yes, we do support reading and writing spatial data points using the Twitter GeoAPI.

ShortestPathFinder and NetworkCostCalculator
The ShortestPathFinder does exactly as its name suggests and calculates the shortest route between two given points on a network. This might be the shortest route in terms of distance, or the shortest route in terms of cost (ie weighting the result on the basis of an attribute such as road speed, etc).

Below: In this example from fmepedia, the output is a route from one point to another:

Where the ShortestPathCalculator can really score is when you combine it with the new KMLTourBuilder transformer; i.e. you pick two points, calculate the shortest route between them, and then create the means to fly the route in Google Earth.

The NetworkCostCalculator carries out a similar action, but only starts with a single source point. It then calculates the amount of network which can be traversed for a given cost. For example, in the screenshot below, we are looking (in PDF) at how far a person might travel in 10 minutes from their starting location.

RasterCellValueCalculator and RasterSingularCellValueCalculator
These two transformers are – like the RasterExpressionEvaluator – based on the RasterEvaluationFactory. The difference is that the RasterExpressionEvaluator is much more flexible – but also much more complicated. These new transformers are designed to expose users to a set of simple raster calculations in an easy-to-use way.

The RasterCellValueCalculator carries out calculations between two different raster features. The output feature is a combination of the inputs where corresponding cells have been subject to one operation from addition, subtraction, multiplication, division, minimum or maximum.

This example on fmepedia is designed to evaluate local amenities for potential house purchasers. By creating a raster for each type of data, with a value in cells where that amenity is available, then the RasterCellValueCalculator can be used to add up all of the raster features to show where the level of amenities is highest. This is what the numeric output looks like when rendered in the FME Viewer.

The lightest coloured parts of those where amenities are most plentiful.

The actual workspace is slightly complicated, because it starts with vector data, and lets the user provide their own weighting for each amenity (so they can rate closeness to parks relative to closeness to a bus stop according to their own needs). However, the key part is the RasterCellValueCalculator, which powers the whole translation.

The RasterSingularCellValueCalculator carries out a similar operation, except that it works with one raster feature (rather than two) and a constant calculation value. For example, in this representation each cell in a raster has 4 added to its initial value.

XMLTemplater
The XMLTemplater is a tool for populating an XML document with new values copied from FME attributes. In that sense it carries our similar functions to the XQuery transformers.

The key use for this transformer is in handling metadata. Much metadata is stored in an XML form, and this transformer allows a user to create that metadata using a template defined in a mix of XML and FME syntax.

The easiest way for me to understand it was this:

• XQuery is for updating existing documents.
• XMLTemplater is for creating new documents.

For example, if I have an existing metadata document with the tag:

BrianC

…then to update this with a new value I would use XQuery in the same way that I describe here.

However, if I want to create a new document, then I could define a template file containing this:

{fme:get-attribute("_username")}

…and read it with the XMLTemplater transformer. The XMLTemplater will automatically insert the contents of the attribute _username into the tag. I haven’t needed to use XQuery to do this.

Then it’s simply a case of writing out the XML document to wherever I want. I could do this with the AttributeFileWriter transformer (if I want a text file) or with a writer (for example if I wanted to store the metadata in a field in a database).

The complete list of new transformers in FME2010 can be found on fmepedia at: http://www.fmepedia.com/index.php/Whats_Great_2010#New_Transformers

Try them out and don’t forget to have fun.