About migrating parcel data using the Import Fabric Data wizard
This topic applies to ArcEditor and ArcInfo only.
The Import Fabric Data wizard migrates to the parcel fabric existing parcel data that has been formatted into a dataset of related point, line, and polygon feature classes. This format is known as a fabric source and is the same format as that of a COGO coverage, which can be migrated directly to the parcel fabric.
Instead of using the Import Fabric Data wizard to migrate data to the parcel fabric, you can use the Load A Topology To A Parcel Fabric geoprocessing tool, which loads a clean topology containing a parcel line and polygon feature class to the parcel fabric. You would use the Import Fabric Data wizard to migrate entire datasets and coverages to the parcel fabric. The dataset, however, does need to be formatted into a fabric source. With the Load A Topology To A Parcel Fabric geoprocessing tool, only sections of data that are topologically clean need be migrated at a time. Less data formatting is required when using the Load A Topology To A Parcel Fabric geoprocessing tool.
Learn more about loading a geodatabase topology to the parcel fabric
To successfully build a parcel fabric source for the Import Fabric Data wizard, an understanding of the parcel fabric data model is necessary.
The parcel fabric data model
Parcels in the parcel fabric comprise parcel line features, parcel point features, and parcel polygon features. Parcel topology is stored explicitly through shared, common parcel point features.
Parcel lines represent the boundaries for parcel polygons. Each parcel polygon has its own set of boundary lines, and thus there are two boundary lines representing a shared boundary. Parcel lines also include connection lines and radial lines. Parcel lines store dimension attributes, which ideally should match the dimensions on the record of survey. Each parcel line in the parcel fabric is a two-point line, from one point to the other. These points are the parcel point features.
Most parcel points represent parcel corners. Parcel points can also represent center points of curved boundaries and endpoints of connection lines. Parcel corner points are common points between shared parcel boundaries. Parcel boundaries share the same parcel corner point with neighboring boundaries, thus establishing connectivity in the boundary network. Parcel points store x,y,z attributes, which are initially generated from either data migration or parcel joining and are adjusted by the fabric least-squares adjustment.
 |
Parcel fabric topology |
Formatting feature classes for data migration using the Import Fabric Data wizard
Existing, parcel-based data needs to be formatted correctly to be migrated into the parcel fabric using the Import Fabric Data wizard. The three primary features that comprise a parcel in the fabric need to be well defined, in separate feature classes, in the source data. These are the features:
- Parcel lines
- Parcel corner points (nodes)
- Parcel polygons
All three feature classes need to have the same name, but with the lines feature class being _arc (note the underscore), the points feature class being _node, and the polygons feature class being _polygon. Feature classes that have been correctly formatted to be successfully migrated into the parcel fabric are known as fabric source data.
|
|
COGO coverages are also considered fabric source data but are already in the correct format for data migration into the parcel fabric.
Tip:You can download the Parcel Fabric Source Builder toolbar from ArcScripts. This toolbar provides utilities for generating a parcel fabric source from an existing parcel or line feature class.
Source parcel lines
Parcel lines in the fabric store recorded dimensions in COGO attributes.
 |
Parcel fabric line attributes |
Lines being migrated into the parcel fabric, or source parcel lines, should have the same COGO attributes. The data migration process builds the fabric parcels using the dimensions stored in the COGO attributes on the source parcel lines (not from the line shape geometry). If there are no values in the COGO attributes on your source parcel lines, the data migration process will invert the line shape geometry to generate dimensions and populate the COGO attributes. The parcels are then built from the line shape geometry.
Source parcel lines should be individual line segments that connect to form the parcel polygon. Source parcel lines should not be polylines or multipart features.
Required COGO fields
The following COGO fields are required in your source parcel lines table:
|
Field name |
Field type |
Description |
|---|---|---|
|
Bearing (or Angle, Direction, or Azimuth) |
String |
The bearing/direction |
|
Distance |
String |
The distance |
|
Radius |
String |
The distance from the center point to the arc of a curve |
|
Delta |
String |
The angle at the center of a curve |
|
Arclength |
String |
The length of the curve arc |
|
Side |
String |
Specifies whether the curve is extending left or right |
The bearings (directions) of your source parcel lines should be stored in a Bearing (or Angle, Direction, or Azimuth) field. The bearing units can be set to any of the units supported by the data migration process. You can set your source units in the Import Fabric Data wizard. These units are as follows:
- Degrees/Minutes/Seconds
- Decimal degrees
- Radians
- Gons
- Gradians
The direction types supported by the data migration process are these:
- Quadrant bearing
- North azimuth
- South azimuth
- Polar
The parcel fabric is created as a new node under a feature dataset. Therefore, the parcel fabric inherits the spatial reference of the feature dataset. The distance units on your source lines should be set to the units of the spatial reference of your parcel fabric.
Required topological fields
In addition to the COGO fields, the following topological fields are required in your source parcel lines table:
|
Field name |
Field type |
Description |
|---|---|---|
|
FNODE_ (or FROMPT or FROMPOINT) |
Long integer |
The from-point of the line |
|
TNODE_ (or TOPT or TOPOINT) |
Long integer |
The to-point of the line |
|
LPOLY_ (or LEFTPOLY or LEFTPOLYGON) |
Long integer |
The left polygon |
|
RPOLY_ (or RIGHTPOLY or RIGHTPOLYGON) |
Long integer |
The right polygon |
The FNODE_ (or FROMPT or FROMPOINT) field stores a reference to the from-point of the line. The line feature references the from-point in the corresponding point feature class (_node) by the point's system COGO feature ID. Similarly, the TNODE_ (or TOPT or TOPOINT) field stores a reference to the to-point of the line, and the system COGO feature ID of the to-point is stored in the TNODE_ field. The left parcel polygon is on the left side of the parcel line going in the direction of the from-point to the to-point. The polygon in the corresponding polygon feature class (_polygon) is referenced by system COGO feature ID in the lines table. Likewise, the right parcel polygon is on the right side of the parcel line going in the direction of the from-point to the to-point and is referenced by the system COGO feature ID.
 |
Arc-node topology |
 |
Referencing the from-point in the source parcel lines table |
 |
Referencing the right polygon in the source parcel lines table |
Optional fields
The following fields are optional on your source parcel lines table. Depending on the quality of data being migrated, some of these fields may be necessary. For example, if you are maintaining connection lines (across roads or to control points) in your source parcel data, the Category field is necessary for specifying the connection line category. If you are assigning accuracy levels to some or all of your parcel lines, an AccuracyCat field is necessary for specifying the accuracy category or level. By default, all parcel polygons and their lines are assigned an accuracy level of 3, unless otherwise specified in the AccuracyCat field on your source parcel lines or polygons.
|
Field name |
Field type |
Description |
|---|---|---|
|
Category |
Long integer |
The line category (for example, boundary line or connection line) |
|
Calculated |
Long integer |
True if dimensions are inverted from line shape geometry |
|
Type |
Long integer |
Used for custom subtypes on the lines (for example, road frontage, back lot line) |
|
AccuracyCat (or ACCURACY) |
Long integer |
The accuracy level of the line |
Tip:The Type field is used when you have your own custom subtypes on your source parcel lines. You will need to create the same subtype on the system Type field of the parcel fabric lines table for your subtypes to migrate successfully.
If any of the optional 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 Type field: Type = NULL
- No AccuracyCat field: Accuracy level = 3
Setting connection lines in your source parcel lines
You can set up connection lines in your parcel data before migration into the parcel fabric. In the parcel fabric, connection lines can be added as a side shot leg in a parcel traverse or by using the Create Connection tool on the Parcel Editor toolbar.
Follow these steps to add connection lines to your source parcel lines:
- Create a Category field on your source parcel lines table.
- In ArcMap, add your connection lines using standard editing tools to your source parcel lines feature class.
- Set the category of the new lines to 3 (connection).
- Load both your source parcel points and source parcel polygon feature classes.
- Create new points/nodes at the endpoints of your newly added connection lines.
Add new nodes to endpoints of connection lines. - Populate the FNODE and TNODE attributes of your newly added connection lines. The FNODE and TNODE values are found under the underscore (_) or pound sign (#) field in the source parcel points feature class.
Populate from- and to-node values. - Populate either the LPOLY or RPOLY attributes of the newly added connection line. The LPOLY or RPOLY values are found under the underscore (_) or pound sign (#) field in the source parcel polygons feature class.
Populate LPOLY and RPOLY values.
Source parcel points
Parcel points in the parcel fabric store x,y,z coordinates for the parcel corners. Initial coordinates are generated during the data migration or parcel joining process, and the x,y coordinates are updated in a fabric least-squares adjustment.
 |
Parcel fabric points table |
Lines being migrated into the parcel fabric should have a corresponding feature class of points or nodes (_node). The points are the endpoints of the lines and are also the parcel corner points. For adjacent parcel corners, there is one common point. Common points maintain topological integrity between parcels and define connectivity in the network. Source parcel lines reference the points by their system COGO feature IDs.
You do not need to have x,y,z fields on your source parcel points. These values are generated from the point shapes during the data migration process.
Required fields
The following COGO system field is required on your source parcel points table:
|
Field name |
Field type |
Description |
|---|---|---|
|
Your feature class name with an underscore |
Long integer |
System field required for data migration |
For example, if your points feature class name is AlachuaCounty_Node, you will have a system field on your points table named AlachuaCounty_. This system field is populated with the feature IDs of the points and is the field that is referenced by the parcel lines table when populating the FNODE_ and TNODE_ fields.
 |
System field on source points table |
Optional fields
The following fields are optional on your source parcel points table:
|
Field name |
Field type |
Field Description |
|---|---|---|
|
Category |
Long integer |
The point category, for example, corner point or center point |
|
LinePntParcel (or Linepointparcel) |
Long integer |
The feature ID of the adjacent parcel (in the COGO system field in the _polygon table), which has the line point on its boundary line |
The LinePntParcel field is used for assigning line points to parcel corner points. A parcel corner point becomes a line point when it lies on the boundary line of an adjacent parcel. You would want to assign a line point to a parcel corner point to prevent it from splitting the boundary line on which it is sitting. In this way, the original recorded measurement of the adjacent boundary line is preserved in the parcel fabric, not split into two separate lines by the neighboring parcel corner point. For example, in the graphic below, parcel point 32 is a corner point for parcels 1553 and 1552 and is a line point for parcel 1550.
 |
Line point 32 on parcel back lot boundary |
If any of the optional fields are missing on your source parcel points, corresponding fields on the parcel fabric points table will have the following values:
- No Category field: Category = NULL
- No LinePntParcel field: No line points assigned to parcel points
Parcel polygons
Parcel polygons in the parcel fabric store the parcel PIN/name, associated plan, history tracking information, area, and accuracy information.
 |
Parcel fabric polygons table |
Lines being migrated into the parcel fabric should have a corresponding feature class of polygons. The polygons are defined by the source parcel lines, and the lines reference left and right polygons by their system COGO feature IDs.
Required fields
The following fields are required on your source parcel polygons:
|
Field name |
Field type |
Description |
|---|---|---|
|
Your feature class name with an underscore |
Long integer |
COGO system field required for data migration |
|
PIN (or NAME, LOT, or APN) |
String |
Parcel identification number |
Similarly to the source parcel points, a COGO system field populated with the feature IDs of the polygons is required on your polygon table. The name of the system field is the feature class name followed by an underscore (minus the "polygon"). This system field is referenced by the parcel lines table when populating the LPOLY and RPOLY fields and by the parcel points table when populating the LinePntParcel field.
 |
System field on source polygon table |
Optional fields
The following fields are optional on your source parcel polygons table:
|
Field name |
Field type |
Description |
|---|---|---|
|
Area (or StatedArea) |
Double |
The parcel area as stated on the plan or record of survey |
|
PlanName (or Plan) |
String |
The name of the plan or record of survey |
|
AccuracyCat (or Accuracy) |
Long integer |
The accuracy level of the parcel |
|
Type |
Long integer |
Used for custom subtypes on the polygons (for example, commercial/residential parcel) |
|
Historical |
Long integer |
True (1) if the parcel is historic |
|
LegalStart (or LegalStartDate) |
Date |
The date of the legal transaction that created the parcel (in other words, the date on the record of survey) |
|
LegalEnd (or LegalEndDate) |
Date |
The date of the legal transaction that retired the parcel, that is, the date of the record of survey of the replacing parcel |
If any of the optional fields are missing on your source parcel polygons, corresponding fields on the parcel fabric parcels table will have the following values:
- No Area field: StatedArea = the area of the polygon shape geometry
- No PlanName field: Plan = the name of the feature class being migrated (For example, if there was no PlanName field on the AlachuaCounty_polygon table, the plan name for all parcels would be AlachuaCounty.)
- No AccuracyCat field: Accuracy of all parcels = 3 (default)
- No Type field: Type = NULL
- No LegalStart field: LegalStartDate = NULL
- No LegalEnd field: LegalEndDate = NULL
- No Historical field: Historical = NULL, which is also false
Control points
Control point data is stored in the Control table in the parcel fabric. In addition to x,y,z coordinates, the Control table also stores quality information about the control points and whether a control point is active in the fabric least-squares adjustment.
 |
Parcel fabric control table |
The data migration process supports the following source formats of control points:
- Feature class
- Tables, .csv files
If you are migrating control points in a feature class, you do not necessarily need to have x,y,z fields with coordinates. Coordinates can be derived from the shape geometry of the point feature class. However, the derived coordinates may not be accurate and correct to the published coordinates of the control points. If you are migrating control points in a .csv file or stand-alone table, x,y,z fields with coordinates are required.
Optional fields
The following fields are optional on your source control points format:
|
Field name |
Field type |
Description |
|---|---|---|
|
Name |
String |
The name of the control point |
|
PointID |
Long integer |
The point ID of the associated fabric point |
|
AccuracyXY |
Double |
Horizontal positional accuracy of the control point; metadata only |
|
AccuracyZ |
Double |
Vertical accuracy of the control point; metadata only |
|
Survey Date |
Date |
The date the control point was established |
|
Active |
Long integer |
Indicates whether the control point is active in an adjustment |
|
Type |
Long integer |
Used for custom subtyping on the control points, for example, benchmark |
Control points being migrated into the parcel fabric need to be associated with a corresponding point in the parcel fabric to be used in a fabric least-squares adjustment. In this way, control points become part of the parcel fabric network. A control point does not have to be associated with a fabric point. It will then be treated as inactive and cannot participate in a fabric least-squares adjustment.
You can explicitly specify the point ID of the control point's associated fabric point in the PointID field. Alternatively, when migrating control points, you can specify a search tolerance around the control points, where fabric points lying within the tolerance are automatically associated to control points. If no fabric point is found in the search tolerance, you can use the Control Point Match tool to manually link control points to fabric points after data migration.
In the screen shot below, fabric control point CP_4024 is associated to fabric point 4024 (point ID) even though the fabric point location is not congruent with the control point location.
If any of the optional fields are missing on your source control data, corresponding fields on the parcel fabric control table will have the following values:
- No Name field: Name = a default, auto-generated name, starting at 1 and prefixed with Auto1, for example, Auto1.1
- No PointID field: PointID = the point ID found within the control point match tolerance
- No AccuracyXY field: AccuracyXY = NULL
- No AccuracyZ field: AccuracyZ = NULL
- No Active field: Active = NULL until the control point participates in a least-squares adjustment
- No Type field: Type = NULL
Migrating control points before parcel data
You can migrate your control points into the parcel fabric before you migrate your parcel data. You will then set a match fabric point to control tolerance instead of a match control to fabric point tolerance.