Skip to content

File Geodatabase Gets More Open: Reflections on Esri’s File Geodatabase API

For a number of years, a small but vocal community has asked Esri to allow developers to access data in File Geodatabases without requiring an ArcObjects license. That dream came...

File Geodatabase APIFor a number of years, a small but vocal community has asked Esri to allow developers to access data in File Geodatabases without requiring an ArcObjects license. That dream came true in June, with the release of the File Geodatabase API. The upshot for users: the ability to import, export, and access data in File Geodatabases in more applications at lower cost.

This fits well with our own goal of breaking down barriers between you and your spatial data, and we’ve long committed to supporting the API when it came available. That effort isn’t quite done — partial support is available in our beta — but I thought it would be interesting to share some of our experiences. These comments are based on version 1.0 of the API; the recent 1.1 release was primarily focused on adding .NET.

Limited Data Model

While the Geodatabase data model is very rich, the API exposes only a limited subset. In particular, geometry is limited to lines and polygons, potentially with curved segments, along with points, multipoints, and multipatches (3D surfaces). As far as we can tell, only untextured multipatches are supported, but that may be resolved in future. A large, fixed, set of coordinate systems are supported; data in other systems isn’t readable at all.

Many of the richer, vector-based types are transparently converted to supported ones, with mixed results. For example, parcel fabrics are cleanly presented via their component parts, but annotations are read without useful positioning information (their geometry is read as the polygon union of their bounding box and leader line).

Relationship to ArcGIS Runtime?

Esri introduced the ArcGIS Runtime, planned for ArcGIS 10.1, at the Developer summit this year. ArcGIS runtime represents a new option for creating and deploying applications based on ArcGIS. Similar to MapObjects, the focus appears to be on easy development and deployment of high performance, map centric applications.

There are a number of unknowns, but it might be possible to get rich, read/write access to all kinds of Geodatabase data via this new library. If so, it would provide another alternative. We’ll be watching with interest: Can ArcGIS runtime be used non-interactively? How will it be licensed?

Unseating Shapefile as the Interchange Format of Choice?

There’s been a lot of discussion around demand for a better GIS interchange format than Esri Shapefiles, with suggestions that Spatialite or File Geodatabase may be the way forward. While our view is that no one spatial format can fit every need, it’s clear that Shapefiles have been tremendously successful for basic spatial data interchange. A few observations:

  • Interchange vs. direct use. Some formats, like GML or WKT/WKB, are focused on interoperability and are typically exported from one system and imported into another. Other formats are designed for use in applications directly; database-based formats, like File Geodatabase and Spatialite, add to this scalability and efficient querying. Interestingly, with its performance focus and open specification, Shapefiles fit solidly into both camps. (It’s worth noting that the current File Geodatabase API doesn’t do efficient spatial queries, but I’m sure that will change soon.)
  • Open specifications vs. free software. One of the reasons for the success of Shapefiles is their open specification, which has made it easy for many software packages to add support. For File Geodatabase, Esri has chosen to distribute an API instead of a spec. One advantage of this approach is that it makes incorrect or incompatible implementations less likely. However, it may reduce the format’s attractiveness as an interchange format. Minor example: Is it a big deal that only Windows and Linux are supported?
  • Richness of the model. There’s a trade-off between complexity (representing richer GIS data) and simplicity (easier to integrate into different software packages). Viewed through the API, File Geodatabases strike an interesting balance: Only basic geometry types are available, but you’re given a narrow view into the richer, full Geodatabase model.

Now it’s your turn. As GIS tools start to take advantage of the new API, do you expect to share more data via File Geodatabases? When you want to publish or share spatial data, what’s most important to you?

Safe product icons
Reach out and get started with FME today

Real change is just a platform away.