Should boundry lines be loaded to a fabric or just polygons

661
4
Jump to solution
01-19-2022 01:43 PM
DrewDowling
Occasional Contributor III

I'm trying to design our migration t th parcel fabric. The current model has a boundry line feature class. This contains boundary lines for all parcel types, subdivisions, lots and parcels. About 10% of the features have COGO attributes. We would obviously love to keep these attributes.

Would it be better for us to load all lines as well as polygons into the parcel fabric or only the boundary lines with valid COGO? Or, if we just load polygons, is there a method to transfer over the COGO attributes after lines have been created by a build?

 

Tags (1)
1 Solution

Accepted Solutions
ChristineLeslie
Esri Contributor

Hi Drew

You can append both polygons and lines to the parcel fabric. I would only append lines with COGO that you want to keep and then use Build Parcels to build the rest of the lines.

To transfer COGO, you can use this script

https://community.esri.com/t5/arcgis-parcel-fabric-blog/migrate-arcmap-cogo-to-pro/ba-p/885059

 

Hope this helps

Christine

 

View solution in original post

4 Replies
ChristineLeslie
Esri Contributor

Hi Drew

You can append both polygons and lines to the parcel fabric. I would only append lines with COGO that you want to keep and then use Build Parcels to build the rest of the lines.

To transfer COGO, you can use this script

https://community.esri.com/t5/arcgis-parcel-fabric-blog/migrate-arcmap-cogo-to-pro/ba-p/885059

 

Hope this helps

Christine

 

JasonBessert
New Contributor III

This is a very good question Drew.  If you are interested in retaining your COGO attributes along with your parcel polygons in the migration, I would recommending loading your polygons to the fabric (with the append tool) and loading your lines (only the ones with COGO) to the fabric with a definition query.  The "Build Parcel Fabric" tool will generate the remainder of the lines needed from the polygon geometry as a 'fill-in-the-gaps' operation to solidify your fabric as well as create the points.

I haven't seen your data, and I'm only recommending this based on an assumption that your data isn't 100% clean and there could be gaps and slivers between the polygons and lines.  This can add to the cleanup on the fabric side, which is OK, because there are great quality tools built in Pro.  We always like to perform some cleanup proactively, ourselves.  If your pre-fabric data has a strong topology (having a polygon boundary must be covered by line rule) and is void of errors, then load all the polygons and all of the lines.

BE AWARE that before loading the lines, you must migrate the lines into Pro before loading them into the parcel fabric.  There is a Migrate ArcMap COGO tool ESRI has shared (see link below) that upgrades an ArcMap COGO feature class (that is typically text fields) to the double field type that is utilized in Pro

 

https://community.esri.com/t5/arcgis-parcel-fabric-blog/migrate-arcmap-cogo-to-pro/ba-p/885059

 

Kindly,

PhilPage
New Contributor II

We have a similar situation with our current model using a polygon feature class to store parcel information and a separate lines feature class that contains attribution relating to the method used to create the line and its accuracy.  The lines and polygons have a clean topological relationship.  It does not store actual COGO attributes but the estimated positional uncertainty information is used by our clients.  Would you recommend migrating all of the lines in a situation like this or is there a better way to transfer line accuracy information?

0 Kudos
ChristineLeslie
Esri Contributor

Hi Phil

If you already have topological correctness between your polygons and lines then I would think it would be easier to append your lines. That way you can append and transfer all your attribute information as well (just make sure you create matching fields, domains etc in the parcel lines feature class).

If you build new lines, you will then need to transfer attributes accross to all the fields.