Skip to content
July 26, 2006 / Steven Pousty

On Geo-Business Objects and Dave’s excellent post

Dave has an interesting post about working with data in a geodatabase but “avoiding” the geodatabase API (Dave Bouwman – Geodatabase Kung-Fu: Geo-Business Objects). I had been grappling with this recently as I start to take on a project that has data in a personal GeoDB and a plain old Access Db. I wanted them to be in the same DB since eventually I would like to move this into SQL server.

The dilema for me is that ArcObjects is not “friendly” when working with just plain tables, as compared to some of the cooler Object-Relational technology out there. I used to use hibernate on my Java projects before doing GeoDB work. I loved the way it removed the need to have SQL anywhere in my code. I was using an Object oriented language and I liked how my compiler helped me to code faster, why would I want to drop into relational world (SQL) where all my interactions were through strings.  ArcObjects provides that Object Relational mapping since I work with Objects (IFeature or ITable) to manipulate things in the GeoDB. But there are two problems it presents for me:

1) It is overkill for non-spatial tabular work and is not “standard” in either Java or .NET.  Both of these languages have data structures and forms that know how to work with them. You have to basically write code to translate from ArcObjects data to the way you want it to be for representation.

2) To use the GeoDB API you need to purchase a license from ESRI. If all I want is a form to edit some of the tabular data why would I have to buy an Engine (or Engine GeoDB) license so that my code knows how to interact with the GeoDB. It makes sense that people who will be editing spatial information would use ArcGIS to do that work and that they would have a license. But people just typing information into a form should not need a license for that work.

So I asked around and it seems like I can edit tabular data (and even the tabular part of feature data) without using the ArcObjects API. This makes my life much easier. I can still write code to interact with the non-spatial data in the GeoDB that doesn’t use ArcObjects. Please share your stories if you have done this type of work.

It looks like Dave has taken on wrapping the ArcObject calls so that you can isolate the ArcObjects in a layer of your code and then expose more traditional .NET objects higher up. I think this is a great idea if you have the staff and time to pull it off. He earns extra points for using the XML schema exported from Catalog as the basis for code generation. The drawback here is that you still need a license and install from ESRI to work with this code. I know Dave is in Server land so this is not as big an issue for him.

For me, I could have GIS people updating the Features in the geodb (they have an ESRI license) and field people entering non-spatial data (they don’t need an ESRI license on their machine). This is why I want plain .NET or Java interaction with the attribute data. I don’t want to have to install Engine on a machine just so people can enter tabular data in a form.

In the continuum from pure ArcObjects in all your code to Dave’s approach to pure .NET or Java interaction, there has to be some guidelines or more ideas on when it makes sense (size of project, size of staff, how dependent you want to be on an ESRI license…)

I would love to hear what other people are doing. It seems like most bloggers are Server or IMS developers. I have left that area for now and I would love to also hear from Desktop/SDE people. How do you handle this tension between ESRI’s desire for everything to be in the GeoDB and not wanting to use a Sledgehammer to nail together a birdhouse?

On a related note I would also like to hear stories about using a Personal GeoDB for both ArcGIS work and plain old Access work. Has anyone pulled it off successfully? Co-workers here are quite suspicous that I can do this and not hose the GIS data. I want to use the relationships and forms in Access to build the non-spatial data entry piece.



Leave a Comment
  1. Dave Bouwman / Jul 26 2006 12:03 pm


    Our “ArcDAL” is actually designed for working with Desktop apps – we’ll be extending it to work with server, but that’s a little ways out.

    I think what you want to look at is the “Non-Versioned” Geodatabase option at 9.2. This is specifically designed to allow other apps to edit the data directly in the tables. In many cases, organizations edit in SDE.Default anynow, so this makes a very easy transition – and you can use all the standard OR/M and code gen tools. Of course you can’t use the super sexy database replication if you skip versions, but of course there are always tradeoffs.

    If you are working with ArcSDE pre-9.2, be VERY careful about editing the base tables w/o some kind of versioning. As long as there are A & D tables in the mix, direct SQL access is frought with peril. If you need a non-licensed editing option, you can use multi-version views and run update queries against them, or store all the attributes in a related non-versioned table, and use direct SQL against that.

    As for the Personal GeoDB and direct access, it works just fine – a friend does this regularly. He builds a data access layer using RapTier, and uses that to edit the attributes via SQL queries. Of course, if they upsize to SQL, the whole thing is hosed, but if you’re 100%-forever in PGDB, then this works.



  2. Matt Priour / Aug 1 2006 3:26 pm

    Unlike D.Bowman, I only have access to Desktop versions of ArcGIS. I have used the direct OleDb access via the ESRI PGDB OleDb driver as the engine behind attribute entry forms for non-GIS users.
    I’m managing a large multi-county mapping mapping project using parcels & roads standardized into a PGDB. Each parcel actually pulls its attributes from a standard Access Db using the Parcel Id.
    The project is being used by our wildlife consulting company , a conservation law firm, and a conservation mind-ed real estate firm. Each of these groups has their own custom layers & feature classes into which data may be input by basic GIS users through ArcGIS or by non-GIS users through data entry forms. Additionally we also have some non spatial info stored in SQL Express databases which are pulled by spatial based queries and reports.
    While this approach is working fine, it probably won’t scale up a whole lot more and still be managable and there are some tricks to keeping the same info shared by all 3 groups

  3. thesteve0 / Aug 1 2006 4:40 pm

    Thanks you guys, it was good to hear that people are using PGDBs with both Arc* and non ESRI technology. I am not going to sweat Versioned GeoDBs just yet since few of these projects are that level. I will burn, I mean cross, that bridge when I get to it. I have heard a lot about the OleDB driver, I will have to look into that some more.

  4. Charalampos / Feb 9 2008 7:44 am



  1. Business » On Geo-Business Objects and Dave’s excellent post Steve’s Little world

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: