Civil 3D – Data References

I wrote this some time ago, and figured I’d better get it out here before 2010.

Data Shortcuts are Cool. The list of reasons to use these is growing. One such reason is a small amount of companies have shunned Vault for varying reasons, including the learning curve involved. I have repeatedly been tasked to produce methods that would allow the greatest flexibility in sharing, with the least amount of interruption to workflow. In earlier versions, Land XML had always been my preferred method of transfer, allowing some anonymity of the data origin. When the origin has been updated, the XML is overwritten and the definitions would recreate themselves like a data XREF, only more stable.

In the past I have reserved certain procedures away from Data references, however since 2009 issued, these reservations are almost gone.

Data shortcuts provide references to objects that can be inserted into other drawings. These references are like the best combination of a MAP queried object, LandXML data, and an XREF all in 1. They lie in the drawing, and distribute information, in the form of the original object, as an uneditable shell. Labels can be applied, and objects can be derived from the reference. These limitation are that only surfaces, alignments, profiles, pipe networks, and view frame groups can be referenced. They provide a nice alternative to vault.

The Working Folder

The working folder encapsulates a work environment much like a Land Desktop project did, and will contain the shortcut information. It may include the related drawings and data shortcuts for a project. The Data Shortcuts node on the Prospector Tab shows the shortcuts in the current working folder. When an object is updated in the source drawing, notification appears in the main application window and in Toolspace Prospector.

Civil 3D – XML Pipe Import Parts Catalog problem

Pipe Networks and the beloved XML has once again bit someone in the fanny.  This time it is the ‘Can’t Swap Part’ on imported pipe networks.

Here’s the deal.  Among all the interesting stuff an XML file will bring in for you, it won’t bring in the Parts List name.  It contains the Material and size of the part as well as the name, just not the Parts List.  I suspect this is good, considering you may not have that named List, but this still leaves us with pipes that have to be swapped.

It seems as though the Network adopts the creation aspects of the commands settings.  The network is created, and then handed the parts to complete the pipe network.  When it does, it sets them by the information in the XML.  The size is correct, but the XML has no idea what to tell your application about what these should look like, other than diameter. 

The application responds with it’s defaults.  If you have no default Parts List set, then the parts list comes in NULL. Notice the example below.