Yearly Historical export/snapshot/archive in ArcGIS Pro

[Paul_Christensen]

While using the traditional Polygon/Line parcel system, once I transitioned to the next tax year, I would copy my working .gdb and rename it. For instance "Landrecords2020.gdb" to "Landrecords2021.gdb". The new .gdb would become my working .gdb and the previous year was 'archived'.

This method gave me a historical feature class that I could then add to my map, and by adding all of my previous years layers, view how an area has changed throughout the years.

I know the AGP Parcel Fabric uses retired parcels to represent historic parcels. However, what is the best workflow to keep a running history throughout the years? Should I continue my method of 'archiving' my past .gdb or maybe just export a snapshot of my working .gdb? 

I want to be able to see how an area has changed throughout the years and I just don't know if the fabric's method of retiring parcels will show this as effectively as my current method especially for non-record driven edits such as QA/QC where a retired parcel is not created.

Do yall just use one .gdb throughout the years and use the retired parcels for this?

[jcarlson]

We create yearly snapshots in our county as well, and we find it's quite easy to do with the Pro Parcel Fabric, though you'll need to create two joins, or use a query layer in order to get the recordeddate attribute from the Records table.

I'd suggest the query layer if you're competent in SQL, as it allows you to control the output field names. Note, however, that if you're using the Pro Parcel Fabric in an SDE as opposed to a FGDB, you'll have branch versioning to contend with, and your SQL will need to be carefully crafted to avoid grabbing earlier edits of an object.

Suppose you wanted to get the active parcels from the end of the 2018 tax year. Here's how you might do it.

1. Get the Records table joined to your parcels table twice.
   1. The first join is matching the parcel's createdbyrecord attribute and the record's globalID.
   2. The second is the same, but with the parcel's retiredbyrecord attribute.
   3. If using a query layer, you can bring the recordeddate attribute in from the records table as more user-friendly field names, such as created_date and retired_date.
2. Apply a definition query like this:
   

   created_date is null OR created_date < 01-01-2019
   AND
   retired_date is null OR retired_date >= 01-01-2019

There you go! You've got yourself your parcels, filtered down to those which existed at the end of 2018.

Another note: if you opt to use a query layer, you can work those date-based filters into the query statement itself rather than using a definition query after the fact. Then you can also take advantage of the much-underrated query layer parameters, and sub a dynamic parameter in for the date. Then you can simply adjust the parameter in the Time or Range slider to see your query layer update on the fly.

Maybe "easy" was a bit of an overstatement. But it's not terribly complicated. In my county, we actually publish our query layer out as a hosted feature class in our Portal, and then apply view definitions to hosted view layers for each year. No need to duplicate most of your parcels each year!