43

Previously, I have used geodatabases as an easy way to keep all files together rather than having dozens of shapefiles all over the place, and it is easier when finally exporting all the relevant data to the client.

Why should I use a geodatabase instead of shapefiles when analysing and running functions on my data?

My primary focus is within ArcGIS, I don't usually edit outside of that environment.

This question is related to How does Personal Geodatabase work from Microsoft Access perspective?

locked by PolyGeo Dec 20 '15 at 21:52

This question's answers are a collaborative effort: if you see something that can be improved, just edit the answer to improve it! No additional answers can be added here

Read more about locked posts here
56

At a high level, it might be preferable to make a choice based on whether users are inexperienced and need nothing more than points, lines and polygons. Shapefiles could be suitable for this.

If they need annotation, domains for pick lists and validation, raster, longer field names, etc then File Geodatabases could be used which are easy to use, fast and can be massive in size.

Personal Geodatabases are based on MS Access. Unless there is a requirement for Access users to also interact with them, there would be more restriction with this choice. The 2Gb size limit & inability to store rasters is restrictive.

22

I try to avoid using shapefiles as you cannot store domains, relationships, aliases etc. but they are the most portable format when distributing data to other people who are using different GIS systems/tools.

Whilst file geodatabases give better performance and are capable of storing huge datasets, everyone above is giving the humble personal geodatabase a bad rap. I use them to store my analysis as you can use ODBC to suck the attribute data right out of them into your preferred statistical application. If your data is in a File GeoDatabase you have to mess around with converting them into some staging format before you can use them as nothing else can read from a File GeoDatabase (unless you want to spent time and effort programming the API...).

So for projects I adopt both formats, file geodatabase for large static datasets, personal geodatabases for outputs and analysis (unless the outputs are huge then they go into a file geodatabase).

If you are working on a project that has small datasets and everything sits happily inside a personal geodatabase then it's just 1 file to zip up and email. Something to consider?

12

File geodatabases (FGDB):

  • A FGDB may contain feature datasets, which aid in coordinate system control and data integrity via topology rules. You are on your own with shapefiles.
  • FC's may be up to 256 TB in size with the use of configuration keywords. All component files of a shapefile are limited to 2GB each (source & whitepaper).
  • FC performance is quite simply faster than shapefile, especially in operations involving attributes.
  • Vector data can be used in a compressed read-only format which can greatly reduce the file size.
  • FC's are used in map packages which are a handy way of sharing data.

Personal Geodatabases (PGDB):

  • Often used as an attribute table manager (via Microsoft Access).
  • Users like the string handling for text attributes.

Shapefiles:

  • Greater usability cross-platform (e.g. QGIS, ArcGIS) and for geospatial operations in a non-ESRI scripting environment (e.g. pure Python, R, Matlab).
  • Many end-users get irritated if you send them a FGDB rather than a zipped folder containing shapefiles. As a side note, KML files are often used over SHP files or FGDB's to share simple spatial data.
  • Shapefiles are easier to sync to the cloud using a service such as Google Drive, whereas FC's & FGDB's often have sync errors.
9

Most people would recommend storing your data in a database for performance reasons, i.e quick to query and search. However I believe there is also the benefit of currency when data is in a database. For example, if you pass a shapefile to a colleague they are likely to use that indefinitely but the data may have been updated. Where as if the data was stored in a database and the user connected to that database using ArcGIS then they would always see the most current and up-to-date data.

So the main Pros of a database are Performance Querying Indexing (although you can index in a FileGDB and MDB or even have a shapefile index however I have found that you can give a database more RAM when indexing, so I put this down as a Pro to the database) Spatial Functions run quicker in a database If you have text or addresses you can have Full Text Search

Cons Knowledge - affects both Proprietary or Open Source Dedicated Server in productions Costs - setup and running

FileGDB/MDB Pros Portable Plug and Play (almost as simple as shapefiles) Can be compressed to reduce size

Cons Can take a long time to create (my personal experience) for a lot of data ESRI Restricted(ish) Concurrent Users File limits

MDB is an microsoft access backed geodatabase which ends up having a file limit of 2Gb so if you have more data or want to provide more access to other uses then use a FileGDB.

More differences can be seen here http://webhelp.esri.com/arcgisdesktop/9.2/index.cfm?TopicName=Types_of_geodatabases

Hope that gives you some idea

6

I generally use FGDBs, but it really depends on what you need to store. Like the other posts have mentioned, Personal GDBs are outdated and have size issues.

Using a geodatabase allows you to set up a topology, which you can't do with plain shapefiles.

Shapefiles hold the exact coordinates of the shapes. In a GDB, the locations are snapped to the nearest point on a grid. I've not run into problems with this, it can cause small changes in data. Also, Shapefiles are easier to access with 3rd party tools. ESRI has an API for the FGDB, but it's new compared to existing ways to interact with Shapefiles.

4

if you want full-blown geodatabase capability (Coded Value Domains, Relationship Classes, Topologies, Geometric Networks, etc blah blah, without the complexity or admin overhead of relational geodatabase, AND/OR you want the fastest drawing, cursor, and geoprocessing performance, File Geodatabase is the way to go. Local disc access is much faster than a remote relational geodatabase. FGDB, like shapefiles, use floating point coordinates, not integer, for better and worse. FGDBs can be fragile, being complex, binary, and proprietary, so keep lots of backups. Shapefiles are the dumbest but the most widely supported, and can be quite speedy to work with too. Relational geodatabases allow you to use SQL, including spatial SQL, which can be quite flexible and convenient for ad-hoc analysis or applications. Personal GDB hasn't been worth monkeying with since the advent of FGDB - buggy, slow, file size limitations.

4

Another advantage of a fgdb over shapefiles is that features in a fgdb can have true curves. In shapefiles, curves are composed of arbitrarily small straight line segments. I'm not sure about personal gdbs.

Not the answer you're looking for? Browse other questions tagged or ask your own question.