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:

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?

About Data Data Formats Esri Geodatabase Interoperability Spatial Data Interoperability Spatial Databases

Paul Nalos


6 Responses to “File Geodatabase Gets More Open: Reflections on Esri’s File Geodatabase API”

  1. Pat says:

    Although the File Geodatabase is more open now, it is still based on a very old concept of having a geometry with some related alphanumeric data. With the format itself it is still not possible to have multiple geometry fields.

  2. Doug Newcomb says:

    I don’t think this will entirely satisfy the need for portable geodata. It would be nice to see more work on spatialite, . Multiple geometries per table is nice, I’ve used it in postgis for years.

  3. Paul Nalos says:

    Pat, Doug,

    I hadn’t considered the multiple geometry issue in this context, but you make great points. The ability to work with more than one geometry per row or feature is a clear advantage of formats like Spatialite or GML.

  4. […] Layers and Spatial Data Server, along with the recently released File Geodatabase API, continue a trend of increasing interoperability for basic geometric data within ArcGIS. Have these […]

  5. In other news, there is now a Python wrapper for the API:

    And an open source project to go with it:

    Joseph Armbruster

  6. Paul Nalos says:

    @Joseph: Indeed, this looks very useful. Thanks!

Leave a Reply

Your email address will not be published. Required fields are marked *

Related Posts