Open File Geodatabase

    Table of contents
    to the older version or return to version archive.

    Combined revision comparison

    Comparing version 14:44, 9 Jun 2010 by matt with version 13:48, 11 Jun 2010 by matt.

    ...

    [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:

    ...

    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. :)

    Version from 14:44, 9 Jun 2010

    This revision modified by matt (Ban)

    ...

    Current version

    This revision modified by matt (Ban)

    ...

    [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:

    ...

    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