Select to view content in your preferred language

Topology should ignore parcel fabric lineage history records

1188
14
06-20-2022 10:52 AM
AlanStearns1
New Contributor II

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.

14 Comments
AlanStearns1

@AmirBar-Maor, perhaps this is the reason @Kathleen_Crombez suggested "This should be implemented as part of the Parcel Fabric Data Model". The Parcel Fabric team could work with one/more other development teams to overcome the issue you describe. Topology is such a powerful and simple to use tool for maintaining spatial data integrity. Its really a shame that we can't use it properly in the Parcel Fabric. As I previously mentioned, we had to drop over two dozen custom topology rules in order to retain parcel lineage history.

AmirBar-Maor
Status changed to: Under Consideration
 
AmirBar-Maor

@AlanStearns1 

I've switched this idea to 'Under Consideration' and we can explore it again. 

 

Kathleen_Crombez

@AmirBar-Maor-

We currently do not use sub-types for current and historical parcels.

We wrote a custom process that exports the current and historical features into separate feature classes and created two separate sets of topology rules. One for all current features and one for all historic features.

This process is not ideal because it will only identify the errors which then need to be corrected in the actual fabric and then re-exported and checked again after the data is corrected.

If sub-types were built into the parcel fabric data model we would not need to do all these extra custom quality control checks. However, I really do like the idea of allowing SQL queries in the topology rules. That would beneficial in many scenarios.