ESRI Formats - Back to the Future?
07 Apr 2009
Remember when “coverage” was the holy grail? “Boy, if I could just read/write coverage, I could interoperate with the GIS folks no problem.”
And then things seemed to get better. Most data was in “shape files” and there was a published specification which more-or-less matched the data generated by the ESRI tools. And lots of folks were using ArcView, so you could share “avl” files (layer style) and “apr” files (project file) and even write third-party tools to consume them directly (they were just a funny text format after all).
And now they are back-sliding. Layers and projects are “lyr” and “mxd” binary formats generated by ArcGIS and not consumable by third party tools. Data is starting to be moved into “file-based geodatabase” (FGDB) and the only tools that can peer into those are Arc*. (The old geodatabase had a lot of drawbacks, but at least you could open it in a third-party tool.) There are no specifications for the data formats, for the layer formats, for the project formats.
I thought we in the computer profession had this discussion and came to a consensus: vendors that tried to use proprietary file formats as a lock-in were to be avoided if possible and castigated if necessary. Even old Microsoft had to play the “open format” game, at least in mixed company.
It’s not just data, though the rise of the closed FGDB format over the last couple years is bad enough. The “metadata”, the style files and the project files, are a key piece of “operational data” that can be incorporated into workflows automatically – if you can read and write them. With format lock-in in place, the only way to automate your work flows is through the vendor-approved channel.
Really, I thought it was decided – they don’t get to do this to us anymore.
