2

I do not know why my tool no longer functions properly when working in a file geodatabase (FGDB), as opposed to the personal geodatabases (PGDB) used in the past. The tool is used to find feature in a point feature class (point_fc) that intersect features in a line feature class (line_fc).

The tool splits a selected line_fc feature at midpoints between vertices that intersect point_fc features. This still works as designed.

The issue arises when a spatial filter is used to find point_fc features that intersect the new 'split' features. The results of the spatial filter are not consistent as when using a PGDB. I don't believe anything is fundamentally wrong with my code, since it works with PGDB, but I may have overlooked something. I've included some code below:

// loop through selected line_fc features
IEnumFeat _enumFeat = _editor.EditSelection; // an enumeration of selected features
IFeature _feature;
while ((_feature = _enumFeat.Next()) != null)
{
    // storage for midpoints
    IGeometry midpointMultipoint = new Multipoint() as IGeometry;
    midpointMultipoint.SpatialReference = map.SpatialReference; // <-----PCS
    IPointCollection midpointCollection = midpointMultipoint as IPointCollection;

    // storage for point_fc geometry
    IGeometry multipoint = new Multipoint() as IGeometry;
    multipoint.SpatialReference = _feature.Shape.SpatialReference; //<----PCS
    IPointCollection intersectingPoints = (IPointCollection)multipoint;

    // get intersecting point_fc
    sFilter.Geometry = (IGeometry)_feature.Shape;
    sFilter.GeometryField = point_fc.ShapeFieldName;
    sFilter.SpatialRel = esriSpatialRelEnum.esriSpatialRelIntersects;
    sFilter.WhereClause = string.Format("{0}{1}{2} = {3}", fieldPreffixDelim, "subtype", fieldSuffixDelim, "12345"); // the specific subtype i'm interested in

    IFeatureCursor fCursor = point_fc.Search(sFilter, false);
    IFeature thisFeature;
    object Missing = Type.Missing;
    while ((thisFeature = fCursor.NextFeature()) != null)
    {
        IPoint pnt = thisFeature.Shape as IPoint;
        pnt.Project(_feature.Shape.SpatialReference); // GCS --> PCS
        intersectingPoints.AddPoint(pnt, ref Missing, ref Missing);
    }

    // split _feature polyline at intersecting points into individual polyline objects
    IPolycurve2 polyCurve = _feature.ShapeCopy as IPolycurve2;
    IEnumVertex splitPoints = intersectingPoints.EnumVertices;
    IEnumSplitPoint enumSplitPoint = polyCurve.SplitAtPoints(splitPoints, true, true, 0.1);

    // check if split occurred
    if (!enumSplitPoint.SplitHappened)
    {
        continue; // go to next _feature
    }

    // new geoCol for polycurve
    IGeometryCollection geoColl = (IGeometryCollection)polyCurve;
    for (int i = 0; i < geoColl.GeometryCount; i++)
    {
        IGeometryCollection polyline = new Polyline() as IGeometryCollection;
        IGeometry geom = (IGeometry)polyline;
        geom.SpatialReference = _feature.Shape.SpatialReference;
        polyline.AddGeometries(1, geoColl.get_Geometry(i));

        // query points that intersect line
        sFilter.Geometry = (IGeometry)polyline;

        // not all lines will intersect 2 points, so we skip those that don't
        // check for 2 points
        int pointCount = point_fc.FeatureCount(sFilter);
        if (pointCount != 2) //<----TODO: determine why we are getting inconsistent results with FGDB
        {
            continue; // go to next polyline feature
        }

        // use fCursor to get intersecting point_fc (also inconsistent results)
        ...
        // do something here with 2 point_fc features
        ...
    }   
}

The same schema is used on both the PGDB and FGDB, and all feature classes/datasets are in GCS. Map document is in PCS (WGS84 UTM).

Why would a spatial filter return varying results when using a PGDB vs FGDB?

It is recommended at ArcObjects SpatialFilter not working well to use a buffer when querying point/line intersections, however my points are snapped to my lines at vertices. I will try this if all else fails.

Improve this question
7
  • 1
    First I'd double check the XY tolerance if you haven't already. Then I would try using SpatialRelDescription of "T********" on your spatialquery instead of Intersects. In this case you would expect them to behave the same, but in the past I've experienced different results when using the SpatialRelDescription instead of a standard enumerated search type. After that I would suggest a tiny buffer like in the linked question, because I haven't found a better way around the issue when the spatial queries are misbehaving.
    – danielm
    Commented Jan 2, 2018 at 17:29
  • @danielm What exactly am I to check with the XY tolerances? ISpatialReferenceTolerance returns the XY tolerance specified in the Feature Dataset properties (0.000000008983153 Degree), which I assume is roughly 1mm.
    – Barbarossa
    Commented Jan 2, 2018 at 17:32
  • I meant to double check that the XY Tolerance was the same between the two schemas. That's the only thing I can think of off the top of my head that would cause the PGDB and FGDB to behave differently. It could also be something else I'm not aware of or it could be some difference in how the PGDB and FGDB formats are searched.
    – danielm
    Commented Jan 2, 2018 at 17:51
  • They are the same between schemas. Also, the relation "T*******" now returns 0 features.
    – Barbarossa
    Commented Jan 2, 2018 at 18:18
  • 1
    I would go with a small buffer around the query line. It should be consistent and catch all the points that are on the line.
    – danielm
    Commented Jan 2, 2018 at 18:43

1 Answer 1

Reset to default
0

This is a solution to my particular problem, but does not answer the overall question. The issues with my code is actually a rookie mistake, and I overlooked it before, as it worked properly with the PGDB.

The issue is that I was providing the spatial filters a projected geometry, to query for features in a feature class with a GCS. For some reason it works in a PGDB, but not in a FGDB. As danielm suggested, buffering the lines by a small amount (2 x XYTolerance) was enough to intersect all 'touching' points. However, this led me to determine that there was a conflict between spatial references. For whatever reason, the conflict was not an issue in a PGDB.

Perhaps someone can chime in on this, whether it is by design or simply a bug.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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