Fixing "Must Not Overlap" Attribute Rule

[SusanLMoore]

We have found fixing errors identified with the the default Must Not Overlap attribute rule for polys in the parcel fabric to be a bit challenging. In ArcMap, the editor was shown the specific area of overlap when an error was found with the topology rule.

When trying to fix this attribute rule in Pro, the entirety of the overlapping polys is selected. When you have large polygons, it makes it extremely difficult to narrow down where the overlap is. 

Do other users experience this, or are we doing something wrong? 

[ChristineLeslie]

Hi - have you tried using the Highlight command to highlight overlaps and gaps in your parcel fabric?

https://pro.arcgis.com/en/pro-app/latest/help/data/parcel-editing/findgapsoverlaps.htm

Regards

Christine

Parcel Team

[AmirBar-Maor]

Here is how the Highlight Gaps and Overlaps tool looks like.

[SusanLMoore]

Thank you for your replies, and sorry for the delayed response. We have been testing and retesting and testing again. We had seen the Highlight Gaps and Overlaps, but we weren't sure of its role because there were also the Current Must Not Overlap AR rules. 

Last week, we finally just removed almost all of the "Current Must Not Overlap" attribute rules. The only one we left was for TaxParcels, as that's the only layer on which we intend to keep history. 

From what I read on this thread, it sounds like maybe we should also remove the Current Must Not Overlap on tax parcel, and only using Highlight Gaps and Overlaps tool going forward (we are at Pro 2.9.5 and parcel fabric 5)? Am I interpreting that correctly? 

If so, what's the suggested validation workflow once an editor is done in an area? Run topology, validate any remaining attribute rules, and then also use the Highlight Gaps and Overlaps tool? 

We appreciate any suggestions! 

[AmirBar-Maor]

@SusanLMoore 

We recommend removing the CURRENT MUST NOT OVERLAP rule and use the too Highlight Gaps and Overlaps instead for the following reasons:

1. The new tool is more efficient
2. The new tool is capable of detecting gaps
3. The new tool accepts a tolerance, so you do not identify empty spaces like roads as a gap.
4. Unlike validating topology, the new tool does not modify the data

As regards the recommended workflow - it depends on your business requirements:

• I assume you would run the Highlight Gaps and Overlaps before and after working in a given area
• Topology & Attribute rules - some customers might run it in their named version after every edit while some might run it periodically. Some might run topology validation but postpone running attribute rules. it depends on the severity of the errors produced and your business requirements.
• This would be a good place for other 'tax shops' to chime in. I suspect we'll discover that the business requirements and practice are heterogeneous. 

[SusanLMoore]

Thanks! We will remove the attribute rule and switch to fully testing the Highlight Gaps and Overlaps. Generally, the editors validate topology for every "job" (e.g., a split/combo, new sub, etc.), so I was anticipating they would validate the validation attribute rules for every job as well. We will see if that truly makes sense as they continue their testing. 

I would be happy to take input from other parcel orgs, too! 

[DrewDowling]

Does the same apply to the must not have gaps topology rule? Should we remove this as well from our topology?

And FYI our current workflow is to run a topology check when editing is finished but before a version is submitted to the manager for rec and post.

[AmirBar-Maor]

@DrewDowling 

Two issues with the topology 'MUST NOT HAVE GAPS' and 'MUST NOT OVERLAP' rules:

1. If you have valid gaps in your data, such as roads, there is no way to specify a tolerance and they will also be picked up.
2. Topology rules work on the feature class level and not on the feature layer. This means it will pick up historic parcels as invalid overlap.

[DrewDowling]

@AmirBar-MaorOh yes I didn't think about historical parcels. They will have lots of gaps over time. Thank you.

[CathyAppleton]

@AmirBar-Maor 

I don't see using the gaps/overlaps option as a great alternative solution.    It is just not very practical when you have to run it on a bunch of layers individually and could easily miss/skip one when trying to select each one to check.    Another issues is the setting, you have to guess at overlap tolerance.   I find this odd since an overlap or gap is exactly that, an overlapping or gap in the layer regardless of the size.      I guess we were spoiled in Arcmap, where we would run topology on all layers at once and did not have to set the tolerance.      Is there any plans to improve or provide a more useable solution?