OperatorSimplifyOGC leads to "Index was outside the bounds of the array" in StridedIndexTypeCollection

I’ve been using the project https://github.com/EchoParkLabs/geometry-api-cs which seems to be derived from here. I ran into this error “Index was outside the bounds of the array.”

This originated from this call:

OperatorSimplifyOGC.Local().Execute(polygon, null, true, null);

and produced the following stack trace:

   at com.epl.geometry.StridedIndexTypeCollection.GetField(Int32 element, Int32 field)
   at com.epl.geometry.TopoGraph.SetChainParent_(Int32 chain, Int32 parentChain)
   at com.epl.geometry.TopoGraph.PlaneSweepParentagePropagateParentage_(Treap aet, Int32 treeNode, Int32 inputMode)
   at com.epl.geometry.TopoGraph.PlaneSweepParentage_(Int32 inputMode, ProgressTracker progress_tracker)
   at com.epl.geometry.TopoGraph.SetEditShapeImpl_(EditShape shape, Int32 inputMode, AttributeStreamOfInt32 editShapeGeometries, ProgressTracker progress_tracker, Boolean bBuildChains)
   at com.epl.geometry.TopoGraph.SetAndSimplifyEditShapeAlternate(EditShape shape, Int32 geometry, ProgressTracker progressTracker)
   at com.epl.geometry.TopologicalOperations.PlanarSimplify(EditShape shape, Int32 geom, Double tolerance, Boolean b_use_winding_rule_for_polygons, Boolean dirty_result, ProgressTracker progress_tracker)
   at com.epl.geometry.TopologicalOperations.PlanarSimplifyImpl_(MultiVertexGeometry input_geom, Double tolerance, Boolean b_use_winding_rule_for_polygons, Boolean dirty_result, ProgressTracker progress_tracker)
   at com.epl.geometry.TopologicalOperations.SimplifyOGC(MultiVertexGeometry input_geom, Double tolerance, Boolean dirty_result, ProgressTracker progress_tracker)
   at com.epl.geometry.OperatorSimplifyLocalHelper.SimplifyOGC(Geometry geometry, SpatialReference spatialReference, Boolean bForce, ProgressTracker progressTracker)
   at com.epl.geometry.OperatorSimplifyCursorOGC.Simplify(Geometry geometry)
   at com.epl.geometry.OperatorSimplifyCursorOGC.Next()
   at com.epl.geometry.OperatorSimplifyLocalOGC.Execute(Geometry geom, SpatialReference spatialRef, Boolean bForceSimplify, ProgressTracker progressTracker)

I can consistently reproduce this locally within my application.

Digging around in the debugger I think I found what constitutes the X,Y coordinates of the polygon being operated on:

| Name | Value | Type – | – | – | – ◢ | m_buffer | {double[8]} | double[]   | [0] | 136239 | double   | [1] | 3047 | double   | [2] | 98207 | double   | [3] | 3047.0000000000005 | double   | [4] | 98207 | double   | [5] | 9448 | double   | [6] | 136239 | double   | [7] | 9448 | double

That was from: polygon -> m_impl -> m_vertexAttributes[0] -> m_buffer

I guess this is the individual X,Y coordinates in series, making up 4 total points. (polygon.GetPointCount() returns 4). If there are any other relevant details of that polygon I can certainly add them.

---

This is the original definition of the function throwing the error:

int getField(int element, int field) {
    assert(m_buffer[element >> m_blockPower][(element & m_blockMask) + 1] != -0x7eadbeed);
    return m_buffer[element >> m_blockPower][(element & m_blockMask)	+ field];
}

and this is the C# equivalent in the other project:

internal int GetField(int element, int field)
{
    System.Diagnostics.Debug.Assert((m_buffer[element >> m_blockPower][(element & m_blockMask) + 1] != -unchecked((int)(0x7eadbeed))));
    return m_buffer[element >> m_blockPower][(element & m_blockMask) + field];
}

[DaveInCaz]

I think I found a solution that will work for me…

I had been using the package https://www.nuget.org/packages/EchoParkLabs.Computational.Geometry/2.0.0-alpha68 to provide the C# library. However I updated to the latest code from GitHub in its place, and the error disappeared.

I assume there must be some difference even though this is not evident in the GitHub history. History seemed to show that only some cosmetic changes to comments were made after the point where it looks like the Nuget package was created; but there must have been something else.

Ideally that C# project would update the Nuget to include the latest code; but I’m not sure how active it is… it looks like issues posted to that project aren’t looked at.

Thanks again for the help here, anyway!

[DaveInCaz]

@stolstov I think I discovered what the real issue is here. Some of the debug code may be causing a side effect which prevents the error. When that debug code is compiled out, the error can occur.

The reason that local compilation appeared to fix the issue was because the Nuget was probably compiled with optimizations. My own project was at that time only being compiled in Debug mode. But more recently we started building in Release which includes optimizations by default, and the problem came back.

Recompiling geometry-api-cs in Release but with optimizations OFF - the error does NOT occur.  So I am doing that now as a workaround but it would be ideal to include the optimizations of course.

Seems like there could be some debug code that actually is critical?

FYI I also updated the library to .NET 4.7.2 but that didn’t affect this issue at all.