There are really good reasons to use the File Geodatabase in the ESRI world over the shapefile and Personal Geodatabase, but it doesn’t mean it is easy to share. Sean Gorman knows that the more file formats he supports, the more likely people (especially GIS pros) will be using GeoCommons. I suppose the simple answer for Sean is to buy a license of FME Server and support everything and anything people upload. The cost of that solution might not make business sense just yet for him so I suppose is the lack of ESRI Geodatabase support (or any other format) limiting you when you want to share data? I like the idea of uploading a Geodatabase full of datasets at one time, but sharing a folder/file based dataset is difficult enough on a LAN, let along the internet. Is converting to shapefiles too much to ask for people who want to share data on services such as GeoCommons?
WeoGeo partnered with Safe Software to bring this kind of datasharing (among other features of FME Server) to the cloud web so there might be solutions that are cheaper than outright licensing FME Server to bring translate capability to Web 2.0 services. If that can be coupled with Amazon Web Services pricing (pay for what you use rather than a traditional license) there could be something that many people take advantage of.
And of course you could export out any layer in GeoCommons Finder! to any of the 200+ FME supported formats.
13 Comments
There are really good reasons to use the coverage in the ESRI world over the shapefile and Personal Geodatabase, but it doesn’t mean it is easy to share.
So, have we come full circle in the data-format-improvement cycle? Is the file geodatabase the new coverage?
The file geodatabase is capable of storing elements as they would be stored in an SDE, allowing for some portability or “offline” use. The GDB has much more functionality than coverages.
@John: I know. I am exaggerating on purpose in order to make a point. Which is: After more than 15 years of “improvements” we still don’t have a GIS format that is both more functional and easier to port/share than the coverage. Many of my clients are still converting to and from shapefiles on a daily basis, for a variety of very valid reasons.
Shapefiles still store data using a dbf so the column names present some annoying limits. Sharing if normal data is annoying with ESRI products.
When is ESRI going to keep their promise and release and open API for the fGDB?
Interesting idea and I think if/when we get to supporting raster formats it would make a lot of sense. The question is how many vector file formats are there that folks would like to see supported. This seems like a fairly small universe which is why, to date, we’ve done it ourselves to save money. On the vector side of GIS supported formats what would everyone see as great to haves? For us it is not a question of the value of FME or WeoGeo for that matter but really a question of economics and engineering integration effort.
One of the huge looming issues with shapefile conversion is the loss of true curves. We have data producing departments who have very serious issues with densifying legally defined curves into polylines for roads, parcels, and jurisdictional boundaries. Once our data get released, it has a knack for finding its way into all sorts of high accuracy situations; and this gets embarrassing (and time consuming) when data users comes back to us with questions on intersecting parcels and jurisdictions (fortunately none of this has ended up in court yet).
ESRI will most likely release an ADO.NET type access to the FGDB. I think I heard it would be around the 9.4 release.
@Brett — we’ve seen a number of customers run into troubles with the stroked-out-curves issue over the years, and I agree that the lack of curve support is a huge issue for Shape files but also a number of other modern formats and systems too. So much so that TCI Corporation has made a plugin for AutoCAD that fits arcs back onto stroked-out-areas (http://tcicorp.com/html/sol_cfit2.php) and has also made this available to FME users (http://www.safe.com/technology/documents/technical_briefs/Curvefitter_Tech_Brief.pdf) as a plugin so that it can be applied to any format at all. There typically are great reductions in file size, particularly with File Geodatabase, and some folks claim improvements in accuracy when data that was originally curve-filled and now stroked into line segments is later curve fitted.
@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???:-)
as an aside – we’ve been steadily shifting to storing and providing data in “spatial databases”.
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.
if ESRI releases an API for fGDB, it might was well be an API for SDE since they are practically identical.
keeping with the simgle file mantra for interchange, what about an XML workspace document support?
File based geodata formats still are incredibly useful, and shapefiles are definitely getting stale. I have been complaining to my ESRI reps about the “missing” open API for file geodatabases for a long while now. I think they really missed the boat by pushing it off for so long. Last I heard it wasn’t coming until version 10, but that may be inaccurate at this point.
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.
my 2 cents…
Here is an interesting post about interchangeable file formats
cheers