Question

Why use fme over python and arcpy?

  • 27 January 2016
  • 7 replies
  • 88 views
C
Badge

Hi guys,

I probably can say I'm at the point of being very confident with my skills in using python including libraries such as os, xlrd/xlwt, numpy, arcpy etc. I can create simple to complicated scripts, which can have simple line of codes, or several functions or several class objects and I can pretty much work seamlessly side by side with ArcGIS. In our office we have FME. I am finding it difficult to see any reason why I should use it over my pythonic process. I am thinking if only I encounter a very unique data format that python thru arcpy or another library cant read will I use FME to possibly do some translation. Other than that, any spatial operation I can fully use arcpy. But I don't want my boss to think I'm wasting our investment. I want to use it but cant find anything on the web that will convince me its a practical tool over things I can set up with python.

7 replies

david_r
Rank
Userlevel 4

Hi

I completely understand your point of view, but here are some (of my) arguments for not dismissing FME:

  • Maintainability: FME workspaces are often easier to maintain than scripts, especially if you're not the author of said script.
  • Self-documenting: The graphical layout of the workspace makes it easy to visualize data flow
  • Automation: publish to FME Server or FME Cloud to leverage existing workspaces in new ways
  • Format support: You already touched on this, the number of formats supported by FME is second to none
  • Speed: some operations are a noticably faster in FME than in ArcPy (granted, it goes both ways sometimes)
  • Efficiency: in many instances, inserting and connecting transformers in FME is a lot faster than authoring a script from scratch. This is especially true for prototyping a solution.
  • Support: never underestimate the importance of vendor support when you have a client/boss breathing down your neck and something doesn't work out of the box. The support given by Safe is amazing and it's among the best I've ever encountered in my entire career.
  • These forums for when you're stuck ;-)

There are sure to be other arguments as well, depending on who you ask.

David

redgeographics
Rank
Userlevel 5
Badge +25

Personally I prefer the FME Workbench interface over any programming language, but that's just my opinion of course. I think there is a large degree over overlap in functionality between FME and ArcGIS + Python and it quickly comes down to how experienced you are in using the solution you pick. If you're very experienced in using Python but a novice in FME and you need to deliver something on a tight deadline you're obviously going to use the solution that you're most comfortable with and that you know will deliver the results.

However, I think there are a few advantages to FME that you should certainly be considering:

  • Thanks to its flowchart-y interface a well designed and well documented FME Workspace makes explaining the process to other users very easy. The flow of data is easier to understand due to its graphical user interface.
  • FME currently supports almost 400 formats, so yes, you may run into one that you need to support that's not handled by ArcGIS and Python.
  • FME offers a number of ways you can inspect the data while you're setting up the process, making it fairly easy to debug.
  • Unless you have an extensive library of code fragments I would imagine an FME Workspace to be quicker to set up than a Python script. A single transformer can contain a lot of complexity and it;s just a matter of drag and drop to connect it.

And finally: you can have the best of both worlds. You can use Python scripts within FME, either pre- or post-translation, or within the process using a PythonCaller.

If you have some time to experiment I would encourage you to try FME for the next challenge you come across, or run through one of the training webinars if you haven't done so already.

Anyway, that's my take on it, I'm sure others will chime in as well.

C
Badge

thanks guys for the input, I understand all your points and I really appreciate it. I'll make it a goal this year to try FME first for my tasks.

C
Badge

btw you guys have both valid and good points so I will refrain from clicking "accept" from either of your response.

J
Rank
Badge +1

Like you @chrisp, I entered my current employment highly skilled in Python, minimally skilled in FME. I quickly found out that anything you can do in Python you can also do in FME, only faster. The learning curve for FME is much less than for Python and arcpy.

I would consider ModelBuilder "the poor man's FME". It is good in an ESRI-centric environment where FME is not available or developers don't have FME skills. However, FME does things easier than Python, and makes apps easier to maintain as well, as the other commentators have said.

Two years from now someone else may take over your applications. Will it be easier for them to learn Python and arcpy, or FME? I would say the latter.

You can also use Python within FME if you require such functionality, for example, connecting to an Oracle database in a Python startup script before the FME script itself executes.

bruceharold
Rank
Badge +16

The argument for visual programming environments like Workbench and Modelbuilder is they are (somewhat) self-documenting and easier for beginners. If you know Python you can often get performance gains by coding something.

Personally I like to inject Python into workbenches and Modelbuilder's Calculate Value tool, and cross pollinating the two environments like this.

erik_jan
Rank
Userlevel 2
Badge +16

@chrisp You can always try FME using the free evaluation and see how you like it.

Experiencing the user friendliness might convince you more than words from users that love the tool for almost 20 years now (like me).

This is where you can get a free trial: Safe Homepage

Reply


Community Stats

28,709
Posts
109,481
Replies
36,554
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.