Access to update Parcel Type names through arcpy or automatically

[ChristalHigdon_USFS]

When copying a parcel fabric dataset using the Copy Tool, and using the associated data parameter to rename the parcel fabric dataset and parcel type feature classes, the Properties still reflect the original Parcel Type names.

Background:
Our entire process is scripted using arcpy. We go through creating the base file geodatabase with the parcel fabric schema, additional business/related tables, spatial reference, etc and then we make copies of it for processing each region’s data to break it up, then ultimately append them back together again into a single CONUS fabric. The Alaska region has a different spatial reference and has to be renamed because the datasets will reside in the same enterprise geodatabase. We use the arcpy.management.Copy gp tool to copy the Feature Dataset and rename everything using associated data input. This includes the parcel type feature classes but does not include the Parcel Type names found in the Properties/arcpy.Describe. 

I would like for the Parcel Type names to be updated through exposing this property in the associated data mapping of the arcpy.management.Copy tool, or else have the controller automatically update them, or else have a tool in the Parcel Tools administrative toolbox that we can run to update the Parcel Type names (via arcpy) after the copy. 

[AmirBar-Maor]

If I understand correctly (please confirm) you have:

1. A base geodatabase that you use as a template
2. You use Python to copy it to the different areas in Alaska
3. You would like then to stitch those pieces together

Questions:

1. Is the description above correct?
2. Did you try to use the XML workspace schema to create an empty geodatabase for each region?
3. Did you consider using the geoprocessing tool Append Parcels to stitch the regions back together? In that case, you want the parcel type names to be identical.

[ChristalHigdon_USFS]

Hi @AmirBar-Maor thanks for taking a look. The background provided was to illustrate our overall process. We have a base file geodatabase where the parcel fabric is created and we copy those for the individual contiguous 48 states for processing our large amount of complex data in smaller chunks. That is all well and good and have no issues putting them back together again.

The issue is copying that base parcel fabric geodatabase for Alaska, which has some differences and will remain separate from CONUS data. We want the same structure with additional fields, tables, relationship classes, but need to rename the dataset, parcel fabric, parcel type feature classes, and relationship classes because they will ultimately live in the same enterprise geodatabase and be branch versioned and published for multi-user editing. 

So the issue is: We are successful at copying the CONUS Feature Dataset and renaming what we need to with the associated data mapping for Alaska, however it does not include the Parcel Type Names in the Properties of the Parcel Fabric as a parameter in the associated data string. We feel like the Parcel Type names property should match the parcel type feature class names as it does out of the box when created (see screenshot in original post for example of how it does not match after Copy). So if I then go in and programmatically list (arcpy.Describe on the parcel fabric) it will not return the parcel type names that match the feature classes I was able to rename in the Copy associated data mapping, and I would like it to. If the Copy tool's associated data parameter allows me to change the names of all of the items, including the parcel fabric controller, it should include the Parcel Type names.

[AmirBar-Maor]

@ChristalHigdon_USFS 

By design we allow these properties to be independent of each other:

1. Feature class name
2. Feature class alias
3. Feature layer name
4. Parcel type name

This means that you can modify each one independently of each other.

Why? here are common reasons:

1. The feature class name is a table name and must abide by DBMS standards (e.g. no spaces). We also append an underscore and a number to guarantee that it has a unique name within a workspace. That table name might also be used in database views and SQL queries, so some organizations keep it short.
2. Feature class alias name can contain spaces and be long as needed. It is used as the default feature layer name when added to a map.
3. You can have multiple feature layers point to the same table, so each can have a meaningful name. For example: current parcels versus historic parcels.
4.  The parcel type name is the logical name for a parcel. Some countries only have one. We use that as the default name for the feature classes when you create a parcel type.

The geoprocessing tool mentioned above, Append Parcels, is smart enough to ignore any changes that have been made to the table name and rely on the parcel type name. So you can ignore any underscores in the table name if you have multiple tables in the same workspace. If they were coupled, we would have to add an underscore and a number to the parcel type name if there was a collision in the table name.

I hope this makes sense

Amir

[ChristalHigdon_USFS]

Thanks @AmirBar-Maor that does make sense. My request still stands that if we want to alter the feature classes AND the parcel type name property, I would like the parcel type name property to be exposed for update, either through the Associated Data parameter or a Parcel Toolset (maybe under Administrative?), so I could change it without having to open Pro and do it manually since our entire process is automated using arcpy. That's great they are independent but please expose it so I can change it in a similar manner as the feature class names that participate in the Parcel Fabric.