Workflow for importing/generating COGO values from CAD to GIS

[AaronCole1]

We're currently working on building a parcel fabric layer from high quality CAD data.  Our workflow seems to be as automated as possible (i.e. everything but topology and COGO attribution) but we're running into a sneaky problem.  If we calculate topology before calculating COGO, some of the distance and bearing values are altered, even if a vertex is only moved a few thousanths of an inch in some cases.  Before the cracking and clustering, the COGO values are in almost every case identical to the surveyed values so we're trying to preserve them through to the fabric.

My current idea is to calculate COGO values first, create a unique ID and placeholder fields to store the initial values, then validate the topology, split lines at intersections, and finally using some simple logic, backwards calculate the COGO for the lines that have been altered by the topology back to their original values, while leaving other changed values as they are once recalculated.

Since we're already going through the process of rebuilding the parcel layer we figure we might as well try to have accurate COGO values while we're at it.

Does anyone have any ideas, experience, or comments?  Has anyone else done this or something similar?

[ChrisBuscaglia]

We're currently working on building a parcel fabric layer from high quality CAD data.  Our workflow seems to be as automated as possible (i.e. everything but topology and COGO attribution) but we're running into a sneaky problem.  If we calculate topology before calculating COGO, some of the distance and bearing values are altered, even if a vertex is only moved a few thousanths of an inch in some cases.  Before the cracking and clustering, the COGO values are in almost every case identical to the surveyed values so we're trying to preserve them through to the fabric.

My current idea is to calculate COGO values first, create a unique ID and placeholder fields to store the initial values, then validate the topology, split lines at intersections, and finally using some simple logic, backwards calculate the COGO for the lines that have been altered by the topology back to their original values, while leaving other changed values as they are once recalculated.

Since we're already going through the process of rebuilding the parcel layer we figure we might as well try to have accurate COGO values while we're at it.

Does anyone have any ideas, experience, or comments?  Has anyone else done this or something similar?

Hello Aaron, I have experience with CAD data.

You are defininietly on the right path with calculating the COGO before you run it through the topology, but there are some things that you need to take into account.

Is the CAD data projected, scaled, rotated or rubbersheeted?  If so, the COGO value inversed will most likely NOT match the original recorded measurement.  If this is the case, you'll have to reverse any scale/rotation/rubbersheeting before you inverse the data, this is not an easy task.  You're better off focusing on loading the annotation from the CAD and then taking the day-forward approach of maintaining feature-linked annotation for all new parcels added to the parcel fabric.  The feature-linked annotation class included with the Local Governement Information model is a great start.  There is even a way to load your CAD annotation and then make it feature-linked by adding a relationship class (retroactively).  Let me know if you need help setting this up.

If the data is not projected, scaled, rotated or rubbersheeted, then inversing before running topology is the way to go.  One thing that you mention is interesting though, why would you have to split lines at intersections if the CAD data is high-quality?  That would introduce additional lines that may or may not exist on the original records, this may be difficult and time-consuming to figure out.

Let me know if this is helpful and we can keep the conversation going.

Chris

[AaronCole1]

Hello Aaron, I have experience with CAD data.

You are defininietly on the right path with calculating the COGO before you run it through the topology, but there are some things that you need to take into account.

Is the CAD data projected, scaled, rotated or rubbersheeted?  If so, the COGO value inversed will most likely NOT match the original recorded measurement.  If this is the case, you'll have to reverse any scale/rotation/rubbersheeting before you inverse the data, this is not an easy task.  You're better off focusing on loading the annotation from the CAD and then taking the day-forward approach of maintaining feature-linked annotation for all new parcels added to the parcel fabric.  The feature-linked annotation class included with the Local Governement Information model is a great start.  There is even a way to load your CAD annotation and then make it feature-linked by adding a relationship class (retroactively).  Let me know if you need help setting this up.

If the data is not projected, scaled, rotated or rubbersheeted, then inversing before running topology is the way to go.  One thing that you mention is interesting though, why would you have to split lines at intersections if the CAD data is high-quality?  That would introduce additional lines that may or may not exist on the original records, this may be difficult and time-consuming to figure out.

Let me know if this is helpful and we can keep the conversation going.

Chris

Hi Chris,

Thanks for responding, and good question about splitting lines.  In cases where straight lines had the same bearing, the mapping technician extended the line without breaking it at intersecting parcel lines.  From my previous experience working with CAD data I still consider what we have to be high quality, but your point is well received.  By creating a unique ID for each feature before planarizing I'm able to see which features have been split by checking for multiple values in that field.  Then, by comparing the recalculated COGO values with the originals, I can pick out which values have changed, and if it was a straight line that was split I give it the original value, if it's a curved line that was I leave it with the new value. 

The data is not projected, scaled, or rotated so our COGO values are coming out as we'd hoped they would, but only before the topology is validated.

We like the idea of bringing in the COGO annotation, and we're in contact with the mapping tech now about the COGO annotation and whether or not we can get it.  For some reason it's not showing up the the dwg files.

Either way, I'd love to continue this conversation, especially as we find out whether we can import the COGO annotation and as we refine our workflow.

Ultimately, I'd like to create a toolbar with some python add-ins, as well as some topology and COGO tools to make the manual part of the process as seamless as possible. 

Thanks,
Aaron