Undo Transactions in Parcel Fabric and Historical Records

Question

All:

My org is implementing the Parcel Fabric in ArcGIS Pro and we are getting troublesome results using the Undo functionality, as it does not appear to undo all the transactions on the various layers participating in the Parcel Fabric such as Historic layers.

Has anyone ever encountered this issue with the undo operation on the Parcel Fabric?

If you have how were you able to prevent it or at least minimize its impact on the accuracy of your historic layers without having to perform time consuming clean-up work?

CathyAppleton · Answer

Hi,

your workflow sounds very similar to ours, in trying to figure out the best way to edit parcels when it is not a simple split or merge but a combination of both with some realignment thrown in as well lol.

yes, historic parcels are created on any pf feature split, merged or divided.   the only time we have noticed the Undo not removing any processes and taking us back to a clean state/step, is when we have saved our edits sometime during the steps/edits.

I'm not well versed in back end settings, so this is just a total guess, but maybe you have automatic save setting on?    again just a guess.

that would be set under...

To automatically save edits in ArcGIS Pro, you can:* Click the Options dialog box launcher in the Manage Edits group on the Edit ribbon tab
* Click the Editing side tab and expand Session
* Check the Automatically save edits check box
* Choose a recurring save cycle
* Click OK

You can choose to save edits based on:* Time interval: Save edits after a specified number of minutes have elapsed
* Number of operations: Save edits after a specified number of operations have been performed

Please let me know if that helps,

Cathy

Enterprise v 11.2, SQL Server 2019
ArcGIS Pro 3.3.1
Branched versioning (parcel fabric)

MikeVolz · Answer

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

CathyAppleton · Answer

Hi Michael,     We use the PF in our county.   Can you please give me a brief description of what you did, then tried to undo, and what the results were?     Then I can see if we have experienced the same thing.

Thanks, Cathy