Open File Geodatabase

    Table of contents
    No headers

     

    [Some time in early 2008] In the Q&A from the 2007 ESRI User Conference Jack Dangermond said that an API for accessing file geodabases will be published after ArcGIS 9.3 is released. This means at least 6 months from now, more likely 12 in my opinion (so winter 2009). I asked ESRI Canada for more information. This is their response:

    "There is in fact a NIM number for the enhancement request to provide open API to allow access to File Geodatabase data without ArcObjects. For your records, the number for this enhancement is NIM010509. As of right now, there is no planned fix specified for this enhancement request, but you can use the tracking number I gave to you to see any advancements that have been made for this issue. "

    You won't find this number on any ESRI web pages, but ESRI customers can use it to ask their customer service representatives for updates (and please do so, that is one of the ways the gauge interest).

     

    [Spring 2010] Anybody who has been following this story will be able to tell you my pessimisstic 1 year estimate above was atcually over-optimistic, make that very over-optimistic. At the local ESRI-UC last month I asked again about this and was told by ESRI Canada that yes the API is still coming, perhaps this fall, and no, they still don't know if it will be license free or if developers who want to use it will be tied to some sort of arcgis runtime. Furthermore it is also likely to be C++ only. This does not look promising for those of us who want to share data freely with all types of GIS users and not suffer the limitations of shapefiles. Maybe it's time to take a deeper look at Shapefile 2.0.

     

    An interesting thread on the gdal mailing list right now where Matt ended ranting about why this is important. Here's an excerpt:

     

    "While ESRI would ideally like to open the file geodatabase format in a manner similar to what we did for shapefiles when we released ArcView 2, geodatabases are complex and can be easily corrupted outside the ArcGIS environment."

    It is perfectly correct to say an f-gdb is easy to corrupt outside of ArcGIS, as are both coverages and shapefiles. All three consist of many components visible in the filesystem and messing with them is an invitation to breaking things. Since the f-gdb has many more pieces than it's predecessors it has a corresponding, and non-linear, increase in the number of potential failure points. That said, it's convenient for ESRI to use that as a shield to not be more forthcoming; they have a lot to gain.

    ...but by the other hand, to develop and maintain the API would also be costly. So why should they do that? To give to the world a new free format so that people could use it without an ArcGIS license?

    The should do it because their customers need it to conduct their work as smooth and efficient manner as possible. It's about being free to use the best tool for the job at hand.

    It is true that many, myself included, would take the public spec and use it avoid buying more licenses. However I, or rather my employer, also own and maintain dozens of ESRI licenses, as well as Global Mapper, ERMapper, PCI, Manifold, and others, and have done so for many years. We desire and expect these and other applications to interact with each other with a minimum of hassle. I and my colleagues should be spending our time analysing and making maps and not packaging and re-packaging and re-packaging the same bits from format to format for task X that Y program does better than Z.

    I'd also like to point out that not having a straight route for data exchange makes it just as difficult get information into  the ESRI toolchain as it does to get it back out again. I like Arcmap. For cartography there is no other product that comes even close. When it comes to large volumes or repetitve cycles of data conversion though, it's gdal/ogr all the way.

    ...hmmm, I seem to have ended up in rants-ville without meaning to go there. And the ears that really need to hear this probably aren't in the room anyhow. Better stop now and get to analysing some data instead of carrying on. :)

        Send feedback