One of the frequent questions we get asked are what file formats will GeoCommons support in the future. Currently we are working on adding GeoRSS, KML network links and KMZs. The big push with these file formats is to allow dynamic data to be added to GeoCommons, which we think will open a lot of new possibilities for what you can do with both analysis and data visualization. The question we’ve been kicking around recently is what other data formats make sense to provide support for?

In a couple of presentation we’ve gotten the question if GeoCommons will support ESRI “personal geodatabases” or “file geodatabases”. For those who have fallen behind in their kool aid consumption:

File Geodatabases—Stored as folders in a file system. Each dataset is held as a file that can scale up to 1 TB in size. This option is recommended over personal geodatabases.

Personal Geodatabases—All datasets are stored within a Microsoft Access data file, which is limited in size to 2 GB.

My quick assessment is that the “personal geodatabases” would be possible since it is a single file in a well known format. Unfortunately from what I’ve read and heard ESRI is pushing folks to adopt “file geodatabases”. The expanded storage size and versatility seem like solid advantages, but what I’ve not been able to sort out is data portability. More specifically if I have my data in a “file geodatabase” how do I load it into other applications outside the ESRI stack. We happened to be at the GeoInt conference last week so we stopped by the ESRI booth to ask. After a bit of confusion as to why we would want to load the data into another application the answer was that we needed to use the “interoperability extension tool“, although it would make a lot more sense to use ArcGIS Server and expose the data as a web service through it.

Both are very clever ways to sell more ESRI product and there is nothing wrong with that – it pays the rent. It does create a bit of a conundrum as to what is the best way to support data portability for traditional GIS data outside of shapefile support. Digging through the ESRI online help there is the suggestion of using “geodatabase XML” which has an open specification. It looks promising, but I’m just not so sure many users are going to dig through a 46 page specification to make their data portable.

Jame’s Fee has brought up this conundrum under the idea of a “GIS interchange file“, which would be a no-brainer to support. In its absence I’m wondering what the community would like to see supported. Are geodatabses worth the effort? Would support for an OGR driver make more sense to allow direct database dumps into and out of GeoCommons? Possibly support for SpatiaLite? Does someone need to push a data interchange standard with the OGC? Is there already one that I do not know about (no I don’t really see GML as that)? Any and all suggestion would be greatly appreciated.


15 Responses to File Format Support in GeoCommons – Do Geodatabases Make Sense?

  1. Bill says:

    Random plug: When I needed pGDB support, I found that FDO’s .NET wrappers for OGR to be arguably more useful than querying the Access tables directly. The API ain’t pretty, but it gets the job done.

  2. jubal says:

    FME or FME Server from Safe would achieve just what your trying to do. The interop tool from ESRI is just a wrapper for FME anyway. We’ve been using it quite happily for a while to push out both files, network links and SQL.

  3. Simon says:

    A way to link to my existing PostGIS database would be delicious…
    And yes, FME is great for conversions.

  4. Jason Birch says:

    I hate it when I get almost done a comment and then accidentally close the browser :)

    Currently, there are two specifications for storing spatial data in a SQLite database: the one used by Spatialite, and the one shared by OGR and FDO.

    Discussions are ongoing between Alessandro Furieri (Spatialite), Frank Warmerdam (OGR), and Traian Stanev (FDO) to see if a common specification can be shared between these three implementations.

    I hope that this works out, because supporting a format that can be used by a majority of open source users and many proprietary users (for instance, ArcGIS via Data Interop Extension or FME, AutoCAD Map, etc) would indeed be a no brainer…

  5. Sean Gorman says:

    Thanks for all the feedback – a common specification for SQLite would be great and definitely something that would be worth supporting. Also still a fan of an OGR driver as well. We’ll have to look at FME again as an option although like everyone else having to tighten the belt lately. Please keep firing any other suggestions that would be useful to support.


  6. GDAL/OGR support would definately be great. If a format is not (well) supported you can always contribute it and more people will profit from the contribution.
    Aside from that: my compliments for the GeoCommons apps!

  7. Jarlath says:

    Given the fact that a lot of people are or will store their data in file geodatabases, my thinking is that supporting file geodatabases increases the ease of uploading data to GeoCommons.

  8. Patrick van Dijk says:

    It’s a shame ESRI decided to create a new file Geodatabase format and not provide either an API or Documentation.

  9. matt wilkie says:

    Patrick: ESRI has said an API for for file geodatabases is coming “after 9.3″,

  10. […] File Format Support in GeoCommons – Do Geodatabases Make Sense? […]

  11. DavidDP says:

    BEHIND THE JACKPOT; Divide And Conquer: Movie sweepstake Titans

  12. […] to the subject of shapefiles  (more quickly after a few drinks – see here, here, here, here, here, here and especially here),  and it always arrives at the same question:  What […]

  13. Thanks for posting this informative article. This is a really good read for me and moncler jassen dames. Thank you very much. woolrich jassen dames also like your post. I find a good site sell moncler jassen heren 2011, moncler muts, woolrich jassen heren. You will also like it.

  14. You had some nice points here. I done a research on the topic and got most peoples will agree with you