Parcel Alignment Failed - Alignment caused a neighbor parcel number of parts to change
We are working on a MAJOR alignment of parcels in a new sub into an existing fabric. In this case, we forced ourselves to use the choice of "Toggle Selection to Surrounding Parcels" since the brand new parcels in the subdivision are aligned to brand new control points which are askew from the existing fabric data. The existing parcels must align to the new parcels so we toggled, which always comes with complications. In this case, the complication is this error about "Alignment caused a neighbor parcel polygon number of parts to change".
This is not the first time we have seen this error, and we would like to know a workaround. As you can see from the screengrab there are 444 selected features surrounding the new subdivision that need to be aligned to the new parcels, and from the error message, there might be one or more "problematic features" that are preventing the alignment from going through. How can we detect this feature and how would we go about fixing it such that the alignment will run though?
Accepted Solutions
Hello @JasonBessert
The Alignment process moves points which in turn modifies lines and polygons.
Sometimes, especially with data that has small segments, a point can move in a way that changes the number of parts a polygon has. Think of a 'bow tie' shape. This is data corruption and we've implemented this check to prevent it from happening.
The tool compares the number of parts each polygon has before and after the alignment process to make sure it hasn't changed.
We usually see this when the data contains very small line segments or points that are very close to each other. You can use the Parcel Layers 'Too Short' or the Geoprocessing tool Find Adjacent Parcel Points to detect those.
Another case can occur when a curve diverges to a straight line: sometimes moving the end point can cause the curve to go under the line (when zoomed in).
I agree we should improve on communicating where the problem is.
If your data is clean of those cases and you are still getting this error the workaround is to either try to use Align Parcels on subsets of the data, until you identify the problematic area, and/or use the Align Feature tool.
Hello @JasonBessert
The Alignment process moves points which in turn modifies lines and polygons.
Sometimes, especially with data that has small segments, a point can move in a way that changes the number of parts a polygon has. Think of a 'bow tie' shape. This is data corruption and we've implemented this check to prevent it from happening.
The tool compares the number of parts each polygon has before and after the alignment process to make sure it hasn't changed.
We usually see this when the data contains very small line segments or points that are very close to each other. You can use the Parcel Layers 'Too Short' or the Geoprocessing tool Find Adjacent Parcel Points to detect those.
Another case can occur when a curve diverges to a straight line: sometimes moving the end point can cause the curve to go under the line (when zoomed in).
I agree we should improve on communicating where the problem is.
If your data is clean of those cases and you are still getting this error the workaround is to either try to use Align Parcels on subsets of the data, until you identify the problematic area, and/or use the Align Feature tool.
Thanks Amir, we applied the last workaround that you suggested from that message to get the map change finalized, working the alignment in portions of the data. Seems like the option of selecting surrounding parcels in the fabric always seems to come with complications and it's to the point where we have a workflow of pre-adjusting the fabric to allow the new parcels/subdivisions to fit more snugly with the newly introduced parcels, such that we always use the new parcels as the features subject to the alignment.
You did bring up an interesting case regarding arc segments converging on a straight line, those are the trickiest and our favorite tool, Align Parcels has trouble working those cases, since there is no tolerance too small to perform the alignment without pressing data together in a manner that is undesired. Hopefully there can be a way additional functionality can be applied to prevent 'over-alignment' of these features, but I'm getting off-topic on the matter of the original tenor of my message in this thread.
Regards,
In case it's helpful, for situations like above, we typically go in and do an alignment along the curve to the point of intersection then back out along the intersecting line. This does require special attention and visiting these individually, but I haven't found a better way to do it either.
