Welcome to ESRI Blogs

Five reasons why you should be using the File Geodatabase

There are many options to the GIS user when deciding what data store to use to store geographic data. At ArcGIS 9.2 we introduced a new type of geodatabase, the File Geodatabase. While all types of geodatabases have their strengths and weaknesses, we thought it would be useful to highlight some of the strengths of using this new type of geodatabase.

Size

The database size is only limited by the available disk space. By default, individual tables and feature classes can be up to 1 TB. With the use of configuration keywords this can be expanded to 256 TB.

Versatility

Works on many different operating systems including Windows and UNIX (Solaris and Linux)

Speed

Provides excellent performance and scalability. For example, to support individual datasets containing well over 300 million features and datasets that can scale beyond 500 GB per file with very fast performance. The file geodatabase out performs shapefiles for operations involving attributes, and scales the data size limits way beyond shapefile limits. Through the use of an efficient data structure that is optimized for performance and storage, File Geodatabases use about one third of the feature geometry storage required by shapefiles and Personal Geodatabases.

Edit Model

The File Geodatabase uses an edit model similar to shapefiles, supporting one editor and multiple readers.  Each standalone feature class, table and feature dataset can be edited by different editors simultaneously but can only have one editor performing edits on them at any given time. This means that User A can edit the Roads Feature Class at the same time as User B edits the Parcels Feature Class.

Compression

File Geodatabases also allow users to compress feature classes and tables to a read-only format to reduce storage requirements even further. This reduces the Geodatabase’s overall foot-print on disk without reducing the performance.

Published Friday, May 30, 2008 2:13 PM by brentardenpierce

Comments

# re: Five reasons why you should be using the File Geodatabase

File Geodatabase is a huge step up from Shapefile and Personal Geodatabase. It's superior in so many ways. I would love to recommend it, but I can't because it's proprietary.

At the 2006 User Conference when File Geodatabases were the buzz ESRI promised an open API. I believe it was even in Jack Dangermond's closing speech.

After 2 years, the only way to read and write a File Geodatabase is through ArcGIS. As an archival & publishing format it's worse than Shapefile, with which ESRI improved the industry greatly by publishing openly.

Please publish File Geodatabase as an open standard, so that your customers can gain the full benefit.

Sincerely, Alex Willmer

Monday, June 02, 2008 2:38 PM by moreati

# re: Five reasons why you should be using the File Geodatabase

We've been using the file geodatabase format in the office for over a year, and feel that it's one of the most solid developments ESRI has produced in years.

However, our clients use a wide variety of tools, GIS & non-GIS, as do we - until the file geodatabase is released as an open standard, we are loathe to use it for more than small-scope, special projects. It seems the similarity to the coverage extends beyond the superficial resemblance of a file directory containing lots of black box files.

Thanks, Brendan Hemens

Monday, June 02, 2008 4:01 PM by bhemens

# Editing with File Geodatabases

"This means that User A can edit the Roads Feature Class at the same time as User B edits the Parcels Feature Class."

Ive not really used F-GDB and im still using Personal GDB as majority of clients are still on 9.1  

Id like to know more about editing the GDB over a network and how it deals with multiple people editing the layers.  If person 1 is editing Layer A, will person 2 be locked out from editing A - will they be warned?

Can layers be protected, or perhaps only certain users given editing rights?  

I know this is more SDE level stuff, but would be good to know.  

I did some testing with multiple editing with personal geodatabases and although it is not recommended, it did seem to work out ok if there arent too many users.

Please discuss...  

Tuesday, June 03, 2008 2:18 PM by jak-c

# re: Five reasons why you should be using the File Geodatabase

Other points to consider to make the FGDB a standard worth adopting :

1) Full SQL support for subqueries (an area where the PGDB trumps the FGDB)

2) ST_GEOMETRY and spatial SQL support

Props to ESRI for making the FGDB platform-independent and for the performance enhancements- yet to make the format notable outside of the ESRI context, an open API is a bare minimum.

Wednesday, June 04, 2008 7:53 AM by usernameforme

# re: Five reasons why you should be using the File Geodatabase

First off, thanks for all the constructive comments! Generating candid discussion on geodatabase functionality was one of the main goals of this blog. We think it is great that people are using the File Geodatabase and we will continue to improve this data source to meet your needs. To that end, any feedback you give is taken very seriously by the team and greatly appreciated.

With feedback from many team members I tried to answer some of the questions that were raised in the comments to this point:

>> Re: Open FGDB API

We are still investigating an open API to the File Geodatabase and do not intend the File Geodatabase format to be viewed as proprietary. The most important requirement in the first release was to create a very good Geodatabase to serve the needs of ArcGIS users. Broadening that out to other environments was recognized as an important goal early on, and is something that we are working towards.

>> Re: FGDB Edit Model

If person 1 has started an edit session on feature class A, person 2 will not be able to start an edit session on A. An appropriate message will be generated. However, person 2 will be able to add A to their map, and create selections and so on.

As to assigning access rights, the File Geodatabase does not yet have the concept of GRANT/REVOKE similar to a DBMS. Access rights can be controlled using the normal operating system file permission mechanism.

With respect to multi-user editing and user access rights, it is important to remember that the File Geodatabase is not intended to be a full multi-user DBMS. When desigining the File Geodatabase we didn’t see the need to lock down the whole geodatabase if a user was editing on class.

>> Re: Subqueries in FGDB

The File Geodatabase supports several types of sub-queries, but not all. In particular, it does not yet support correlated sub-queries. Other types of sub-queries work just fine. Having said that, the intention is that additional SQL functionality will be added to File Geodatabase in order to meet user and developer requirements. The most common requests are for ORDER BY and SELECT DISTINCT, both of which are quite likely to be slated for a future release.

Hope this helps clear things up and thanks for the feedback.

Thursday, June 05, 2008 1:11 PM by brentardenpierce

# re: Five reasons why you should be using the File Geodatabase

One big issue we have with file geodatabases is that they are very slow and can make bizarre errormessages when they are stored on a network drive.

As long as they are on a local disk, everything is perfect but when they are distant, pGDB beats 10x them in performance

Thursday, June 05, 2008 1:29 PM by jaykayone

# re: Five reasons why you should be using the File Geodatabase

My wishes have been granted:

http://www.gaia-gis.it/spatialite/

Is ESRI planning on supporting SpatiaLite?

Friday, February 27, 2009 1:39 PM by usernameforme
Anonymous comments are disabled