Loading historic data to parcel fabric

[Ulises]

We are evaluating moving to the parcel fabric model.  As today we manage our parcels in a single polygon feature class with archiving enabled for several years.  Is it possible to load that historical data to parcel fabric if we go with that data model?  We already have 2 sets of data that we use for historic reference previous to the implementation of the archiving functionality.  We don't want to use 3!  Thanks in advance for your feedback.

[jcarlson]

With your archiving model, do you mean that you just look "back in time" on the database to see historic features, but that when you're in the "present", those historic features aren't there?

Also, is there some field you have to link a parcel to the document that retired it?

Maintaining historic data in the parcel fabric is excellent, and provided you have some way to populate the "retiredbyrecord" field, it's a painless process getting historic features in.

You may need to be careful about misalignments, however. Suppose a boundary was adjusted after a parcel was retired. Copying the historic pre-adjustment parcel will create an disparate edges in the topology, and may create a bit of cleanup work for you. But having the historic data is better than not, and well worth the cleanup, I say.

[Ulises]

Hi Josh, thanks for the quick reply.  I understand that if I migrate my parcels to parcel fabric I start fresh with the new features.  I believed that would mean not having to use a versioned parcel fc as of today and start using the parcel fabric features in our workflows but then our users will need to either continue to use the version history by the archived model enabled (if still versioned) or reference a new feature class exported from the archive before unversioned the parcel fc.  By your comments can I assume there is a way to import into the parcel fabric model all that information in the archived table using the "retiredbyrecord" field?

Again thanks for the feedback and sorry if I'm still not clear in my thoughts. 

[jcarlson · Accepted solution]

In the Pro Parcel Fabric, everything is governed by Records. If the globalID of a record is present in the retiredbyrecord field, then the parcel is retired, and designated as having been retired by that record in particular.

Assuming your parcels have some kind of attribute saying what record / document retired it, you can use a field calculation to populate the appropriate globalID, but you'll need the records to exist first. Check out Create Parcel Records, too, as I think you can use that to create the records easily.

I'm not sure how your users currently utilize your system, but with the new parcel fabric, you don't have to make use of archiving at all (though you can if you like).

We publish a hosted copy of our parcels to our enterprise server, but do a little bit of data manipulation to "bake in" the record attributes like document name and recordation date. By doing it that way, we can just have a time slider for our parcels and users can see the parcels at any point in time of their choosing.

[Ulises]

Thanks a lot for the feedback, Josh.  I will research on those pointers.

Regards

[JasonCamerano]

Hey @Ulises 

Looks like @jcarlson gave you a lot of good info!

I'll give some extra descriptions on how best to evaluate your data and a possible workflow for that portion of migration.

First, like Josh said, you need to determine which field on your polygon data is a unique representation of the document that created that "parcel".  If you have a unique value or you have a related table that has the unique values on there, (join them over if that's the case) you can then run the Create Records GP tool once the polygons have been appended into the fabric data model.  It will then create a unique Record assigned to a GUID that will then be placed in the Created By Record field of the parcel polygon in the parcel fabric. 

Now you have all your parcels as current in the pro parcel fabric.

If your data has a field that represents the recorded document that retired it and if that recorded document has the same unique name  of the Records that were created via Create Record you can do some database joining to determine the GUID that will need to be assigned to the Retired By Record field so you can basically see a linage of parcel transactions.

However, if you do not have this relationship in your data and you just have parcels that are historic you can simply do a field calc on the Retired By Record field on all the parcels in the Parcel Fabric and set the value to {DDDDD-DD....DDDDD}.  Just a bunch of the letter D in the format of a GUID.  This will make them show up as historic in Pro and be symbolized as so.

Hope that's clear.  Let me know if you have any other questions.

[Ulises]

Thanks Jason