Data loading considerations
To load clean and validated topologies to a parcel fabric use the Load A Topology To a Parcel Fabric geoprocessing tool. In Catalog it is located under System Toolboxes > Parcel Fabric Tools > Data Migration.
This topic discusses a few factors to consider when loading parcel data into a parcel fabric, such as the migration of parcel attributes and the migration of overlapping parcel polygons.
Types of attributes
There are three key categories of attribute fields in the parcel fabric.
- Geometry and System attributes are read-only and updated by the system when you change other related attributes. Examples include Shape, ShpStdErrE, and ShpStdErrN.
- Private attributes cannot be changed directly in the table window, nor in the core editing attributes dialog. These attributes are changed in the parcel editing controlled environment, such as in the Lines grid after opening a parcel. Examples include Bearing, Distance, and Radius.
- Public attributes are completely open for editing in the table window and in the editor’s attributes dialog, and also in the property pages when you click Open Parcel. Fields that are added when you enable an information model, such as the LGIM, are also all in this Public category. Examples include Name, StatedArea, Accuracy, and Type.
Loading attributes
When migrating attribute fields to the parcel fabric, be aware that many attribute fields on the parcel fabric tables store common parcel maintenance attributes such as parcel PINS and area. If you maintain attribute fields that are represented by the parcel fabric attribute fields, you should change the names and types of these attribute fields so that they can be migrated to the correct parcel fabric attribute fields.
If you are loading parcel data to the parcel fabric Local Government Information Model, attribute field mapping is done in the staging environment.
The following attribute fields are used on the parcel fabric Parcels table:
Attribute field name | Field type | Migrating parcel polygon attributes |
---|---|---|
Name | String | Fields named Name, PINParcelName, LOT, or APN are migrated to the Name attribute field. |
StatedArea | String | Fields named Area or StatedArea are migrated to the StatedArea attribute field. |
Accuracy | Long | Fields named Accuracy or AccuracyCat are migrated to the Accuracy attribute field. |
Type | Long | Fields named Type are migrated to the Type attribute field. |
Historical | Long | Fields named Historic are migrated to the Historical attribute field. Set to true if the parcel is historic. |
LegalStartDate | Date | Fields named LegalStartDate or LegalStart are migrated to the LegalStartDate attribute field. |
LegalEndDate | Date | Fields named LegalEndDate or LegalEnd are migrated to the LegalEndDate attribute field. |

In a parcel fabric enabled with the Local Government Information Model, some parcel fabric attributes use aliases. For example, the Name attribute uses an alias named Parcel Identification Number on the Tax Parcels layer and uses an alias named Lot or Unit Number on the Lots and Units layer.
If any of the following fields are missing on your source parcel polygons, corresponding fields on the parcel fabric parcels table will have the following values:
- No PIN, ParcelName, LOT, or APN field: parcel is given the name of the polygon feature class suffixed by _1, where 1 is incremented for each parcel, that is _1, _2, _3, and so on.
- No Area field: StatedArea is populated with the area of the polygon shape geometry, provided that Compute Area for New Parcels is chosen on the Load a Topology to a Parcel Fabric dialog box.
- No PlanName field: Parcels are migrated to the default <map> plan.
- No AccuracyCat field: accuracy category of parcels is inherited from their associated plans. If no accuracy is defined for a plan, the internal, default accuracy category of 4 is used.
If parcels are migrated to the default <map> plan, they will inherit the internal, default accuracy category of 4.
- No LegalStart field: LegalStartDate = NULL.
- No LegalEnd field: LegalEndDate = NULL.
The following attribute fields are used on the parcel fabric Lines table:
Attribute field name | Field Type | Migrating parcel line attributes |
---|---|---|
Category | Long | Fields named Category are migrated to the Category attribute field. Use a Category field to migrate lines that are not boundary lines, for example, connection lines. |
Calculated | Long | Fields named Calculated are migrated to the Calculated attribute field. Use a Calculated field to flag lines that have COGO generated from the shape geometry (and not legally correct COGO). |
Type | Long | Fields named Type are migrated to the Type attribute field. ![]() The line type should match the type of the line's associated parcel. |
Accuracy | Long | Fields named Accuracy or AccuracyCat are migrated to the Accuracy attribute field. |
The line type should match the type of the line's associated parcel. If you have not populated this field prior to migration, you can populate this field after migration.
If any of the following fields are missing on your source parcel lines, corresponding fields in the parcel fabric lines table will have the following values:
- No Category field: Category = Boundary line (all lines in your parcel fabric will be set to the Boundary line category).
- No Calculated field: Calculated = NULL.
- No AccuracyCat field: Accuracy category = NULL, accuracy category is inherited from the parcel.
If there is no accuracy defined for the parcel, then an internal, default accuracy category of 4 is used.

Additional attributes
If you would like to migrate additional attributes fields that do not match the attribute fields of the parcel fabric or of the Local Government Information Model, then you need to create these same attribute fields on the parcel fabric Lines and Parcels table for your attributes to migrate across successfully. Additional attribute fields are only migrated to the parcel fabric if the same, corresponding attribute fields exist in the parcel fabric Lines and Parcels tables.
Learn how to add additional attributes to parcel fabric tables
Loading plans
Plans are migrated to the parcel fabric by populating a PlanName field on your source polygons table. Each parcel polygon can have either a NULL PlanName attribute or a plan name string. When the polygons are migrated, an entry for each unique plan name is added to the Plans table in the parcel fabric. If there is a NULL PlanName attribute, the parcel is migrated to the default <Map> plan. If you are loading parcel data to the parcel fabric Local Government Information Model, a PlanName attribute field is already created in the parcel polygon staging feature classes.
Line points
Line points are not detected during the data loading process. You can use the Merge Parcel Courses tool to merge collinear line segments (within a specified tolerance) into a single line. Once lines are merged, any adjacent parcel points sitting on the line become line points.
Overlapping parcel polygons
When loading parcel data to a parcel fabric Local Government Information Model, parcels are separated by type in the staging environment and loaded in separate topologies for each type. Separating parcels by type avoids overlapping parcels of different types being migrated in a single topology.
However, overlapping polygons can be migrated as long as the corresponding lines of the overlapping polygons do not overlap or intersect any other lines. If lines overlap or intersect, the [Line feature class] Must Not Intersect Or Touch Interior topology rule of the Load A Topology To a Parcel Fabric geoprocessing tool is violated. For example, the overlapping polygons below will migrate successfully:
These overlapping polygons will violate topology rules and will not migrate the parcel fabric:
Overlapping polygons that have intersecting boundary lines need to be separated and migrated as separate topologies. In other words, each strata of overlapping polygons needs to be migrated separately.