nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Add additional match point methods and optional parameters to the 'Import Parcel Fabric Points

SeanLyons

Within the parcel fabric our organization maintains, we store control points for the entire province. Keeping these control points up to date requires regularly ingesting a control feature class containing 10s of thousands of control points and only updating the changed points in our parcel fabric. Previously in ArcMap, this workflow was accomplished using the ‘Load control points’ tool. Our organization is now in the process of migrating to ArcGIS Pro.

The ‘Import Parcel Fabric Points’ tool in ArcGIS Pro is missing some key functionality for it to be used as a replacement in our workflow. In its current state, the ‘Import parcel fabric points’ tool is better suited to importing small numbers of points in a single plan, rather than a large number of control points throughout a whole province.

There are several important enhancements that would help make the ‘Import Parcel Fabric Points’ tool more suitable for importing a large number of control points:

Additional Matching Methods:
- Proximity Match based on XYZ Attributes: Allow the matching of existing control points based on the XYZ attributes rather than shape geometry. This will make it easier to update points that have been moved without having to manually match them.
- Match based on Attribute Only: Allow the ability to match points based on a field only (such as the Name field), not proximity. This would make it easier to update a large number of existing points quickly using a known unique attribute without the need for computationally expensive proximity calculations.
Additional Optional Parameters:
- Update Attributes Only: Allow the ability to update only the attributes of the points, including the XYZ attributes, without updating the geometry. This will reduce the risk of unintended changes to the parcel fabric
- Detailed Logging: Provide more detailed logging options that include information about what points have changed and how they have changed. This will make it easier to identify any issues that may arise. With the ArcMap ‘Load Control Points’ tool it was possible to output a Log Results file, this functionality would be beneficial in ArcGIS Pro as well.

By incorporating these enhancements into the ‘Import Parcel Fabric Points’ tool, our organization will be able to more efficiently update our parcel fabric control and reduce the risk of errors or unintended changes.

Find more posts tagged with

Status: Open

Comments

AmirBar-Maor

@SarahSibbett

We will look into supporting additional matching options for imported points.

You can create as many layers from any table using a definition query. If you have points that you designate as 'control points' you can populate an attribute and apply a definition query.

Think of 'control point' as how a point is used. Some organizations might call certain points 'control points' while others organizations would not consider those points as valid control. The point is that a control point is a business decision. In a GNSS era many parcel corner points are more spatially accurate than many 'control points' and the real control is the satellite constellation and its control segment.

Please note that if you store points in the wrong location, they will still impact the performance regardless if they are being filtered by the layer (definition query).

Once you run LSA any point that has XY coordinates will move to that location, especially if used to constrain the LSA. We do not recommend having points with coordinates that do not match the geometry and having an attribute rule to catch such errors (within tolerance). Either fix the point location or the coordinates. If the coordinates are wrong a simple fix would be to delete them.

Sounds like we need to meet in the next UC in San Diego to discuss this 🙂

SarahSibbett

@AmirBar-Maor thank you for the feedback. The statement regarding the number of control points that can be imported was not related to the performance of the tool, rather the current match methods that are available. We really need the ability to match based on attribute (i.e., Name) or proximity match based on XYZ attribute. Otherwise end up with too many control points that will not be matched.

Regarding your question about if we are promoting the idea that the points' XYZ attributes do not have to match the geometry, yes, this is true. Since there is no separate 'control' layer in the Pro world, and control may sit on a parcel corner, we do not want to unintentionally move a parcel corner. In cases where control geometry does not match the XYZ attributes, we plan to handle this during an LSA.

Regarding the spatial reference, LTSA applies a filter to remove control points outside of their jurisdiction.

I hope this provides some clarity. @SeanLyons can chime in if there is anything else he wants to add.

AmirBar-Maor

@SeanLyons

Thanks for submitting the idea.

The import parcel fabric points geoprocessing tool is designed to import thousands of points. If you have any performance issues, please submit a technical support case so we can look into it.

If I read between the lines, you are promoting the idea that the points' coordinates (XYZ attributes) do not have to match the points' geometry. Is this true? why would you want that? can they be a cm apart? a meter apart? a km apart?

In the past, we had organizations import points that fell outside the spatial reference. This impacts the spatial index and degrades the performance. For that reason we ship the parcel fabric with the rule that the coordinates, if they exist, should match the geometry and that the point should fall within a user-configured bounding box (MBR).

In a versioned environment, you can always compare the child version to the default version to identify the changes. Wouldn't this be better than a log?