One great advantage of Style-based software is the simultaneous increased consistency and flexibility that Style brings to the table. These days given the will and the skill you can make a Civil 3D Style, Civil 3D Label Style, or Civil 3D Label Set do almost anything a user could think of with the Civil 3D data behind.
The downside to this abstraction of a complex set of properties to named Styles is the Systems Management challenge presented by that same diverse set of Styles. We could call the problem…
The Three Bears
- How do we easily tell users what the Style does?
- How do we identify or clarify the differences between Styles?
- How to we show our visual users what the Style looks like?
Sadly, there are not too much, too little, or just right answers in spite of the modern total reconstruction of the original Goldilocks and the Three Bears fairy tale. To explain, let me paraphrase from the somewhat famous Learn Something New About Civil 3D Today post:
“The tale of Goldilocks and the Three Bears was once a fearful bedtime morality tale from a day when bears regularly could and did come to visit houses. When a bear huffs outside your tent, you pay attention.
The story is a morality play with an intentional shifted perspective. The tale once had distinct male and female nuances now lost in the Disney translation. What woman in their right mind would visit the den of three male bears? Whether she be a maiden or a cougar what was she looking for? Recall that in the original telling Goldilocks runs away in the end.”
Put another way…too much, too little, or just right decision making is not the most important point of the real story.
Bear Number One
How do we easily tell users what the Style does?
The Civil 3D Description property and the current Style context makes this reasonably easy to accomplish if we are disciplined in our Style development work and we train our users to pay attention in the Civil 3D Toolspace. The Description properties of most Styles allow us to explain both the reasons and significant Style details.
Sadly, the Descriptions of some Sets and notably Description Key Sets are simply completely inadequate to the real world work to date. Back in the day, no one thought to ask why would anyone want to have multiple Description Key Sets in the first place?
Bear Number Two
How do we identify or clarify the differences between Styles?
I’m a strong believer that Style naming rules save our bacon with the classic Style identification and Style differences problem. Style naming rules also help significantly with the Bear Number One problem too.
- If they are executed well in conjunction, Descriptions and Style Name Rules in a Civil 3D production environment work together.
- If they are not coordinated, you are basically wasting production man-hours.
You effectively sow confusion.
The Civil 3D Style environment is changeable by both definition and purpose.
Therefore, Style Management rules like the Simple Style Rules and the Hierarchy Rules help considerably to preserve the Style naming rules as functional production assets in our real world projects.
At some point we hopefully recognize that Styles become another replaceable State like the properties of AutoCAD Layers held in a separate Layer State. That facility and learned skill allows us more publication flexibility.
We can achieve the goal of publish on demand…
I call this Intelligent Publish on Demand because both user knowledge and applied skills are required.
I should add that the above makes no sense at all if you don’t see the usefulness of the goal and/or do not possess the working and publication Style libraries with the choices required to execute such a plan.
Bear Number Three
How to we show our visual users what the Style looks like?
This has always been the difficult challenge of Civil 3D Style and management. By definition Style result and resolution is driven by the current Civil 3D data behind. Style is both invisible and unavailable without the data to produce a result. Civil 3D also assumes by implication that you have the Civil 3D Style application skills and the Styles themselves to do the work.
A classic case would be a Profile Label Set that works well and practically in a split Profile. You need:
- A Profile with that kind of data and a Profile View with a Profile View Style that splits well.
- The Civil 3D skill to know how to do that.
- A Profile Label Set with the right Label Styles
- The Label skill to set them up in the Profile View
To date the only practical solution is a sample dataset with enough diverse and normalized data to address most of the Style resolutions people require.
A video with some ways and means to get to Style content in that context might also help. Style visualization and testing are learnable and necessary Civil 3D user skills. There are some important ones in here.
Jump Kit Style Resources
Needless to say the Framework for Civil 3D tackles the Three Bears problems at all levels and from multiple fronts. Most customers agree the Framework solves them and that we supply the training fundamentals for the necessary Civil 3D skills and disciplines to make them work.