Can you animate a parcel lineage/ history in ArcPro Parcel fabric?

[Kara_Shindle]

So one of the original reasons we went to the ArcMap Parcel fabric was keeping track of parcel history.  We are looking at a conversion to ArcPro, and a new request has come up.

A genealogist wants an animated history of a parcel for a presentation.  I want to know if this is possible.  I'm imported our original fabric to ArcPro to test out records and I'm struggling to "backfill" the parcels history - seems like I might consider posting an idea for building out a parcels history for ownership/long searches, but I digress.

Is it possible to make a parcel fabric time aware without converting it out of the fabric?  Is there a way to animate it in the fabric or can anyone share if they have done it previously, and how?

[jcarlson]

You can sort of do it, but it requires some data manipulation.

The first issue you'll run into is that your parcel and line features don't actually have their own created/retired date fields. Those come from the associated record. For a feature layer to be time-enabled, the time attribute has to be part of the main table.

If you wanted just a per-map solution in Pro, you can do an ad-hoc join to bring in those attributes based on the associated record, but you'll need to make two joins, one of the created record, one for the retired.

If you're working with an Enterprise Geodatabase, you can also use a Query Layer to do this.

In our org, we actually have simple hosted feature layers that use a GUID field to sync with the "real" parcel fabric. In the hosted, layers, though, we use Python to "bake in" the timestamps from the associated records, so all of our hosted parcel fabric layers are time-enabled.

It can be complicated, and maybe not the right solution for other orgs. For us, though, it allows certain modifications to our public-facing cadastre, like the created/retired timestamps, that would otherwise be difficult to implement directly in the parcel fabric itself.

With those time-enabled hosted layers, we can then create time-enabled web apps, or bring the layer into ArcGIS Pro to create animations, etc.

[jcarlson]

Regarding "backfilling" the fabric. We call it "backdating" here, but it's something that's important to our long-term goals of fully documenting parcel genealogy for our county. It's our "2050 Goal", we like to joke. I don't know if that's an over or underestimate, honestly...

The Pro Parcel Fabric is meant to work in a "forward-looking" way, but it's not difficult to work things backwards. Here's our process for backdating a split, which is the most common change to our cadastre.

1. Create the historic record
2. Find the child parcels that already exist in your cadastre
3. Assign said parcels to the active record to show that they were created by it
4. Turn off the active record
5. Merge the child parcels using the Merge tool
   1. Merge to a new feature
   2. Make sure you keep the original features
   3. Copy the createdbyrecord GUID from the child parcels to the new feature's retiredbyrecord
6. Turn the record back on
7. Click "Build Active"

Why turn the active record off? When using Merge with parcel features in an active record, the parcel fabric will automatically retire the input features, because it assumes you're doing a new combination, not backdating an old split. With the record off, it does not retire the child parcels. But it also doesn't auto-calculate some of the record's attributes, so that's why we turn the record back on and click "build".

If you get serious about backdating, you'll quickly find that the stock "historic parcel" symbology makes it hard to see multiple generations of historic parcels at once. To deal with that, we work in a separate map in which the created/retired definition queries have been removed from the parcel and line layers, and we use layer blending modes to make it easier to see where multiple generations of parcels exit.

[AdamHart1]

@jcarlson 

That is very useful information. I have started the process of "back-dating" our parcel fabric as well and am trying to figure out the most efficient workflow to do this. I have 99.9% of our historic parcels already in the historic layer, so the steps you mentioned above wouldn't be the exact workflow I would use for back-dating. The steps I have done so far in my case are:

1. Create the record to get the GlobalID for the record.

2. Select the historic/current parcels involved in the historic split/combination.

3. Copy/paste the GlobalID of the created record into the "Created by Record" and "Retired by Record" fields of the selected parcels.

4. Build by extent

This seems to work okay for now, but I've noticed that if I try to build the record when all the associated parcels are historic, then the build does not work from what I can tell. So I am still learning the best workflow for this process. If you or anyone else has input on this, I'm sure I'm not the only one that would appreciate it. My department does have to do a lot of split history research, and this workflow would be hugely beneficial and more time efficient. Thanks

[jcarlson]

Yeah, we don't have our historic information. But if you have the features already, your workflow sounds like the right way to go.

What version of Pro / Parcel Fabric are you using? A recent update should have made "build record" consider retired parcels in generating the record geometry.

[AdamHart1]

I am currently using Pro 2.8.2. We haven't updated to 2.9 yet because of the compatibility issues with our version of Enterprise. If you think that is the issue, then I will see if we can can get upgraded. Thanks again.

[jcarlson]

It is indeed. I found the Idea I posted, an can confirm that this was added in 2.9.0.