A Q & A on FME 2011

Directions Magazine (DM): It's interesting that the term "sidekick" is used in some of the marketing materials. Where does FME sit for most users on the continuum between a "sidekick" to a GIS or spatial database and being the key daily tool of choice?

Dale Lutz (DL): This is a very good question. We do know that for some of our users, FME is their key daily tool of choice. These would be people who are continuously distributing or aggregating data as part of their job – such a description fits a lot of municipal, state and federal GIS professionals, as well as many in the private sector. However, I'd guess that for the majority of our customers FME is a key enabling technology that lets them get past data integration issues quickly and on to their main job tasks in their GIS or spatial database of choice. Sidekick for many; #1 for some.
 
DM: Point clouds, the datasets from LiDAR collections, are a new supported data type. Was implementing them significantly different than any other data type?

DL: Actually, it turned out that point clouds have a lot in common with rasters. We like to say that point clouds are "misbehaving rasters" actually. It's a helpful way to think of it. It took us probably five years to get rasters integrated well into the FME framework - the high volumes and need to treat the entire raster as one object and to stack transformations on them in an efficient way all required a lot of R&D. We were able to reuse much of the framework and lessons learned from our raster implementation when we added point cloud support to FME. Both raster and point cloud are quite different from traditional CAD and GIS in terms of the mental model that needs to be created for manipulating them in a transformation environment like ours. One surprising chunk of effort for us was making sure that the "coercions" (or transfer between data types) to/from point cloud and other FME data types all worked reasonably and rationally - this allows us to easily combine raster and point cloud and vector and 3D in a single workflow, which opens up powerful options for our users.
 
I'd be remiss in not pointing out that the data volumes involved in point clouds also posed a significant challenge. Processing times tend to be longer for, say, clipping operations involving point clouds because you can't take shortcuts like you can with raster. We're very pleased with how it all turned out though, thanks to our very smart and talented development team.
 
DM: With this release FME Server supports REST services. Can you explain for non-programmers what that means and why it's important?

DL: We know that most of our customers want to include the power of FME Server in their existing Web applications. As such, we needed to make this as easy as possible. The biggest benefit to having REST for FME Server is the speed of deployment that this well-known style of Web development allows. With REST, you can simply use a Web browser to explore FME Server and discover the URL to any service or workspace and its parameters. Every service and workspace can be run using these discoverable and "bookmarkable" URLs, making possible very quick development and integration of FME Server into Web applications built on any framework. (For even more context, there's an article in the FME Insider newsletter - page 4 - that walks through our REST service support.)

DM: One new feature that caught my eye is Stylers for MapInfo, DGN and DWG. Do I understand correctly that these transformers will "assign" based on preferences which line styles, fills, text, blocks, etc. will be included in the output file? That sounds like a feature CAD users have wanted for some time. Is there a reason it appeared now?

DL: Yes, since 1995 FME has allowed users control over a variety of CAD display characteristics. However, it was always a bit hard to use. The success we had with making some KML stylers in the last release, together with user survey and FME format usage statistics, prompted us to make some nicer user interfaces for those people moving data from a spatial database or GIS to CAD (or MapInfo). The feedback from early beta testers has been very positive. We're just sorry it took us so long!
 
DM: I'm surprised so many of the newly supported formats are proprietary (or at least company specific): ESRIJSON, Google Spreadsheet, Microsoft Windows Azure and Microsoft Windows Azure OGDI, Pointools Point Database. Are new company specific formats going to be invented? Why or why not?

DL: This is an interesting observation. It does seem like companies continue to invent new formats - likely because the world continues to change and existing formats in some way constrain development or are otherwise unsuitable. It is interesting that we didn't highlight any "open" formats - we continue to do work on the latest flavors of GML and all its regional dialects, but perhaps that is just an expected part of what we do. We did begin to add support for Spatialite in this release, which is not company specific (we can read it), and will add writing over the next weeks and months.