Hi Cathy:
I hope this response is not information overload. I will divide the response into 3 sections.
Lack of control over which edit operations generate Historic Parcels
Clip, Merge, and Delete generate Historic Parcels, but Align Parcels does not
Due to the frequently erratic and terrible output of the Align Parcels tool, it’s often necessary to fix the alignment issues between new parcel(s) and existing surrounding ones by using a series of Clip & Merge operations – all of which are generating a plethora of intermediate Historic Parcels all the while
If Historic Parcels are to be of any real use, they need to be “clean” – that is, they should ideally only contain the original pre-edit state of the parcel, and nothing more
As a result, it’s now incumbent upon the parcel editor to manually clean-up the contents of Historic Parcels, deleting both the polygon and line features of those intermediate states which were captured
This process is exceedingly tedious to say the least, and made worse by how easy it is to select features which may be shared by other active/current parcels – and which, if accidentally deleted, will directly result in topology validation errors which, in turn, must be fixed
Incomplete Undo results
Most noticeable when attempting to Undo bad output from the Align Parcels tool, it is almost always the case that it will not fully undo all of the numerous operations within that edit transaction chain
i.e. certain lines and points which were Retired By Record do not get un-retired, creating either extra or missing lines that lead to topo issues when parcels are rebuilt
The only work around is to Save often and fully Discard any edit operations w/ bad results, and retry the edit
Questionable use of Historic Parcels
ESRI’s own best practices dictates that general users not be given direct access to the Parcel Fabric – parcel editors alone are to have access to the controller dataset as it exists in the Enterprise environment
Rather, downstream GIS users/consumers of the parcel data are to access derived feature class(es) – including any need for Historic Parcels
Since Historic Parcels are queried by date/time stamp, this means that users would need to request a given output Historic Parcels layer (likely in a FGDB) to use, creating a new management workflow to handle these new derivative datasets
At minimum, any real use of Historic Parcels is clunky at best, as the people most likely to want to see/use them are the very people who can’t access the Fabric directly
