Dear FME’ers,
Happy “FME Release Day”.
Yes, today is the day that has been chosen to release the newest version of FME; FME2012. Time to party!
Anyway, probably the largest change is in how we construct and use attributes inside a workspace. There are some updates that will have a huge benefit for workspace authors, and this post details a few of these.
General Philosohpy
The basic premise for FME (as a product) is unchanged for 2012. It is still a Data Transformation tool; its core value is still one of spatial data interoperability.
However, there is a philosophical change for 2012; the idea that attributes and parameters should be handled directly within the transformer that needs to use them.
For example, there is less need to use a StringConcatenator transformer because string concatenation is built into transformers such as the HTTPFetcher, Tweeter, and SQLExecutor: and this is what this article is going to examine.
Reducing Support Transformers
In the basic FME training manual we talk about a difference between Operational and Support transformers. Operational transformers transform the content or structure of data, while Support transformers provide a framework for the operation to take place.
The idea for FME2012 is that attribute construction can be embedded directly into an operational transformer, so that the number of support transformers can be reduced.
For example, in 2011 you might construct a URL using the StringConcatenator to be used in the HTTPFetcher. In 2012 you can simply open a text editing dialog within the HTTPFetcher itself:
The text editing dialog is also updated. It is no longer like the StringConcatenator editor in previous versions. For example, here it is creating a string for the LabelPointReplacer:
Notice the mix of attributes and constants, with a “New Line” string thrown in. You’ll even find there is an option to include a published parameter, removing the need to use the ParameterFetcher transformer.
Also notice there is a button marked “Switch to Advanced”. This opens the same setup, but in a more open-ended editor:
Now you can really create some complex strings. And notice the menu on the left: you can even include FME functions such as @Area(), @Length(), and @Count(). A real expert could even use the @Evaluate() function to incorporate an arithmetic expression inside the string!
For example, here a string is being created by multiplying the area of a feature by the value of an attribute:
The string might be used as an attribute value in the output of a workspace, or a label content, or in many other places.
Expression Evaluation
Apart from strings, the other editor we now include is one for arithmetic expressions. You’ll find this attached to any transformer parameter that expects a numeric value. The editing dialog looks like this:
Notice that it’s very similar to the advanced text editor; it just doesn’t need @Evaluate to carry out math functions, as it’s assumed any expression will be a math function of some sort.
Take this as an example:
There the author is calculating the time to travel along a segment of road by using the link length (@Length function) and speed limit and traffic status (both attributes).
Again, this dialog appears in any transformer parameter that expects a numeric input. You might choose to use it in the Bufferer transformer to calculate a buffer size, or in the LabelPointReplacer to calculate a label height. Or, if you actually wish to create it as an attribute, you can just place an ExpressionEvaluator transformer and use the editor there.
Attribute Handling
Let’s look at another few items of interest. Firstly, the Reader Feature Type Properties dialogs have a new update in 2012: the ability to hide (or unexpose) user attributes.
For example, here the user has hidden a number of attributes that are unnecessary for their workspace. Only the required attributes remain exposed:
This makes the source schema, and all transformer dialogs, much clearer and tidier than if the entire set of attributes was still exposed.
Secondly, several of the key “AttributeXxxxxx” transformers have been given the same integrated functionality, and also other significant updates.
The AttributeCreator is a good example. With the updates for string concatenation and expression evaluation added to this transformer, it becomes the all-singing, all-dancing transformer of choice for workspaces in FME2012.
The key capabilities of this transformer are now:
- Manually Create an Attribute
- Set an Attribute Value
- Copy an Attribute
- Create an Attribute with an Editor
- Create an Attribute from a Parameter
For example…..
Here the user is carrying out several tasks, including creating an attribute, copying an attribute, and setting an attribute value to that of a published parameter.
The AttributeRenamer has had similar updates. In fact it can now:
- Rename an Attribute
- Copy an Attribute
- Delete an Attribute
- Create an Attribute
- Create an Attribute with an Editor
- Set Default Values for Copied/Renamed Attributes
- Import a Schema from another file/dataset
With these updates, the AttributeRenamer is now almost a mini-SchemaMapper. As our old friend the SchemaMapper dragon just said, it’s like him having a new child:
Ahhhhhhh.
Drawbacks?
Are there any drawbacks? Well, a couple.
Firstly if you embed attribute construction inside a transformer then you’re making the workspace as a whole less readable. Part of the attraction of Workbench is that it is self-documenting: you can print a screenshot of the workspace and pretty much understand what is going on and why.
If you hide key parts inside a transformer, then it makes for a more compact workspace, but one that is less self explanatory.
Also, if you construct a string or expression inside the operational transformer, you don’t have that string as an attribute to use elsewhere. For example, calculate a buffer size in the Bufferer and that calculation is restricted to the Bufferer; you can’t reuse the value as an output attribute.
However, we do hope to solve this latter issue in the near future. It might be that we can make expressions shareable, so they can be used and re-used in multiple locations.
Either way, there isn’t really a right or wrong method to constructing a workspace. Actually there are a lot of wrong methods, but the point I want to make is that you can choose whether to embed your attribute construction or not, and neither way is officially better than the other.
Nor is it compulsory to insert @Area() calls into an AttributeCreator transformer instead of just using the AreaCalculator. Both methods are available, and which you use is a personal choice of style.
To help users migrate to the new functionality we’ve created a training course called Mastering FME2012. In fact, the majority of this post is extracted from one section of that course.
This online course covers all of the important topics in detail and should be a sine qua non (sorry!) for any user wanting to get the most out of the latest FME.
According to our training calendar it’s being run on February 2nd, 8th, and 14th.
So sign up now, and I promise to stop using latin expressions in my posts,
Regards
PS – Safe is also running an ongoing contest for the next week or so. Prizes include a travel voucher, an iPad, a PS/3, and a daily prize of Indiana Jones DVDs. So go enter, and come back daily!
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)
