File Geodatabase -- Choice or Necessity?
At ArcGIS release 9.2, ESRI introduced yet another spatial data format – the file geodatabase. Users are confused, and rightfully so.
Many of my clients are already juggling too many data formats. CAD (which is not going away, by the way), coverage (e.g., from old NJDEP layers), shapefile, personal geodatabase, and now – the file geodatabase. Which format should users choose to store their GIS data? The answer keeps changing, more frequently than most would like. How often should users have to migrate their databases to a new format? And what about compatibility issues? Many third-party developers still only support the shapefile format.
Too much choice isn’t always good. Too many choices confuse users and they tend to select/buy LESS. This "paradox" has been studied and written about at length, most recently by Harvard psychologist Dan Gilbert (I'm a big fan) in his book "Stumbling on Happiness".
If the new file geodatabase format is intended as a replacement for the poorly performing personal geodatabase (as it seems to me), ESRI ought to come out and say so, using clear, simple and straightforward language. Then migrating users’ databases becomes an understandable necessity rather than a confusing choice.
Greetings,
Regarding GIS database formats, I use Arcgis 9.1 and cannot comment on the new 9.2 geodatabase format. There must be some advantages to the new format.
I wish I had 9.2
Regards
Alan
Reply to this
I agree that having all the file formats is a bit too confusing - it also makes it difficult to choose the right format for your clients. In my current position I keep most everything in shapefiles, since that's how I got them, but if there is a group of data that should be stored together(series of aerials, municipal parcels, etc), then I make them into a personal geodatabase. I currently do not see a use for the new format because it is not backwards compatible, and so requires that all users have 9.2. That simply isn't going to be a reality for quite some time(and by then ESRI will have a new version out). Unless you are ONLY working with people with 9.2, it's pointless to use the file geodatabase, which makes it appear pretty useless to me for the GIS community until either there is a way to make it backwards compatible or everybody has current licenses(unlikely at best)
Reply to this
while I can understand that the average user would be confused with format types and when to use them. The best option for a user is to use the format that works best for your need and on at your skill and experience level. The good thing about advanced formats is the ability to integrate to a more advanced format.
As for the new file geodatabase this type of database is what is called a flat file database. Data is stored in a folder system and has the advantage that Each dataset is held as a file that can scale up to 1 TB in size.
The Personal Geodatabase on the other hand stores datasets within a Microsoft Access data file, which is limited in size to 2 GB.
- Some other advantages are that you can store a number of native data formats with out having to convert them. with the personal database format you are tied to the Windows operating system.
- Each dataset is a separate file on disk A file geodatabase is a file folder that holds its dataset files. In a Personal Geodatabse all the contents in each personal geodatabase are held in a single Microsoft Access file (.mdb).
- The new format also allows you to optionally store data in a read-only compressed format to reduce storage requirements.
What is comes down to is that the new file geodatabase is great for users who need more storage power and have a need to work out of the limitations of the Windows Access format. This is great for users who are not quite ready to migrate to or can not afford the cost of setting up an ArcSDE Geodatabase.
Hope this helps with some of the confusion.
Reply to this
Bill is absolutely correct. The choices are there for flexibility and agility. There would be confusion if the various storage types were synonymous with one another, but each offers unique functionality. FYI. The file gb, begins at a 1TB table or feature class level and scales up to 256 TB per table or feature class.
Reply to this
This thread is very timely in light of the article recently found in Directions Magazine, where Oracle Spatial is becoming the defacto standard upon which the various "GIS" applications are being founded. The GE action is just one of many currently underway
I I have included the article below. Reading the other comments, the thought comes to mind that the GIS constituancy aappears to have two fundamental divisions, those who practice in a corporate IT environment and those who don't. It is my observation that even if you are doing geospatial work in a large organization, if the corporate IT standards and controls are not in place for you work , you are essentially a sole practioner. The issues of file formats which started this discussion are indicitive of inherent instabilities in a world of GIS divoreced from the larger world of Information science and technology.
An increasing number of observers are concluding that the promise of "Enterprise GIS" founded on the propritary offerings of the GIS vendor community is trulely an oxymoran. Data can and should be manageed in DBMS that are spatilly aware.
The Directions Article:Cutting Out the GIS Middleman: GE Energy Cements Relationship with Oracle to Build Enterprise Applications
By Joe Francica
(Mar 15, 2007)
In past editorials (1, 2), I've speculated about systems integrators being the next likely group to embrace geospatial technology and begin to engage their clients with location-based solutions. At the GITA Conference in San Antonio, GE Energy announced that it is developing applications with Oracle 10g Spatial technology. While you may not think of GE as a systems integrator because of its reliance on its Smallworld solution in the utility and telecommunications marketplace, this announcement changes many things.
Speaking with several GE Energy executives at GITA, I learned that they want to cut out the "GIS middleman" by leveraging as much functionality in the Oracle Spatial stack as possible, to develop a "next generation" of spatial solutions. In particular, they want to use the Network Data Model (NMD) and Oracle's linear referencing system. In addition, GE expects to take advantage of Oracle's Fusion Middleware to reach deeper into the Oracle application stack for business intelligence. GE intends to build thin client Java-based applications that would effectively dive directly into Oracle. No GIS will be in the mid-tier, not even Smallworld.
GE executives won't try to encourage existing Smallworld clients to migrate to these new applications. Still, they will acknowledge that they are keenly aware of how pervasive Oracle technology is within their existing client base. As such, executives want to make it easier to address the needs of the IT departments that are now managing more of the geospatial implementations, and perhaps spatially enable more enterprise applications using Oracle Spatial and a services-oriented architecture (SOA).
Reply to this
I think this is ESRI reaction to users who want to have large databases but don't want to or can't invest in Oracle/MSSQL. I suspect that there are users who still use the coverage model as their main data storage because the other choices don’t fit their needs. The file geodatabase is just another option you have for storing your data that is more modern then a coverage/shapefile, doesn't have the size/speed limitations of a pgdb, and isn’t as costly to deploy as a server based RDBMS. The question that should be asked of the file geodatabase is will its use proliferate and what limitations will it have? I don’t think it will be widely accepted but, I believe there will be some users who see the value of it and will benefit from another data storage option.
Reply to this
Thats exactly it,
Its really a teaser database as well as ESRI's 9.2 INFO now comming with SQL Express. It allows users who need more power to explore it as well as its new Child/Parent Database sharing capibilities. Its really ment to help sell you or convince your orgainization into moving into ArcSDE.
Its really a plus for those looking to convince thier boss, board, or client that they should invest into spending the money to move towards an Enterprise system. Same stragity that works with selling their extentions. The new Geodatabse funtions in 9.2 allow you to see the need for an enterprise system but block you from using the it as a true enterprise system.
Some look at this as a bad thing but if you think about it. It really allows you to expand you use a little into a semi Enterpries though limited system. But more importantly it can help you to show your company or clients what an enterpries SQL/Oracal system might do for them before they commit to the big bucks.
Bill
Reply to this
Isn't this like pushing someone to the point of no return, where they have no choice but to "choose" to spend megabucks?
Reply to this
This point seems to be lost in this most recent post...but it is ArcSDE. Its been noted that these new db's are a business case for migrating to SDE when in fact it is ArcSDE. The geodatabase surprisingly has not been embraced by many small government organizations or small private industry. And in that case the personal and workgroup, as well as file and personal gdb still offer an incremental growth path.
Small Steps.
Not just storage, remember all the added functionality that the geodatabase offer, such as topology, annotations, terrains, networks, and the rest. So, it markets to that group and gives no excuses for migration. Additionally, the before mentioned gdb's are a viable option to groups that currently use the enterprise class db. Organizations can support smaller groups that have specific needs such as your development team, QAQC team, or small workgroups that do not want features committed to the db but want central management of users and data.
Reply to this
The answer to the file geodatabase has recently come to lite with the relate of access. the new access format does not work with Esri products, with out some out side programing skills. Esri is working on a fix for this, but put out in my and others option the file geodatabase as a temp fix. Once a user upgrades to the new access and opens a geodatabase in it, the program will update the access database and it will no longer work in arcgis. Until Esri gets this worked out be warned about upgrading and if you do, Do not open a geodatabase in Access. If you do thier are ways of fixing it, but it right now involves programing skills
Reply to this
Bill:
Thanks a lot for your very insightful input. --Atanas
Reply to this
Not sure if someone already covered this or not but the file based geodatabase is platform independent where all of the other geodatabase types are tied to a specific platform. ESRI is starting to acknowledge the short comings of the comings of the Access based Personal Geodatabase in their training classes represent teh File based GDB as alternative not a replacement. It also looks like they are committed growing teh capabilities of the File based geodatabase as it while support one-way replication with an SDE database in version 9.3. This will allow it to be used more easily by SDE users looking to distribute data without adding to the licensing cost of their RDBMS. I think it was also first step towards supporting open source data repositories as 9.3 will see the addition of Postgre SQL with support for MySQL probably comming with the first service pack (rumor has it).
Reply to this
[URL=http://oyobauqp.com]otkbjeef[/URL] rgnijuhl vzoiljis http://rmgualwg.com zgjmbxhn wqfjpssm
Reply to this