The Jump Platform - A Big Picture View
"Template customization in AutoCAD Civil 3D requires
a structured approach - a continuous development process."
What does that Mean?
This short video segment takes a top down viewpoint to the Big Picture of the Jump.
It's brief discussion about the Architecture of the Jump Platform.
The way Civil 3D works literally requires us to employ a Method
to Create and Manage templates for our projects or we just
work harder and do less.
This is a basic view of the architecture behind the Jump Platform.
There are three horizontal Sections in the diagram from top to bottom:
Working Projects - the production environment of Civil 3D powered by the Jump Platform
Project Setup - Template construction (customization) for the project and/or jurisdiction
Template Setup - Core Template construction
For illustrative purposes there are three jurisdictional or "Standard Systems" shown above.
These are the "duplicate" vertical parts in the diagram.
If you can think of a Symbol System and the associated annotative Labels and Views as a Plan Set Language. That should hopefully make some sense.
The 3 Plan Set Systems or Langauges shown above might be:
1) The raw Jump Platform used to integrate outside consultant work into your project
2) An internal production version of the platform - used by your staff to produce the work
3) A jurisdiction's Standard requirements - used to publish the project work to the client's requirements
This ability of the Jump Platform simplify and translate Civil 3D work between jurisdictional and/or project specific "Standards" is centric to the platform's design goals.
This design goal and approach also serves to make project upgrades significantly easier from release to release provided the Styles are constructed and built "properly" and according the Civil 3D hierarchy rules.
The real world keys to making this approach work are:
1) Templates that employ common Naming Conventions for the Symbol Sets and the
Civil 3D Styles and Sets
The SAME block NAMES are employed
The SAME Style NAMES are employed as much as possible
2) Store Key Project Features in NoStyles template drawings and reference them appropriately
A NoStyles template ONLY includes default "Standard" Styles and Sets
3) Managing the "State" of the drawing "containers" that hold the Key Features. You can also think of this
as Managing the Dynamic Model. You build Features that go through QA and then change into more
"permanent" parts of the Model. Hence the Jump's Civil 3D Project Template has REFERENCE folders.
4) Push the publication Details uphill as much as is possible within the limits of the software and the Standards
details you have to cope with.
That is most easily and practically done with Project templates, Sheet Set templates,
and STB plotting methods that also use common NAMES
The need for different templates is obvious as is the need for a method to construct and proactively manage them.
A couple of other important things to note:
Our previous AutoCAD and Land Desktop experience will tend to lead us to believe that LAYER conventions
and specific properties are much further down in the stack than this approach shows. Previously, we had no
choice but to rely on Layers to BOTH manage the objects and produce what we needed to see and publish.
In C3D
Styles do handle what things look like - even what named Layers the Feature components appear on.
Features are more important to the Dynamic Model than the drawings that contain them
BOTH of these factors depend more on named reference
We must be more careful and disciplined about the NAMES themselves
You might think that Template Section and Project Section slices are the same thing.
On a day to day basis that might be true.
However, if you don't separate things propertly from bottom to top based on how Civil 3D
produces the representations of the Features and Labels, you will run into lots of confusion.
Sorry if you want and think you need only ONE Civil 3D template.