As I write this I am on my way to talk about the release of FME 2008 that we just announced yesterday. As I reflect on this release, I am filled with great excitement about what the Safe team has achieved. This is a monumental release for many reasons. Thinking through it, a stream of thoughts compete in my mind: things like CADRG Writing, FME Server, 3D, BIM, Object Data and enhanced database support.
With the addition of 3D/BIM to FME, I see a common pattern playing itself out. Over the past decade we have seen a great progression of spatial data types. For each of these types, we first encountered them in file based systems and then later in databases. This was the pattern for vector, raster and 3D data types within FME. The thing that is surprising is that the amount of time between us embracing a new data type and the time before we supported it in a database has dramatically changed. The time between us supporting vector files and databases was measured in about a year; the amount of time for us to support raster was measured in months and the time to support 3D in a database was measured in weeks.
While the addition of 3D data to FME is very exciting to all of us at Safe it is in fact just a logical evolution of us building the only complete spatial ETL tool. It is safe to say (no pun intended) that 3D/BIM data is merely the expansion of data from the “macro” to the “micro” or from “exterior spaces” to “interior spaces”. What is truly exciting is what our users are going to do with this new type of data once it is able to move freely from application to application using FME.
With this release we have also pushed the number of formats that FME supports to well beyond 220. This got me thinking back to the early days of FME (circa 1995) when we focused our messaging on the format aspects of FME. In retrospect I think that we have been too successful doing this as even to this day many people think of FME as the format conversion tool and Safe as the format people. Of course, formats are still a part of the solution that FME provides as format support is necessary, though not sufficient, for effective communication of spatial data from one application to another. I often tell a story of my first trip to the UK where I learned first hand that format is not enough for communication and data model is really the key thing. In that case the “data” was electricity, the data format was the big UK plug, the data model is the mismatch between Canadian electric voltage and UK electric voltage. During that data model lesson a poor hair dryer paid dearly.
As time has moved on over the years, what we mean by the word “format” has evolved as we have moved from a file centric world to an application centric world. Here is the format definition from an FME perspective:
Format: A “data endpoint” that can be represented by anything that can store, consume or produce data. This includes but is not limited to files, databases, applications, devices, sensors or web feeds.
Looking forward we are now referring to the work we do as “Powering the flow of spatial data.” The more I reflect on this the more I like it. Another change is that we are stepping away from spelling out the words “Feature Manipulation Engine” since it is a mouthful. Looking at the new slogan I see how this too has evolved and how the acronym and it’s the vision for the product are as relevant as they always have been.
First, Feature is a word we use to mean “data”. This is what flows through the data pipe that is FME. If I was asked what F stands for I would have to say that F now means Format. See above how we define format. When you think of FME of course we want you to think about Format even though it is not our focus.
Second, Manipulation is a word that means the same thing as transformation. Back in 1995 when my good friend Dale and I came up with the product, it had a focus on model manipulation right from the start. Indeed when you think of FME think of its Manipulation (now called Transformation) capabilities.
Third, Engine is a word that we use to mean “Powers data movement”. After all what engines do is create power for moving things and doing work. Just as an automobile engine powers the movement of people and cargo we power the movement of data. This coupled with the continually growing support for formats and the transformation capabilities of FME results in something that we and our users are really excited about.
To truly appreciate FME, you must experience it for yourself. I encourage anyone who isn’t fluent with FME to download our tutorial and experience the wonderful things that can be done once you have an engine that unleashes the flow of your spatial data from wherever it is to where you need it. Not just where you need it but where you need it in the data model that you need it in.
Now imagine if you could provide that data model transformation capability to users both inside and outside your organization with just a couple of clicks within FME Workbench, and you start to understand why we are so excited by the launch of FME Server.