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.
If I understand correctly (please confirm) you have:
Questions:
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.
By design we allow these properties to be independent of each other:
This means that you can modify each one independently of each other.
Why? here are common reasons:
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
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.
Thanks for your input. That makes sense.
If we implement this, we are likely to expose all of the parcel fabric properties, not only the parcel names.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.