Transfer Attributes creates duplicate COGO fields each time

1452
10
10-06-2021 06:53 PM
Labels (2)
WileyBogren
New Contributor III

Hello, happy October again!

Is there a way to use Transfer Attributes between a Pro COGO line feature class (works, auto-labels, etc) and the Parcels_Lines class that also has COGO enabled? So far, every time I run transfer attributes, it creates a duplicate set of the COGO fields Direction_1, Distance_1, etc...and populates those with the result of the attribute transfer, while the original cogo fields (which are the ones actually referred to by the COGO functionality) remain blank. Meanwhile the Fields view in my attribute table pane gets more and more crowded each time I run the tool...

I'm migrating polygons into a version 3 parcel fabric, using arcgis pro 2.6 - with the goal to script this all with arcpy, so a functioning arcpy command is just as good a solution as a recipe for getting the tool to work through the Geoprocessing pane.

Context: Following the workflow from the Append Data page  in the Getting Started with Parcel Fabric guide, I select a group of polygons and append them to my Parcels polygon table. Then create records from a RecordName field, then build parcel fabric to add the points and lines.  Finally transfer attributes to get the cogo values from my (existing & Pro) source cogo dataset into the new lines created by build pf. But even the Transfer Attributes help page says it tries to duplicate fields rather than populating the existing cogo fields 😕

Thanks for any and all help and pointers!

0 Kudos
10 Replies
WileyBogren
New Contributor III

Even more annoying, the duplicate fields are marked 'REQUIRED' and cannot be deleted.

So a workaround using Transfer Attributes to put COGO values in new duplicated fields, then Calculate Fields to put the values in the actual COGO fields does work...but you're left with clutter from the duplicate fields that can't be deleted!

0 Kudos
AmirBar-Maor
Esri Regular Contributor

Hello @WileyBogren 

If you are migrating your legacy data and have both polygon and lines, simply append them both.

Is this is what you are trying to achieve?

The steps would be:

  1. Create a new parcel fabric in the correct spatial reference
  2. Add parcel types, extend schema as needed (fields, domains,...)
  3. Use geoprocessing Append to append legacy polygons
  4. Use geoprocessing Append to append legacy lines
  5. Use geoprocessing Create Parcel Records to create records
  6. Build parcel fabric

If you know all your legacy COGO dimensions were entered from legal records you can also set the COGOType field on your lines to 1 (entered).

Does this accomplish what you are trying to do?

All of the above can be run manually or chained in a geoprocessing model or a script tool (if automation is needed).

Why are you scripting it? isn't the data migration a 'one-time' event?

 

A

0 Kudos
WileyBogren
New Contributor III

Hi @AmirBar-Maor , thanks for your response!

I didn't know I could append both polygons and lines before building parcels - I'll try that next! I'm still curious if there's a way to use Transfer Attributes to actually put the values into the intended COGO fields rather than new ones, or at least to get around the 'REQUIRED' flag on the added fields in order to delete them afterwards.

Scripting serves two purposes. First, I'm running 'test migrations' on fresh datasets every month or two, to see if there are consistent issues, and to give myself practice in running the migration so the real event will go smoothly. Scripting is the best way I know to efficiently repeat a sequence of commands perfectly, even if my note-assisted memory of the steps has faded since the last test run.

Second, I have not yet found a workflow that migrates our entire parcel dataset in one go, without failing at one step or another (for example, Build Parcel Fabric). So I have needed to iterate the migration steps over a series of parcel subset selections, each iteration building a small part of the output fabric onto what has been completed so far.

0 Kudos
TimHodson
Esri Contributor

@WileyBogren- on your question:

I'm still curious if there's a way to use Transfer Attributes to actually put the values into the intended COGO fields rather than new ones, or at least to get around the 'REQUIRED' flag on the added fields in order to delete them afterwards.

As a workaround you could try the following:

Run the GP tool Disable COGO,

Run Transfer Attributes,

Calculate the results from the added fields to the original COGO fields,

Delete the extra fields that were created , and then

Run Enable COGO.

0 Kudos
WileyBogren
New Contributor III

@TimHodson Thank you, I'll try that sequence on Monday!

0 Kudos
AmirBar-Maor
Esri Regular Contributor

@WileyBogren 

Great to see you are making good use of the geoprocessing framework. You are free to choose between a geoprocessing model or a geoprocessing script tool to automate and test your migration process.

If build is failing please submit a technical support case.

Other tips that come to mind:

1. If you have densified curves on your lines and polygons, process them TOGETHER using the Geoprocessing tool Simplify by Straight Line and Circular Arc before you run build.

2. Run Geoprocessing Check Geometry and/or Repair Geometry to make sure the cause for any failure is not a bad geometry.

If I had to transfer attributes from one feature to another I would consider using a spatial join. I am not sure you will get a 'one to one' relationship between source and target.

As for not duplicating fields when using the transfer attributes if the fields are marked as 'required' - that is a good find and I would log it with technical support.

 

0 Kudos
WileyBogren
New Contributor III

@AmirBar-Maor Thank you, i'll try Check/Repair Geometry.

Do you know a similar tool for checking/repairing values in a field?

I got an error this morning trying to append a (Pro-version, otherwise functional) cogo layer from file geodatabase into a parcel fabric parcels_lines layer on sde.

I found a way around, but I wonder what the best way would be to actually find the field(s) and value(s) that summoned the error:

ERROR 000224: Cannot insert features - Underlying DBMS error [[Microsoft][ODBC Driver 17 for SQL Server][SQL Server]The incoming tabular data stream (TDS) remote procedure call (RPC) protocol stream is incorrect. Parameter 7 (""): The supplied value is not a valid instance of data type float. Check the source data for invalid values. An example of an invalid value is data of numeric type with scale greater than precision.] [[...]Parcels_Lines_1]
Failed to execute (Append).

0 Kudos
KeithOlsen
Occasional Contributor

Hi @WileyBogren . I'm having this exact same issue while copying a parcel fabric from file geoDB to SQL (sde) Enterprise geoDB. What was the work around solution you came up with? It seems to be hanging on the parcel_lines (cogo) layer. Thanks!  --Keith

0 Kudos
WileyBogren
New Contributor III

Hi Keith!

The most effective fixes for us have been:
1) clean very small lines out of the dataset, starting with lines with length 0 for the first try and, if necessary, very small threshold (like length < .001ft).

2) append the lines to Parcels_Lines while the parcel fabric is still on a file geodatabase, then copy the complete parcel fabric up to SDE...rather than copying it up to sde before appending the lines.

0 Kudos