Topology should ignore parcel fabric lineage history records

[AlanStearns1]

We have quite a number of parcel types in our parcel fabric and its very important that most of those feature classes do not have gaps and overlaps and that the linework remains coincident among them.  There are also a half a dozen parcel types whose polygons must be covered by other parcel type polygons.  Therefore we have created over 2 dozen custom topology rules in our parcel fabric.  In order for these topology rules to work properly (and not have to mark a myriad of exceptions), we must delete all parcel fabric lineage history as soon as its created. It's unfortunate that we were forced to choose between topology and lineage history, but in the end it was an easy choice as topology is much more important and beneficial to us and we already track (non-spatial) parcel lineage in our CAMA System.

[jcarlson]

That sounds quite drastic! The lineage is one of my favorite things about the parcel fabric, and I'd be hard pressed to give it up for anything.

Have you tried using subtypes in your parcel layers? We have subtypes on our parcels to differentiate between standard ownership parcels and, say, leasehold parcels, and are then able to define topology rules specific to each.

Could you, perhaps, make your own attribute-defined subtype for the retired parcels, then have your topology rules only evaluate against the "active" subtype?

[AmirBar-Maor]

@AlanStearns1 

You could create an attribute rule that deletes a parcel as soon as it becomes historic.

You could also create an attribute rule that copies it out of the parcel fabric and deletes it. But you do lose the parcel lineage...

What kind of topology rules are you currently using that make historic parcels an issue? If you are using MUST NOT OVERLAP and/or MUST NOT HAVE GAPS I recommend you take a look at the Highlight Overlaps and Gaps tool.

It highlights overlaps and gaps WITHIN TOLERANCE - which means you can define the width of a valid gap (like roads) or overlap (like condo units).

[AlanStearns1]

Thank you both for the suggestions.  I was especially intrigued by @jcarlson ‘s suggestion to use subtypes, mostly because we had a total of 14 no gaps and no overlaps rules on 7 different feature classes (and one of the 7; tax parcels is represented in their map as 4 different layers) and the Highlight Gaps and Overlaps tool suggested by @AmirBar-Maor only works on one map layer at a time, so I was initially thinking the editors would have to run the tool 10 times in each extent they are working in.  But then after we deprecated one of the feature classes that was notorious for gaps and overlaps, I realized that it would be unusual for them to split/combine (and hence produce a gap or overlap in) anything other than a Tax Parcel and we could add an all-tax-parcels layer to their map so they would really only need to execute the Highlight Gaps and Overlaps tool once in a given extent most of the time.  After some testing in a replica environment, the Mapping Director finally agreed to use the Highlight Gaps and Overlaps tool and remove all the no gaps and no overlaps topology rules, so we can now start keeping our parcel lineage history for the first time in over 20 months.

[AmirBar-Maor]

@AlanStearns1 

That's great to hear. We always welcome ideas about how to enhance the parcel fabric capabilities. @jcarlson can attest to that 🙂

Also - make sure you really need 'Geodatabase subtypes' - those should only be used if you have different topology rules or attribute rules. If they all have the same rules it is simpler to just use a field called something like 'MyTaxParcelType' and use it for symbology, feature templates etc.

Good luck

Amir

[Kathleen_Crombez]

I agree that the parcel fabric features should be subtyped for active and historic. This should be implemented as part of the Parcel Fabric Data Model.

We are finding dangles on the active lines that do not show up in the topology because there is a historical line connected to it.

I suspect as we start digging deeper there are going to be other topology issue we are missing due to the historical parcels being part of the validation.

One example were this could be a big issue is if you are trying to check all active lots are covered by an active subdivision and the active lot is only covered by a retired subdivision. This will not get caught in the topology as it is.

All of the fabric generated rules should be made for both types of data (active types and historic types)

[AmirBar-Maor]

The Highlight Gaps and Overlaps tool has been enhanced to work on all visible layers with ArcGIS Pro 3.3.
Using subtypes can add complexity to your rules, layers, and editing feature templates - so make sure you really need them.

[AmirBar-Maor]

The parcel fabric uses standard geodatabase topology, and since topology runs on the entire table, ignoring any filtering, it is not possible for it to ignore certain parcel states.

Maybe a better location for such an idea, for topology to ignore certain features using a SQL query, should be part of the geodatabase ideas?!