Since posting this question, I've come to the conclusion I'm not fighting flaws in the BasicGeoprocessor object, but more likely having issues with poor object lifecycle management on my part (there is some helpful info cited by @blah238 in this thread).

I accepted @Jakub's answer to close the question so it won't appear in the unanswered questions list perpetually. However, at present I believe there's nothing wrong with my BasicGeoprocessor implementation, and the issue is related to hanging references elsewhere in my code.


I maintain a small ArcObjects solution using the 9.2 SDK that is plagued by inconsistent failures in its BasicGeoprocessor.Intersect() implementation. It seems to be failing more frequently than it succeeds. While it succeeds on every first run, it tends to fail on subsequent attempts. Although, sometimes it still works on the second run, so it's been difficult to truly isolate the cause of errors.

I'd certainly rather use this approach and apply the Geoprocessor, but it can only do wholesale intersections at the shapefile level, and I only want to intersect two in-memory SelectionSet objects. Could the ITopologicalOperator do this? In the past I've been unable to make it work on real-world data, and it seems some others have too.

Here's the relevant block of code calling the BasicGeoprocessor. It's argument variables are explained in the comments, and if you follow the link above, you can see the example it's patterned after. I suspect my references to either parcelTable, soilTable, and/or parcelFCursor may be lingering between calls, creating the errors.

'perform intersection
Dim BGP As IBasicGeoprocessor
BGP = New BasicGeoprocessor
BGP.SpatialReference = parcelFeature.Shape.SpatialReference

    ' parcelTable and soilTable are ITable
    ' True (useSelectedInput argument)
    ' True (useSelectedOverlay argument)
    ' 0.0# (the mythical Tolerance value, I've also tried 0.0, and 0)
    ' pFCN (IFeatureClassName)

    intersectFC = BGP.Intersect(parcelTable, True, soilTable, True, 0.0#, pFCN)

Catch ex As Exception

    MsgBox("unable to intersect input data")
    Exit Sub

End Try

'(blah238's answer, first link above, suggests this is **NOT** the way to do this)
'Clean up. This chunk shows all the variables preceding the Try block, too. 
parcelLayer    = Nothing 'IFeatureLayer
parcelFC       = Nothing 'IFeatureClass
parcelFeatSel  = Nothing 'IFeatureSelection
parcelSelSet   = Nothing 'ISelectionSet
parcelFCursor  = Nothing 'IFeatureCursor
parcelFeature  = Nothing 'IFeature 
parcelTable    = Nothing 'ITable          <--- I think this one is the culpret.
parcelSF       = Nothing 'ISpatialFilter
soilLayer      = Nothing 'FeatureLayer
soilFC         = Nothing 'IFeatureClass
soilSelSet     = Nothing 'ISelectionSet
soilTable      = Nothing 'ITable          <--- and or this one.
pWSN           = Nothing 'IWorkSpaceName
pFCN           = Nothing 'IFeatureClassName
pDSN           = Nothing 'IDataSetName
intersectFC    = Nothing 'IFeatureClass
BGP            = Nothing 'IBasicGeoprocessor

I'd love to know what other folks are doing to perform in-memory intersection on SelectionSet objects or if anything stands out as obviously wrong here. As always, thanks so much for any assistance and insights you have.


iTopologicalOperator can do this on feature by feature basis. Since you want to do this "in memory"; have you considered using iArray? The array holds references to objects which are released when the array is destroyed.

You could iterate through 2 selection sets and use iTopologicalOperator:Intersect and store the results in iArray. As I already mentioned you might have to do this on feature by feature basis. You could merge all features and then attempt to intersect the 2 complex geometry with iTopologicalOperator:Intersect but it might fail if the geometry is not simple or too complex. By doing this on feature by feature basis you can examine each input geometry that will participate in each operation and simplify prior to Intersecting. You can also examine and simplify the result as well. You can add some custom "intelligence" into the programming and decide which result is valid and or not valid based on your own criteria. You could even "explode" multi-part geometry results and handle them separately but this approach would require recursive iteration.

| improve this answer | |
  • Thanks for the feedback, I'll consider your recommendations, but I'm not sure about the simplifying. Do you just mean exploding multi-geometries, or do you mean simplifying Douglas-Peucker style? Also I have always wondered, what distinguishes simple and complex geometries in the context of ArcObjects and ITopologicialOperator? I'm sure both my input datasets contain some of the wildest polygons known to man; both have inner-rings, and some may be multipart. Also the soilsTable has very high-detail, meandering rings, I wouldn't be surprised if they use circular arc curves. – elrobis Mar 20 '12 at 15:12
  • Sounds like that might be a part of the problem. Writing a recursive custom intersect procedure will not be a simple task. You could try running the Repair Geometry geoprocessing tool then run your existing process. In any case what i meant by simplifying is the iTopologicalOperator:Simplify method. – Jakub Sisak GeoGraphics Mar 20 '12 at 15:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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