Skip to main content
  • EN

The FME Community is often the first stop for new users who are just beginning their journey with FME. Whether you remember your first workspace or the “aha!” moment when FME finally clicked - we want to hear from you!

What advice would you give a new FME user just starting out? What do you wish someone had told you when you were just getting started with FME? Drop your best advice below!

New to the Question of the Week? 

Every week, we’ll post a simple but thought-provoking question that could be about your FME journey, the power of spatial data, FME innovation, or the future of FME.

Each weekly question you answer earns you an entry in our monthly draw for exclusive Safe swag ($50 value) and points toward badges!

Answer your first question and you’ll get the Socializer (Ice Breaker) badge. Answer five questions and you’ll get the Socializer (Talker) badge.

Two things that I always say as part of the trainings I run are:

  • Just try it, don’t ask ‘do you think this will work?’. Implement the logic, and understand what it’s doing. It might work, it might not, either way you’ve learnt something!
  • Give a problem to a room of FME users, and they’ll all come up with a different solution. Each will have its own advantages, and disadvantages. There’s not one ‘right’ solution. They’re all dependent on the circumstances around the problem. You may find solution A works well in this case. You’ll then have a similar, but slightly different problem, and solution B works better than solution A.

With respect to the latter point, there’s a practice called CODE GOLF: “a type of recreational computer programming competition in which participants strive to achieve the shortest possible source code that solves a certain problem.” (thanks Wikipedia)

I feel like once you start getting comfortable with FME workbenches, try FME GOLF: shrink your workspace into the minimal amount of transformers that runs the fastest. Sometimes it’s as easy as throwing an Attribute Manager in the mix, or learning how to use SQL WHERE statements in your feature readers ;) 

Two things that I always say as part of the trainings I run are:

  • Just try it, don’t ask ‘do you think this will work?’. Implement the logic, and understand what it’s doing. It might work, it might not, either way you’ve learnt something!
  • Give a problem to a room of FME users, and they’ll all come up with a different solution. Each will have its own advantages, and disadvantages. There’s not one ‘right’ solution. They’re all dependent on the circumstances around the problem. You may find solution A works well in this case. You’ll then have a similar, but slightly different problem, and solution B works better than solution A.

With respect to the latter point, there’s a practice called CODE GOLF: “a type of recreational computer programming competition in which participants strive to achieve the shortest possible source code that solves a certain problem.” (thanks Wikipedia)

I feel like once you start getting comfortable with FME workbenches, try FME GOLF: shrink your workspace into the minimal amount of transformers that runs the fastest. Sometimes it’s as easy as throwing an Attribute Manager in the mix, or learning how to use SQL WHERE statements in your feature readers ;) 

I do like that concept, and often aim for that myself.

Like a lot of things, I do find the context of the end process to determine to what extent I build with that in mind.

If I was building an internal process that was going to be maintained by myself or colleague (we’re resellers of FME) I would use more advanced techniques that will make the process more efficient, smaller etc.

However if the process was being delivered to a client where FME was a tool they used to help achieve other outcomes, I may not utilise some of the more advanced functionalities to ensure the process is easy for them to maintain and manage going forward. Of course, situations like this are valuable learning opportunities so I try to gauge whats appropriate for the client.

A couple of good examples are:

  • WHERE clauses and spatial filtering on (feature)readers - A lot of beginner users may not realise or understand the advantages of this approach
  • SQL Joins - I’m not an SQL expert, but can work my way around a join. Whilst is may be more effcient to use an SQLExecutor to join some tables and then read the data, it may be easier for the end user to maintain a process that uses (feature)readers and a FeatureMerger/Joiner

Sign up for the free training and don’t be afraid to try things or ask questions

Community Stats

31,939
Posts
121,304
Replies
39,555
Members

Latest FME

Terms & ConditionsCookie settingsAccessibility statement
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.