Question

FME Form (desktop) best practices and style

  • 4 May 2023
  • 3 replies
  • 35 views
tva
Rank
Badge +10
  • tva Contributor
  • Contributor
  • 28 replies

Hi,

I was wondering if there are some best practices and or style guides / examples on for workspaces. Some questions that I have about this (besides the obvious: avoid crossing as much as possible, annotation, clear transformer names etc)

 

  1. Like is there an agreed style for public and private parameters (casing, under scores, ...)
  2. Is there an advise on how many transformers can be put in the main part and how many in a custom transformer?
  3. How many custom transformers can be nested into each other or is it advised to not do this to deep (performance impact)
  4. Any other good to implement styles?

3 replies

david_r
Rank
Userlevel 4

You'll find some topics covered in the (old) training manual, but it's by no means an official guide. I think most experienced users end up with some preferences and/or pet peeves, but tastes and preferences differ.

To answer your first three specifically, based on my own preferences:

  1. Parameters, public or private, are always UPPER case with underscores in my workspaces. That makes them easy to spot.
  2. I try to keep it down as much as possible (there used to be a standing joke about more than 3 transformers), but I've got no hard limit. However, I believe that an increased number of transformers merit an increased effort for annotations, bookmarks and a structure that is easy-ish to follow.
  3. Personally I don't like to nest custom transformers, but for no particular reason other than trying to keep things transparent.

I'm sure there are other users here on the community that can chime in with their own preferences.

jdh
Rank
Badge +22

You'll find some topics covered in the (old) training manual, but it's by no means an official guide. I think most experienced users end up with some preferences and/or pet peeves, but tastes and preferences differ.

To answer your first three specifically, based on my own preferences:

  1. Parameters, public or private, are always UPPER case with underscores in my workspaces. That makes them easy to spot.
  2. I try to keep it down as much as possible (there used to be a standing joke about more than 3 transformers), but I've got no hard limit. However, I believe that an increased number of transformers merit an increased effort for annotations, bookmarks and a structure that is easy-ish to follow.
  3. Personally I don't like to nest custom transformers, but for no particular reason other than trying to keep things transparent.

I'm sure there are other users here on the community that can chime in with their own preferences.

To contrast with David,

 

1. I prefer CamelCase for my parameters. I don't use a style difference between public and private. I do try and keep the names consistent between workspaces. ie OutRoot is one I use often for the Ouput Folder Root Directory.

 

2. Custom transformers should be based on functionality rather than number of transformers. If you don't need to repeat it (either within the same workspace or different ones), just put them in a bookmark and optionally collapse it. Ie keep the transformers in main, unless you are repeating multiple blocks of them.

 

3. As far as I am aware there are no performance impacts with nesting custom transformers (CT), but consider the pros and cons of linked vs embedded. If you use a linked CT, changes to it could break your primary CT, whereas going through and updating embedded transformers could be a real pain. I personally use embedded CT when nesting, but in my case most of these CT are "helper functions" for example I have a custom transformer that returns the unit of the feature's coordinate system because knowing whether it's in meters or degrees can affect the workflow.

I would try to avoid nesting custom transformers that access external resources.

 

4. Bookmarks are a good way to differentiate different sections. I often nest bookmarks, though it is rare that I collapse them. I know some groups colour code their bookmarks (data input, different types of processing , data output) but I don't with the exception of using red to indicate a section that requires user intervention before processing (we have a few cases where the workspace needs to be customized to the data in a way that is too complicated for published parameters)

 

Use the workspace parameters overview to describe the purpose of the workspace. Give a high level overview of the actual processing, either here, or as an annotation in the main workspace.

 

When creating custom transformers make sure that interim attributes don't override existing attributes. ex if using an areaCalculator make sure to change to output so that it is not simply _area which could easily already exist on the feature. I start all interim attributes with an !. Many prefer a unique prefix per custom transformer. Likewise make sure to cleanup all interim attributes.

 

Use junctions to help simply the lines.

 

I personally don't like to rename transformers, other than to occasionally change the numbering. I'll use an annotation if warranted.

 

 

 

 

caracadrian
Rank
Badge +20

Here we go! Best practices 2023:

1. NO. I use Camel Case for Parameters, writer dependent case for attribute names: all lowercase for PostreSQL, DWG, CamelCase for Geopackage, dot separator for Geopackage, underscore separator for GDB

2+3. I don't know! The deepest level I have gotten to is 3. I don't use custom transformers unless I must loop something. Somewhere in time Safe mentioned that collapsing bookmarks is better for memory usage than using custom transformers, so that is what I do.

4. I change the color and width of crossing connections; I don't use tunnels or hide connections unless I send something to production, and I want it to look clean and create space for annotations.

Reply


Community Stats

28,670
Posts
109,366
Replies
36,531
Members
Terms & ConditionsCookie settings
A product of
Safe Software respectfully acknowledges that we live, learn and work on the traditional and unceded territories of the Kwantlen, Katzie, and Semiahmoo First Nations.