Monday, September 15, 2008

You are in a maze of twisty passages, all alike. (An ArcObjects rant)

So, it's approaching midnight and the weekends-and-evenings side project I've been working on for the last three days or so suddenly stopped being fun and started being unpleasant.

Once again I find myself shaking my fist in the general direction of Redlands, CA. Can't they ever get anything right?

Hint: When your API contains the following interfaces;
  • IFeatureLayer
  • IFeatureClass
  • IGeoFeatureLayer
  • IDEFeatureClass
  • IGPFeatureLayer
; all of which are wrappers around pretty much the exact same concept... you're doing it wrong.

And to push things over the edge, the design wizards in Redlands have decided that it takes a dozen or or more twisty lines of under-documented property accesses and mystery casts to get from any one of them to another.

(snagged from the Fail blog)

For ESRI/ArcObjects virgins, you can get a glimpse of the horror in a conveniently visual form here: (warning: huge PDF; also an older version but what google found quickly).

And for those of you who have shared my pain, and might be interested as to what spurred this particular outburst (I'm probably into the hundreds of these, but this is the first I've published outside of a nasty email or two):

I'm implementing a geoprocessing tool, and trying to do it properly and robustly. ((Which means, at the moment, somehow getting from an IGPValue which contains a catalog path to an (output) feature layer, to the appropriate IFeatureWorkspace that can create a feature class in that location -- even if, for example, it's inside a personal geodatabase instead of a good ol' shapefile.))

Other things not working right yet:
  • Having my IGPFunction::Validate magically create an IDEFeatureLayer that appropriately describes its output. Necessary, I think, for people to be able to wire my tool up in Model Builder. (Side rant for another day -- Model Builder's value as a scripting/programming/automation tool: nearly worthless. Model Builder's value as a PowerPoint slide generator: $$$$.)
  • Getting IGPUtilities::GenerateDefaultOutputValue do something more interesting than E_FAIL.
Good news: Once things are working right, I'm planning to post and GPL the whole thing: that way others can possibly learn a bit from my struggles and/or help me overcome any lingering ArcObjects battles.

The tool itself is a reincarnation of Boundary Maker, an old Avenue script I wrote ages ago.


Anonymous said...

Hi Dan -

For boundary manipulations, I find maptopologies to be useful. I'm not familiar with ways of doing this with OOTB modelbuilder, so I think it would be great to see more custom gpTools being developed. Here's some quick & dirty VBA code I wrote a while back for doing something similar:

When dealing with ArcObjects I find it helpful to remember Randy Pausch's comments about walls from his Last Lecture.

Dan Shoutis said...

Hi Kirk,

I didn't put two and two together at first and thought your link was to to a GIS or programming reference that might have some technical solution....

A fantastic lecture; I should check out the book. Rather telling that the best response to ArcObjects issues is a healthy dose of life philosophy. ;)

I think you'll find Boundary Maker Redux interesting, once it's out. I'm barely touching ArcObjects except to build a GP tool wrapper. The rest is straight-up computational geometry, a rather different (but much more flexible) approach.

Anonymous said...


Great post, very amusing (if that's the right word for it). How about this illuminating entry in the developer help:

"FindBeginningRing Method: Returns the beginning ring of the ring group containing the specified following ring."

Well that's just clear as crystal.

Anonymous said...

Hi Dan -
A big drawback of maptopologies is that they are tied to arcmap's Topology Extension. If you come up with something equivalent to maptopology (without an arcmap dependency) it would be very useful. In addition to packaging for use in modelbuilder, consider making it available to arcengine.

Anonymous said...


Dan is right about how creating a GP tool is a mess, given these numerous data types that seem to point to the same type.

However, if any of you are Java developers/managers, then there's some good news for you. ESRI will be releasing support for creating GP tools in Java shortly. This support will include Eclipse IDE wizards that will generate boiler plate code for you, based on what you tell the wizard to generate (what type of parameters, values, licensing, etc).

The data types still haven't changed in the first release of this Java support, but in future releases we are planning to ask more questions in "English" in the wizard and generate code so that users don't have to worry about the data type and "ability to work in a model" mess.