Easily differentiate points appropriate for a surface model from those that are not.

A typical topographical surveys consist of hundreds or even thousands of points, most of which must be added to the definition of a surface model.  Some of these survey points are not appropriate for use in defining surface models.  Such as those points not taken on the ground.

Many Civil 3D users use a special point group to exclude those points that are not appropriate for surface models.  The group is defined by including the survey points, but excluding those points whose raw descriptions match those in the list.

This works well, but it will fail when the surveyor shoots a point with a non-standard code, that point does not belong in a surface model, and this is not communicated with the design staff.

Consider this technique instead:  Define description keys for all points and define the Format column as usual with one exception: add a special character, such as a plus, to the end of those points which are appropriate for modeling surfaces.  Points that are not shot on the ground are devoid of this plus at the end.

Then define the point group with only one custom setting, Include points whose Full Description ends with that special character, in this case a plus.

When a surveyor in the field encounters a feature which requires a new code, and that point is appropriate for a surface, they can simply append that special character to their raw description.  If no communication between them and the office staff takes place, that point will automatically be included in the point group and therefore in the surface model.

In the rare case where a point normally appropriate for a surface model is not appropriate for a single shot, the surveyor can append another special character to exclude that point from the surface.  MHD-  Then the surface point group can exclude points whose raw description ends in that character.

Manhole where the lid is above ground…

We use the Manage Tab in Civil 3D for some important stuff like data shortcuts, managing styles, and Dynamo. But how often do we look at the panels between those tools?

So today let’s talk about Property Set Data.

Property Sets are a great tool to attach additional information to any AutoCAD or Civil 3D objects in your projects. They are pretty easy to use and incredibly versatile.

Property Set Data can be set up in a drawing (DWG) or in a template file (DWT) so that it can be brought into each new project. The opportunity to have these in a template is often overlooked, but can offer a nice solution for adding data to objects and aiding in the transfer of information throughout a project’s life cycle.

When you select Define Property Sets in the Manage Tab, it will bring up a filtered style manager window where you can create Property Sets, determine what objects they can be applied to, and add definitions.

While pipes have a lot of meta data behind the scenes, utilities are often drawing using Feature lines or Polylines. Layers absolutely give us some information as to what these lines represent, but property sets can take this transfer of information to a new level. In this case we can ensure consistency across revisions and eliminate dangerous assumptions about existing utilities.

There are several ways to add definitions to your property set, but all of the definitions above are manual property definitions. The type of definition will restrict the value input options for the user. There are many types of inputs from plain text to True/False options to integers or even predefined lists that we can use to get useful and quantifiable data added to any object.

In your drawing you can select multiple objects and add a Property Set to them all at the same time in the Extended Data Tab of the AutoCAD Properties window. Likewise, we can remove a Property Set from multiple objects at the same time. Then depending on the data type, you can pick from a dropdown list or enter a year of installation to add important information needed for the project design.

From the additional information I added, not only can we see what these polylines represent, we also have a better idea of how accurate this information is. Knowing that this utility information was confirmed through daylighting gives me much more confidence that it is 75mm conduit, or that it is even drawn in the correct location.

This custom meta data stays with these objects and can be leveraged in other applications like NavisWorks or Infraworks.

Or we can manually code our own label styles to sit in the template with our property set

<[PS:Property Set:Definition Name]>  Keep in mind this is case sensitive.

Or we can create a Schedule in the template to show this information in table form. Creating schedules is a little tricky and somewhat hidden in Civil 3D, but using the command < SCHEDULE [Style] > we can create a schedule style. Then < -SCHEDULEADD > we can create a schedule of this data.

This information can also be linked to Microsoft Excel and Microsoft Access for more flexibility.

Hopefully this example has shown you some of the flexibility of Property Set Data. But this is only the tip of the iceberg when we look at the possibilities that come with creating these customized properties for objects in our designs. So get creative with these tools and use them to streamline communication, minimize errors and assumptions, and create more informative designs.

Here are a couple useful commands to speed things up when working with Property Sets:

• AECPSDAUTOATTACH – Automatically attaches all property set data to all the objects they apply to in the drawing. Also allows automatic updates if property sets are edited.
• PROPERTYSETCLEAN – Use when AECPSDAUTOATTACH is OFF. Updates property set information associated to objects after edits have been made to property set data.