Optional fields for parcel fabric, and best practices for schema changes?

447
1
Jump to solution
03-14-2023 10:23 AM
Labels (1)
AndrewWallick
Occasional Contributor

Is there a list anywhere of optional fields for the parcel fabric polygon feature classes? The help site has a list of the fields, but I don't see it saying if any of those are required or optional. 

We'd like to potentially delete the Calculated and Stated Area fields, since we already have our own fields for these.

We'd also like to delete a field we have called "Type." I think this might be a field left over from when we used the ArcMap Parcel Fabric. Are we safe to delete it now, or is it used by something?

Also, is there a recommended workflow for deleting fields, and also for deleting parcel types? the post below from 2020 was asking it but got no answers.

https://community.esri.com/t5/arcgis-parcel-fabric-questions/best-practices-for-parcel-fabric-schema...

0 Kudos
1 Solution

Accepted Solutions
AmirBar-Maor
Esri Regular Contributor

@AndrewWallick 

From your question, it looks like you were upgrading an ArcMap parcel fabric.

Any field that is required (aka 'system field) is listed in the help documentation and you cannot delete it. However, if you are used to call a field something else, you can always create a field alias on your layer after you publish the data. If there is a field you don't want to see, just turn it's visibility off. You can also highlight and reorder fields. You can learn more about it here.

Specifically for the 'Stated area' and the 'stated area unit' fields: when we perform a parcel merge for example, we sum the stated areas of the parent parcels in the child parcel and use the projects default area unit - so if you want this behavior we recommend that we use these fields. The calculated area field will be populated when there is enough COGO information to calculate it. You can then compare the stated area and the calculated area for QA.

Another last motivation to use these fields: we ship attribute rules with the software that use these area fields. It will make it easier for you to configure them.

As for any old ArcMap fields - we move them over so you can QA them, or calculate over values before you get rid of them. If you can delete them it means they are not needed anymore.

If you upgraded from ArcMap and have used the Local Government Information Model, you will find that many parcel types have fields that are irrelevant and should be deleted.

I hope this answer helps

Amir

 

 

View solution in original post

1 Reply
AmirBar-Maor
Esri Regular Contributor

@AndrewWallick 

From your question, it looks like you were upgrading an ArcMap parcel fabric.

Any field that is required (aka 'system field) is listed in the help documentation and you cannot delete it. However, if you are used to call a field something else, you can always create a field alias on your layer after you publish the data. If there is a field you don't want to see, just turn it's visibility off. You can also highlight and reorder fields. You can learn more about it here.

Specifically for the 'Stated area' and the 'stated area unit' fields: when we perform a parcel merge for example, we sum the stated areas of the parent parcels in the child parcel and use the projects default area unit - so if you want this behavior we recommend that we use these fields. The calculated area field will be populated when there is enough COGO information to calculate it. You can then compare the stated area and the calculated area for QA.

Another last motivation to use these fields: we ship attribute rules with the software that use these area fields. It will make it easier for you to configure them.

As for any old ArcMap fields - we move them over so you can QA them, or calculate over values before you get rid of them. If you can delete them it means they are not needed anymore.

If you upgraded from ArcMap and have used the Local Government Information Model, you will find that many parcel types have fields that are irrelevant and should be deleted.

I hope this answer helps

Amir