I manage and maintain a huge set of Civil 3D Style resources for more versions and flavors of Civil 3D than I want to remember. Most people see these manifested in the Framework for Civil 3D public products delivered from this site. Like everyone else who does this sort of thing for a living, I had to learn the hard way to systematically manage a large set of Style collections.
Folks asked me to summarize or boil down that body of knowledge. This is no easy task nor does the result tend produce short pithy posts. Civil 3D is a complicated and demanding diva.
To achieve consistent performances from the Civil 3D diva that deliver real civil engineering and survey project work requires the management of a lot of complexity. It is easy to become overwhelmed unless we divide and conquer the many facets involved.
Honestly, a good bit of this is a waste of time unless you cannot find someone else to do most of the work for you. From my perspective that is the most sensical reason why there is a Framework for Civil 3D in the first place.
The recent Elements of Style in Civil 3D post detailed the mandatory AutoCAD and Civil 3D Style essentials we face in brief. You should take time to at least speed read the post. You also need to review the critical path goals expressed there.
We want to pursue that elusive and somewhat mythical beast – the Civil 3D template.
There are at least two general, daily-use forms of the Civil 3D production template. These are the collections of Styles and Label Styles used in:
- Working Templates employed in the day to day production process and project drawings
In the production project world, we usually want and require more than one form of Working Template and a variety of Style choice.
- Publication Templates and project publication drawings
In the best-case scenario, this second Publish collection is typically a subset of the larger Working collection and includes a limited set of Styles matched to the deliverables requirements.
We need to answer the why and the how the template forms come into being and are then maintained. Template creation produces much more affirming feedback and is more fun. The maintenance is where the rubber hits the road and the real work and the fruits of our skilled labor and management abilities are truly made manifest.
Style Collection Types and Libraries
Any Civil 3D template (or any project drawing for that matter) is a Style Collection. If we want to successfully manage and maintain consistent, operational Style collections, we must create a separate collection of the known good.
Any Style collection that is in use is subject to change by any Civil 3D user with access to the drawing without notice to any other user.
I like to point out that this user dependent aspect of Style in Civil 3D is nothing new to AutoCAD users. This is why we talk and obsess about CAD Standards. A user can change any property of a Layer (even a layer name) without notice to any other user. The potential number of Styles and variants in Civil 3D acerbates the CAD Standards management problem and argues for the systematic management of the same.
Many people initially consider that their Civil 3D template is their separate known good Style collection. This has some simplified benefits:
- A limited number of resource Style collections
- The resources match the templates in use which may reduce confusion as to the location of the known good
- A limited number of known good resources somewhat matches development to the end-product
- Maintenance of Styles linked to Civil 3D Expressions and/or Property Set definitions are somewhat simplified.
Civil 3D Templates employed as the known good resource has significant practical maintenance and upgrade problems. Template known good collections:
- Tend to grow in size, number, and complexity over time
- Contain Settings which can and do complicate Style maintenance and update processes.
- Are generally limited to those commonly in use Styles.
Therefore, the development and maintenance of specialized Styles collections is more problematic or at least tend to be avoided.
- Ignores and/or complicates the creation and maintenance of separate Publish templates.
The idea that you might have or want a separate Publish template may seem absurd.
- Creation of new separate specialty collections and resources are more problematic.
The creation of these means there are now multiple forms of the known good.
- Require separate container Styles to manage shared Civil 3D Expressions and Property Set definitions employed in the collection.
Styles that employ these resources may break if the Expression and/or Property Set definition does not exist prior to a Style import.
This is admittedly a nuanced but annoying issue.
Template Development is Additive
In practice, Civil 3D Templates are generally best created and maintained by Additive methods and processes. In other words, collections of tested Styles are assembled together after development and after mandatory testing with live Civil 3D data behind.
- The process of creating new Styles and collections is typically best performed in non-template drawings
- The process of editing and updating Styles and collections is typically best performed in non-template drawings
Your own personal experience with Style development and the intimate relationship of Style to the Civil 3D data behind should bear witness to the above.
All Templates Must be Updated
Civil 3D release and update maintenance may require the replacement and/or recreation of the template themselves due to both functional software changes and Civil 3D object model changes.
In most cases, the changes and updates required in any Civil 3D release or update are partial. Those changes pertain to very specific portions of the entire template Style collection.
The Civil 3D Style development process, therefore, tends to demand the creation and maintenance of separate Style library collections to maintain a consistent and separate state of the known good.
The level of detail or separation of resources in any Style collection tends to increase with both size and time. We need make a concerted and systematic effort to manage this practically. In effect, we can lose the known good result we need for production results by over complicating these organizational matters.
Collecting the Styles and Label Styles based on the Type of Civil 3D Feature (the order of Civil Features in the Toolspace interface) is typically the easiest or common method to organize the practical solution. The Framework employs this Style collection method to create and maintain a Style library for all Civil 3D Features.
Most of the Style Choice diversity and maintenance problem is functionally confined to a few Civil 3D Features. It is important to try and identify these.
At the practical level 80%+ of the list of all Civil 3D Features require only a few Style, Label Style, and Set choices. We should identify these Civil 3D Features.
Collections of Styles and Label Styles necessary to complete specific tasks also works in those specialized circumstances. These collections include Styles and Label Styles for multiple Civil 3D Features that, in effect, function together to optimize the task work.
The Framework also employs Specialty Libraries for specific types of project tasks. For example: Levee and Floodwall design; Pond and Basin design; Beach Erosion mitigation; etc. These include all the AutoCAD Style and Civil 3D Style resources needed to perform and/or publish that work. We refer to these task-based library collections as Adaptive Template Building Blocks.
In concept we add Adaptive Template Building Blocks to specialize a template and/or project drawings.
For practical purposes we must also recognize there is also a Core collection set of Civil 3D Styles, Label Styles, and Sets that are required in Working Templates, project drawings, and Publishing versions of the same.
- Where we choose to draw the line between this Core set of Styles and the entire contents of a Working or Publishing Template is somewhat arbitrary.
- Core Styles Membership is primarily based on the collection of Styles that is always available and those unlikely to change in most circumstances.
- We should consider that the 80% of Civil 3D Feature collections that do not require lots of style choice probably can be included in a Core collection.
- Most of the Generals Style collection should be included in a Core collection.
A Core Styles Library collection becomes more important when we choose to employ a Template Style Collection Target based on the newer Reference Template Tool methodology.
Next time we address in more detail the method and practice of implementation of library collections in the two currently available…
Civil 3D Template Style Collection Targets:
Classic Template Method
Project and publication drawings inherit a Style and Settings collection from a Civil 3D template (.dwt) file on creation. This is what most folks do today.
The Classic Template Method relies significantly upon the individual Civil 3D user being accountable to consistently follow a consistent update/upgrade process based on the overwrite of named Styles from a known good drawing resource.
Reference Template Method
The Reference Template Method allows us to update the included named references (both for raw AutoCAD Style and Civil 3D Styles) in this form of template and thereby update all the Style references in all project drawings. In other words, the overwrite of named Styles from a known good drawing resource(s) is externalized, managed, and more automated.
Project and publication drawings inherit the external reference relationships to the attached resources.
Release the Power Beyond the Code
Get the Framework for Civil 3D Release 8
The Civil 3D Style Maintenance Handbook Post Series
Updates, additions, and fixes to the posts in this series are on-going.