Here is an interesting post about interchangeable file formats

cheers

File geodatabases can indeed be thought of as (Workstation) ArcInfo “workspaces”, but one extremely helpful advantage of the file GDB over old coverages is that everything you need is contained in the .gdb directory (as opposed to the dealing with a “coverage directory” and an “info directory” that might be shared among many coverages in the workspace.)

This simple change means that you can zip and ship file geodatabases very easily using standard operating system tools, and pass along all of the geodatabase advantages (e.g. annotation) to your collaborator or client.

One of the other interesting things about file geodatabases versus shapefiles emerges when you look at a shapefile with a very large (many columns) attribute table that is sparsely populated. Compare this to the same data in a “compressed” file geodatabase – read only, yes, but just fine for display and query. We have one data-layer that is 500 mb in shapefile format, 50 mb as a compressed file geodatabase. The difference is in the .dbf table versus attribute storage in the compressed file GDB.

And finally, if you do a fair amount of data maintenance in SDE (er… Server) it is much simpler to export that data to a file geodatabase for sharing, than dealing with shapefiles and the headaches of column-name truncation, field data type irregularities, etc.

keeping with the simgle file mantra for interchange, what about an XML workspace document support?

By this I mean “normal” databases (not a Geodatabse per say) w/ a geom field, usually in WKB format. Doesn’t help with the true curves of course, but does make for an easy to port format that can be as simple or complex as required. We keep ours in SQL Server, but can pretty simply convert it to Oracle, MS Access etc. As long as the client can read the geom binary, we’re good to go.

We’ve been sort of cringing at the whole FGDB thing, as coverages were (as has been mentioned) a real bear to move/share and I don’t see the FGDB as being any different. Not to mention that most of our clients can read them as they don’t use ESRI software.

I think shp files have outlived their usefulness in the grand scheme (yes – I realize that they are still being used and doing well for many organizations) as the limitations of this format have caused us to essentially stop using it unless we have to for a client.

my 2 cents.

@Indigo — the open API for File Geodatabase will certainly be something widely welcomed. In the opt-in usage stats we collect with FME, Shape by far is the most popular format, but it is looking a bit long in the tooth and so it may be time for something better, and a free-and-clear File Geodatabase API may pave the way. But, if not, there’s always the option of storing spatial data in SQLite (right Jason???:-)