Editing Existing Parcel Records vs Creating a new Parcel Record

[RobertChaney]

Need clarification on when you would edit in an existing parcel record verse creating a new parcel record.

As part of building my parcel fabric I will run the GP tool create parcel records, to create the initial records.  This field will usually be based on a unique parcel number or a subdivision name (if the parcels are within a subdivision boundary).

I've noticed that when I create a new record and split an existing parcel, the new record boundary has the same geometry as the record that was initially created for the parcel being split.  Is this what I'm suppose to see?  I was  thinking that that new record would be just the geometry of the new split parcel.

Does anyone else create initial records for their parcel fabric or create them as you go?

My screen shot shows the same record boundary for parcel 11.001 and the new record for parcel 11.002

Thanks,

Robert.

Fabric ver. 5

file geodatabase

Pro ver. 3.2.1

[AmirBar-Maor]

@RobertChaney 

The purpose of having a record is to know the source of a parcel, and to make the data in the 'system of record' defendable.

Using the parcel name to create a record for each parcel, does not make any sense to me. It would be better to create a record called 'unknown' or 'legacy data' or 'Digitized from paper maps 1995'... something that would make sense when you identify a parcel.

If you've already migrated the data and already started creating real records, you can still recover:

1. Select all the parcels that were migrated (you can use 'Select by Attributes' and use the editor tracking fields).
2. Use the geoprocessing Create Parcel Records' and use the expression option to enter the name of the record. For example 'Legacy data - source unknown', and run it.
3. Open the attribute table of your records feature layer and make sure all the parcel based records are deleted (you can use the same method above to select them)

As for record geometry:

1. Record geometry will only be created or updated when the number of parcels associated with the record is less than 2000. This is done for performance and you can change this setting in the parcel fabric properties.
2. The record geometry is the union of the retired and created parcel geometries, as it is the footprint of the legal transactions and impacts both. For example: we have organizations that create a record to retire a lease - in that case they only retire parcels and do not create any new child parcels.
3. Certain operations like Build, Merge, Clip, Divide, Split ... will update the record geometry when you have an Active Record. Alignment workflows do not do that but you can always use 'Build Extent' to trigger an update.

I hope this helps, and more importantly, makes sense.

Amir

[MatthewBeal]

We initially had a single, catch-all record for our fabric but were experiencing a lot of long draw times and other random bits of weirdness. One of the suggestions I got from our consultant was that having one record that was essentially the extent of the entire county could be causing delays because it would be looking at the topology for the whole county rather than just the smaller individual polygons. We pretty much followed your steps, except in the expression builder we added the parcel number. So ours read like "A-01-002 | Legacy data - source unknown." That way, each individual record was still only the size of a regular parcel. This completely resolved our issues. 

[RobertChaney]

Matthew, 

 What your describing is basically what I'm doing to create the initial records, each parcel essentially is it's own record unless it's within a subdivision.  And instead of a expression, I'm just using an existing field within the parcel type.

Robert.

[DrewDowling]

I like your approach, it's like a hybrid. For what it's worth, we went with the single large catch-all record.

My understanding is that if a record has more than 2000 features, it won't calculate or update the geometry of the record during edit operations. We didn't see any performance issues related to this approach.

[RobertChaney]

Amir,

 Part of my workflow of migrating data to the parcel fabric data model is to create the initial records for the fabric.  Again, these records are based on a TaxParcel parcel type and a field that's populated with the original parcel number or a subdivision name if the parcel lies with in subdivision boundary.  So, I'm not sure what would be the point of trying to "recover".  Unless, it's necessary to indicated that these original parcels were brought over from another source and are to be considered legacy.  Once, real editing starts in the fabric new records are created and given a name based on a owner name, new parcel number, etc.

So, is it recommended that records initially be created as part of the parcel fabric migration?  I believe this was something I saw in the video (Parcel Fabric: Migrating and administrating parcels with ArcGIS Pro).

Also, would there ever be a situation where you would set a existing record as the active record and edit under that record?

Thanks,

Robert.

[AmirBar-Maor · Accepted solution]

@RobertChaney 

Records can be created, deleted, and associated with parcels at any point of time.
Different organizations will use different conventions for their records: some will use the recorder number (or land registration) which will allow them to easily integrate to their  3rd party systems (e.g. CAMA. land registry, document management...), some use a meaningful name like the subdivision name.
Whatever you use, it will be good to be able to tell the difference between:

1. Data with a missing record (CreatedByRecord IS NULL)
2. Data that was created after the data migration and has a good parcel lineage
3. Legacy data 

There are situations when you activate an old record. One example I can think of is fixing bad boundary lines by re-entering them from the record. The workflow might look something like this:

1. Select the parcel to fix
2. From the Active Record HUD, activate the record from the selected parcel
3. Shrink the parcel to seed
4. Delete the bad lines and re-enter them from the legal record
5. Reconstruct from seeds

[RobertChaney]

Amir,

 Thank you for the update and clarification.

Robert.

[AmirBar-Maor]

The first version of the Parcel Fabric, Parcer Fabric version 1, did not have the ParcelCount field on the records, which meant the 'one record' approach would take a very long time to process.

Since parcel fabric versions 1, 2, and 3 have all been deprecated, using a single record will not take a longer time to process. If you want to use the Parcel LIneage depiction using link charts, you probably want to use records that make sense (not just create one for each parcel).

 

[MatthewBeal · Accepted solution]

So would you advise that I go back and merge all those pre-fabric parcels back into one record?