nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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.

Find more posts tagged with

In Product Plan

Status: In Product Plan

Comments

ChristalHigdon_USFS

Great news @AmirBar-Maor! I definitely prefer straightforward over work-arounds. We are migrating into Parcel Fabric for our entire federal agency, and needed a solution now for our data set up and migration though. I hope the python access will help others in the future. Even the ability of the Copy tool to use field mapping to change the parcel type names would be a great solution. Thank you for considering this need.

Amir Bar-Maor

@ChristalHigdon_USFS
A clever workaround indeed.

Regardless, we so plan to implement a more straightforward python access to the PF properties.

ChristalHigdon_USFS

UPDATE for anyone searching how to do this. I got a clever work around on a thread about Esri all of a sudden stopping the functionality of Define Projection on a dataset, which threw a wrench in our workflow. In implementing that work around, I saw I could use the same method to change the parcel type names.

Here is the post for the code sample:
https://community.esri.com/t5/arcgis-pro-questions/unable-to-define-projection-on-undefined/m-p/1629826

Kudos to cmathers!

The workaround I used based on the code in the post above:

Export the template FGDB to a JSON with the Generate Schema Report tool.
Edit the parcelTypeNames in JSON using re.sub() (also needed to adjust the spatial reference since in 3.5 Esri [intentionally] broke the functionality we had long relied on for DefineProjection).
Convert the Schema Report to an XML Workspace with the Convert Schema Report tool.
Create an empty FGDB.
Then apply that to a new FGDB with the Import XML Workspace Document tool.

Amir Bar-Maor

@ChristalHigdon_USFS

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.

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.

Amir Bar-Maor

@ChristalHigdon_USFS

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

Feature class name
Feature class alias
Feature layer name
Parcel type name

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

Why? here are common reasons:

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.
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.
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.
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

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.

Amir Bar-Maor

If I understand correctly (please confirm) you have:

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

Questions:

Is the description above correct?
Did you try to use the XML workspace schema to create an empty geodatabase for each region?
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.