If you use Python within FME, then the updates we’ve made to FME2012 should be very, very useful to you. Python support has finally come of age – Python II you might say – and is now a fully-fledged member of the FME Objects family. This brings many improvements and benefits, as I’ll detail below.
NB: The title “Python II” refers really to this being a major upgrade to FME Python support, not any particular Python release. It’s also a play on the film Python II, whose tagline – by the way – is “The Beast is Back!”. My favourite Python-titled movie is actually “Police Python 357”, a French cop movie that really could cause confusion (What! You’re using Python v3.57?!)
Of course, if you’re not a Pythonista you might always have wanted to be, in which case I’m going to write a follow-up post that includes an example showing how even the most inept programmer (me) can use Python to do awesome things.
If not, and the terms Python, open-source, and Killer Rabbit are really a closed book to you, then you can both educate and entertain yourself with this video clip.
A New API
The first thing to note is that Pyfme – the old interface between FME and Python – is no more; dead, deceased, deprecated. Actually that’s not exactly true. We want to maintain backwards compatibility, so any Pyfme scripts you had in previous versions will still run in 2012. However, from now on you’re encouraged to use the new FME Objects API for Python.
The new Python FME Objects API has several advantages over Pyfme, including enriched FME Objects coverage, detailed API documentation, and improved help documentation.
FME Objects Coverage
Our original Pyfme interface never included the full spectrum of FME Objects capabilities. For example, it covered the central interfaces like session, feature, etc, but not all FME Objects.
The new API extends the FME Objects coverage. Although not full you do now have Pythonic access to rich geometry including FMEArc, FMEDonut, FMEPath and FMEText. For the full list of supported interfaces, check out the documentation. Speaking of which…
The API documentation for Python in FME2011 was – we admit – not great. That’s probably why so many people were grateful to the wonderful Oliver’s Python Corner on FMEpedia.
In 2012, having upgraded Python to a full member of FME Objects, we can now provide detailed API documentation including descriptions for the methods, parameters, return values, and the possible exceptions that may be thrown.
If you have FME 2012 installed, and provided you clicked the option to install all SDKs, you can find the new documentation within your installation folder at: <FME>/fmeobjects/python/apidoc/index.html (click image to enlarge):
We’ve also updated the help documentation that is part of Workbench, and improved the sections that relate to Python. Check out the help for the PythonCaller and PythonCreator transformers and you’ll see that it is more comprehensive than before. We’re also adding more Python-related content to FMEpedia, and added new samples to the FMEObjects folder in your installation.
So, if you are moving from pyfme to the new API, what do you need to know?
Firstly, if obviously, the opening line for new scripts won’t be “import pyfme” it will now be “import fmeobjects”
Secondly, all attributes are now added through implicit typing to remove the need to keep track of the attribute types, for example in 2011 you would need to use an explicit type:
Whereas the simpler 2012 method looks like this:
Thirdly, we’ve improved the parameter passing structures to have a more standard Python feel, such as using tuples for points. For example, instead of using this technique to create a line feature:
# Create a feature. feature = pyfme.FMEFeature() # Explicity define the geometry on the feature. feature.setGeometryType(pyfme.FME_GEOM_LINE) # Add points to a feature to create the geometry. feature.addCoordinates(xCoordsList, yCoordsList, zCoordsList)
Instead we would use:
# Create a feature. feature = fmeobjects.FMEFeature() # Create an FMELine geometry. line = fmeobjects.FMELine() # Add points to FMELine as tuples of coordinates. coord1 = (0, 100, 0) coord2 = (500, 100, 0) line.appendPoints([coord1, coord2]) # Set the geometry on the feature. feature.setGeometry(line)
I’m told the basic idea is to make the use of the API as simple and intuitive as possible.
Other Python Updates
Besides the upgrade to the API, there are many other useful Py-updates.
Python Interpreter Option
FME2012 includes an option (under Tools > FME Options) to set a different Python interpreter:
There’s a whole page on FMEpedia devoted to this option and why you might want to change it. In brief, you may want to integrate FME with the interpreter from a different package (e.g. ArcGIS) or need to integrate with a 3rd-party module that doesn’t work with the latest FME interpreter.
Incidentally, the version of Python FME installs is (at the time of writing) v2.7. The follow-up post I plan to write shows an example of using a v2.6 interpreter in order to integrate with MapNik.
Just be aware that if you do downgrade to a v2.3 or v2.4 interpreter, you’ll be stuck with Pyfme. The new API only works with v2.5 or greater.
Python Transformer Updates
The PythonCaller and PythonCreator transformers have also had a bit of a makeover for 2012.
Though small, a useful addition is the “Attributes To Expose” parameter. Often your Python script will create new attributes. Because FME doesn’t know what they will be, it can’t show them in the workspace. So this parameter lets you expose attributes within the same transformer that you’ve just created them.
Code Editor Updates
Open the code editing dialog and you’ll see a few new changes (click to enlarge):
Not only is there the ability to highlight a script in different ways for different languages, there are options for line numbers and – importantly for Python – spaces and tabs. Python uses spaces to properly layout a script, and this option will convert tabs to spaces automatically.
Did you notice the content of the script in the screenshot above? That wasn’t something I added; it’s a template that’s now included to provide a head-start on putting together a correctly structured script.
Using Python: Some Tips
Finally, let’s have a quick look at some tips for using Python with FME.
PythonCaller vs PythonCreator
The PythonCaller transformer is for when you want to run the script for each incoming feature. That’s why it has input and output ports. The PythonCreator only has output ports. It is intended for users who wish to create features within their Python script. It only gets run once.
To store a Python script globally use the “Startup Python Script” property within the “Advanced” tab of the “Workspace Properties” in the “Navigator” pane. You can put your script into there and use it from anywhere within FME.
Storing scripts globally has the advantage of keeping your Python logic centralized, which makes editing and maintenance easier. This is useful if you want to have multiple PythonCreator transformers throughout your workspace using the same script.
Feature-Based or Group-Based Processing
The PythonCaller can interface with a Python script in two different ways: via a function or via a class. Use the Function Interface when you intend to process a single feature at a time; i.e. each feature runs through the script. Use the Class Interface for more flexibility, when you want to run the script just once for all features.
The follow-up post I’m planning shows an example of this.
I hope you Pythoneers found this post useful. If you have any further questions, please don’t hesitate to let me know, and I will get an answer from someone who understands the subject!
But whatever you do with FME Objects, don’t forget IFMEWorkspaceRunner, an interface to let you run Workbench-created translations programmatically. It means you don’t have to reinvent the basic components of FME in your code, but can take advantage of the ease of use offered by FME Workbench while still creating a standalone solution.
Mark IrelandMark, 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)