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
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.
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.
btw you guys have both valid and good points so I will refrain from clicking "accept" from either of your response.
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.
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.
@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