Command Line Tools Integration

Liz Sanderson
Liz Sanderson
  • Updated

FME Version

  • FME 2016.x


A powerful pair - FeatureReader and FeatureWriter (new in FME 2016) - allows a simple integration of third-party command line tools into FME.

Any tool, any library that is able to read, process and save data in formats supported by FME can become a part of an FME workflow. For better usability, such external tools can be wrapped up into a custom transformer, so a user deals only with a familiar FME interface with no need to know any of the complicated syntax details a tool requires.

A general workflow for such an integration looks as follows. Note that most components depending on the workflow can be skipped (shown in blue). The only required parts are assembling a command line and executing it (shown in red).


Here are the three most common scenarios:

  1. Custom Reader transformer. A command line tool can read some format not supported by FME. The custom reader collects parameters from a user, makes a command line, executes it, and reads features with FeatureReader. Then, the features leave the transformer as if they were read with any standard reader. Users can then transform it and write it out to any of FME’s 350+ supported formats. See SVGReader example below.
  2. Custom Writer transformer. A command line tool can write a format not supported by FME. After gathering the parameters and saving FME features to a temp file, the transformer assembles a command line and executes it on the temp file(s). The results go to a user-specified location, as they do with any normal FME writer. See AnimatedGIFWriter example.
  3. Custom processing transformer. A command line tool can transform data in a way not available through standard FME transformers. With parameters set by the user, the data is saved to a temporary location with FeatureWriter, then the transformer makes a command line, executes it, and reads the processed features with FeatureReader. See LAStools_lasground_Caller example.

Components of the Integration Workflow

Each of the steps in the integration workflow diagram above are described here.

1) Gathering parameters

When a command line interface is replaced with a transformer GUI, it makes sense to create parameters that look user-friendly: instead of short options, use their expanded descriptions. A “Choice with Alias” user parameter allows showing such descriptions while the parameters get values that can be used directly in the command line.

Here’s how such a parameter may look within a command line:


Within the Edit Choice dialog:


and in the transformer’s GUI exposed to the user:


Some parameters may need additional processing. For example, we may need to recalculate a normalized color set through the FME “Color Picker” (for example, “1,0.5,0.25”) to RGB24 representation (255,127,63). In this case, the parameter can be fetched with ParameterFetcher, split into R,G, and B parts with AttributeSplitter, and assembled into required string with AttributeCreator. See SVGReader below for more details.

The path to the external tool may or may not need to be published as a parameter. For using a custom transformer within an organization, it might be better to hide the path from inexperienced users within the command line of the transformer. An FME professional will have to take care of setting the transformer up. If a tool is going to be shared across organizations (through FME Store, for example), it is better to publish the path:



2) Reserve temporary file names

While it is possible to generate unique names for temporary input and output files using regular FME transformers, it is more reliable to use a special TCL command within TCLCaller transformer. The syntax of the command looks as follows:

FME_TempFilename <file_name_prefix> <file_name_suffix>

It creates an empty file with a unique name in the FME TEMP folder.

For example, if we would like to make a temp file for using one of the ImageMagick utilities, we can write the following TCL expression:


The expression will generate a name similar to this:


Now this name can be used for making a command line, setting as transformer parameter and filling the file with some contents.


3) Save data with FeatureWriter

Depending on a workflow, it may be necessary to save the intermediate files to some temporary location or use the source files directly. For example, when we use LAStools for ground classification, we may first clip the area of interest and classify only this part of the original point cloud. Another example is when the source format is not supported by LAStools. In these cases we need to make the temporary LAS files.

Using the file name reserved with TCL command (see above) and FilenamePartExtractor transformer, we can create attributes specifying path to the temp output dataset and the root name for the file:


After that, it’s easy to use these attributes within FeatureWriter:



4) Assemble and execute command line

The command line can be written directly in the SystemCaller transformer or made with AttributeCreator as an attribute, which then will be used in SystemCaller.

The command line should include:

  • the full path to the program,
  • all the user parameters either “as is”, for example, “$(DELAY)” or made into attributes with ParameterFetcher or AttributeCreator (@Value(_frame_delay)), and processed if necessary,
  • the path to the source data - temporary or original,
  • the path to the destination data - temporary or final.

Here is a couple of examples:

“"$(IMAGEMAGICKCONVERT)" -delay $(DELAY) @Value(_ImageMagick_sequence_file) -loop $(LOOP) $(GIFOUTPUT)”

""$(LASTOOL)" -i "@Value(_input)" -o "@Value(_lastools_temp_output)" -scale_u $(HEIGHTSTORAGESCALE) $(HEIGHTSTORAGE)"

Always make sure the paths in the command as well as the whole command have double quotation marks around them - this helps to avoid potential problems with some characters in paths, such as spaces.

In some situations, the assembled command line may become too long exceeding the allowed limit. On Windows, the limit is 8192 characters. There are a few possible ways to work around this limitation. For example, instead of listing all the files in a command line, it is possible to use a wildcard, see AnimatedGIFWriter example. Or use shorter names for folders and files by choosing FME_TEMP folder location closer to the root. For example, instead of C:\Users\username\AppData\Local\Temp\, use E:\FME_TEMP\

The assembled command line attribute goes to SystemCaller, which executes the process and waits for results before continuing with other parts of the workspace. The external tool may also report back to the log window the status of the job or error messages.


5) Read Data back with FeatureReader

Once the external tool finishes its job and makes some output, FME can bring the output back with FeatureReader for further processing. In some cases, it might be necessary to merge the processed data with the original.

For example, the point clouds in formats not supported by LAStools may need joining with the processed data for preserving the original components. This can be done with PointCloudMerger by X, Y, and Z of both the source and processed point clouds.


6) Remove temp files

After the external process finishes, and the data is brought back to the normal FME workflow, we may need to remove the temporary files. It is possible through the OS commands, such as “del” in SystemCaller, for example:

del "@Value(_lastools_temp_input)" /Q

In some situations when dealing with point clouds and rasters, it is more reliable to issue the following FME command with FMEFunctionCaller:



This transformer can be placed right after reading the geometry or later - in any place where the geometry of the feature still exists. The transformer removes the temp file as soon as it is not needed anymore-for example, if its geometry is destroyed in the FME workflow or the translation ends.

Note that both OS “del” command and the @Geometry(DELETE_SOURCE_DATASET) function should be used with caution to avoid deleting the original source data or temporary files before or during their use by an external process.


Note on Customization

The general integration workflow described in this article does not have to be placed into a custom transformer. Creating such a transformer, however, makes it easier to separate the task accomplished by an external tool from the main workspace. It is easier to debug, update or modify a single custom transformer than the whole workspace, which can be really big and complex. All the examples shown here can easily be modified by right-clicking the custom transformer and choosing “Edit”. The transformer will open in a new Workbench tab. Learn how it works and feel free to change it the way you need it - add or remove options, change the tool performing the transformation, translate the parameters into a different language, or chain a few tools together into a single transformer if this makes sense in your working environment.



Example 1: SVGReader

SVG (Scalable Vector Graphics) is an XML-based vector image format for two-dimensional graphics with support for interactivity and animation. FME supports writing SVG files, but not reading. We can read SVG files as rasters using ImageMagick, a free and open-source software suite for displaying, converting, and editing raster image and vector image files. It can read and write over 200 image file formats.

Note that ImageMagick is not a part of FME. You can download your copy of the product from here -

The SVGReader custom transformer allows reading one or many svg files and bringing them into FME as rasters with FeatureReader. The raster(s) then can be stored in any supported raster format. Note that some formats may require adjusting their raster interpretation (See RasterInterpretationCoercer). FeatureWriter is not used in this custom transformer.

It is also worth noting how we set the color and transparency of the background - the parameter is set as a normalized FME color, and then changed to ImageMagick rgba model with AttributeSplitter and AttributeCreator:



Download the template:svgreader.fmwt


Example 2: AnimatedGIFWriter

Another example using ImageMagick. AnimatedGIFWriter expands FME’s writing capabilities by adding animated GIF support.

Using FME allows much easier creation of the georeferenced animations, for example, driving maps.

The workspace example shows how to pass the background extents to the moving parts of the animation so a user does not have to calculate the location of the rasterized features in the animation.

The custom transformer uses FeatureWriter to save the background and all the animation frames into temp PNG files. ImageMagick assembles them into the GIF.


FME 2016 does not support animated GIFs, so it makes no sense to read the file back and display it in Data Inspector. The easiest way to see the animation is through a web browser:


Download the template: work2home.fmwt


Example 3: LAStools_lasground_Caller

The popular LAStools software suite is widely used by many organizations for processing LiDAR data. For FME 2016, we made several custom transformers that wrap up a few LAStools instruments.

Note that LAStools suite is not a part of FME. You can download your copy of LAStools from For pricing and licensing information, visit and

LAStools_lasground_Caller calls lasground.exe, which classifies points as ground and non-ground.


In this example, FeatureWriter is used when the source file was changed before entering the transformer, or the source point cloud format is not supported by LAStools. In these two cases, the temporary LAS files are created in the TEMP folder and lasground.exe runs on these files, otherwise it works directly with the source files:


FeatureReader is always used to bring the results generated with lasground.exe back to FME.

An interesting part of this workflow is merging the original point cloud with the generated LAS files. If the source has components that are not supported by LAS, they will be lost after lasground.exe finishes its job. PointCloudMerger allows combining the original point cloud with the results by X, Y, and Z:


Note that merging by XYZ will not work if a tool changes one of these components.

Download LAStools wrapper transformers:

Download the template (contains the workspace with 5 LAStools wrapper transformers):lastoolsdemo.fmwt

Was this article helpful?



Please sign in to leave a comment.