Holes Segments and Nodes in Civil 3D

At times I joke a bit about the Feature Lines Only design crowd in Civil 3D. I do this to contrast classic and manual Feature Line construction and manipulation methods with the advantages of managed Corridor Design methodologies that can produce multiple and controlled Feature Lines on demand. This is not a binary choice. Obviously, civil engineering folks need both.

Our Choices are not Do Be or Not to Be

The most important reason to employ managed Corridor Design is not in the reduction in the number of tasks or an increase in the speed of work but in the capability to produce better managed optionality and more design choices to choose from.
See the Civil 3D New Directions post series that ends with The Arts of the Separation of Powers in Civil 3D post.

The key point there is that managed optionality is a managed Civil 3D project capability sustained by Civil 3D corporate and Civil 3D user skills. Therefore, managed optionality can become a significant competitive advantage and value add in the marketplace for those that do the development work.

Why couldn’t Groundforce (a current Autodesk Civil Futures project) feast upon and optimize my Corridor’s Alignment and Profile Baseline pairs and related Offset children?
See the recent Civil 3D Future Design and Optimization Styles post for more about Groundforce and the genuine need for those proposed Optimization Styles in Civil 3D.

The Real Problem is Elemental

Maybe you did or did not notice how often the issues of the significant difference between an entire linear primitive and the collection of specific kinds linear segments arose in the earlier discussions.
This isn’t something contrived by adept or specious argument.

Linear objects play a vital role in modern civil engineering method and practice.

As a relevant aside – classic civil engineering point-based design methods are important. The choice of design methods isn’t binary unless the tools and our perceptions confine us. Design by dots and design by connect the dots methods really don’t differ all that much. That depends on how we perceive and talk about the forms of geometry.

Silly me. I believe Survey Dbs of project design point locations are as valuable as resources as Alignment, Profile, or Surface DREFs.

In Wholes or In Parts

We tend to create, edit, and manage by the linear beasties.
We talk and think about them all as Wholes.
This is what we do.

The shorthand of our human symbolic thinking seems to get in our own way.

The substantive issues that we often need to address and complicate matters, are buried within the elemental properties of the Segments and the relationships between those Segments that are collected into those Wholes.

Segment the Problem

Simply - An Alignment is and cannot be a CAD polyline primitive by engineering definition and requirements. Feature Lines, Parcel lines, Figures are not exceptions lest the plethora of Civil 3D Feature names confuse the mathematic and engineering realities.
All of the following are elemental (and I use that term carefully):

• A structure of collected Segments is elemental
• Segment Type properties are elemental
• Segment tangency (or not) relationships are elemental
• Segment geometries (that include PIs and PVIs) are elemental
• Node properties are elemental
• Etc etc etc

This is a large and ordered list. Yes. Whether we like it or not, we are talking about Tuples and specifically Tuples of Tuples. See the Civil 3D Codes, Not Tools, and Tuples post are linked posts for a practical discussion about why Tuple Think matters to us all in Civil 3D.

Where Are We Going?

From a pragmatic working perspective, both Civil 3D Whole direction and Segment direction are elemental. It significantly helps us to temporarily modify directionality for the sake of basic geometric construction convenience.

A second point being: the capacity to recognize and maintain a Temporal State of a Property is perhaps central to the practical execution of both better Design Optimization and managed Design Optionality.

What the Node?

We tend to want to conveniently compress Segments into Wholes.
Do we want the detail and complexity of elemental Nodes to vanish?

Strangely, it seems to me, that most of our difficulties in design and command mechanics inside Civil 3D revolve around exactly that relevant temporary lust.
We want to hanky wave the elemental Nodes until we don’t or until we can no longer ignore the problem.

Self-Fulling Prophecies and the Usual Unexpected Consequences

Today, we cannot easily turn Feature Lines into Alignment and Profile pairs inside Civil 3D.
There are workarounds – See the Create Alignment and Profile from a Feature Line video.
We cannot yet edit any of these potentially interchangeable Civil 3D Features without using the Civil 3D Feature specific commands.

Hoorah. There is less of this than there was in the Civil 3D past or at least the interfaces are more similar.

If we agree on some not-so-simple Node and Segment-based property mapping rules (These sound like Optimization Styles?), there is no reason why we couldn’t employ any of the different Civil 3D command workflows to work on any linear Features in Civil 3D as need and ease of use demand.

Wholes Lust Becomes the Sucking Hole

Our historic and primitive perspective has consequences. Civil 3D must insist on these specialized behaviors because of our habitual work obsession with CAD primitives and particularly CAD polylines in their various forms. These traditional geometric primitives never could do the job in the first place. They are CAD primitives. These are like grading with only picks and shovels and without backhoes.

You won’t have any problem finding current videos by Civil 3D skilled folks that consider Feature Lines to be nothing more that AutoCAD 3D polylines (or LDT breaklines) in a Civil 3D disguise.

Collections of CAD primitives are not truly elemental by the formal mathematic and geometric definitions. Those applied math concepts and the other forms of geometry do matter.

A pile of lines is not a Surface or a Site Parcel. There are no relationships or rules possible between the primitives. For not so obvious reasons, that elemental difference turns out to be mission critical to the engineering construction solutions work at hand.

These failures of collected primitive properties creates serious civil engineering design problems that Civil 3D seeks and mostly manages to overcome with the specific Civil 3D Feature definitions.

As this point everyone’s brain hurts. Sometimes that means something is about to break or not.

Let’s end some confusion - Which E form of geometry are we talking about? Say What?

Euler’s Day Off

The CAD is about basic Euclidian geometry - great useful and essential stuff.

As Euler famously proved in his solution to the Seven Bridges puzzle our real world, civil engineering and survey project problems are not only all about that primitive-based geometry.

Our now familiar Civil 3D Wholes cannot be CAD primitive polylines. They must have Segments. Segments are not merely collections of CAD primitives (lines and/or types of curves) because Segments do require types and Segments always have Nodes with a potential large tuple lists of properties.

Nodes cannot be simply CAD primitive points.
Nodes may not have an exact location but may be resolved to one.
The temporary crossing nodes on familiar Feature Lines make that point if the resolution of observation locations in a Survey Db does not.

In Civil 3D, the Nodes in our many Segments; 2D and 3D Linear networks; 2D 3D and 4D Networks are more than ACAD points.

Nodes and their Segments should be elemental Features in Civil 3D.
These Features aren’t in there to date.
The CAD primitive workarounds tend to simply complicate and confuse matters.

Time to bridge the gap?

The Geometry of Position

It seems appropriate to employ Leibniz’s turn of phrase -The Geometry of Position as the case in point. Sorry. I am about to use the term topology here. Yikes.

I could walk through the same Node and Segment scenarios for Surfaces, Parcels, Pipes, Points, and every other Civil 3D Feature, but I won’t belabor the point. Let’s just say…

• A Surface is a topology
• A Site Parcel is a topology
• An Alignment and children are a topology
• An Assembly is a resolved management topology of collected Subassembly topologies
• A Corridor is a resolved management topology of other defined topologies

Will Feature Lines grow up to be a topology someday? I hope so. Eheh.
Ok. I am pulling your leg a bit…
A managed topology of related Features Lines (and/or Alignment and Profile Baseline pairs) turns out to be a pretty useful Civil 3D design tool that already exists in Civil 3D.

Many in Civil 3D Land already consider there is almost an equality between a Feature Line collection and a Surface topology.
By definition, a formal Surface topology requires points and edges (defined as paired points). – the Nodes and Segments not the Wholes.
We humans want and need to the name the Wholes to manage the data complexity and the significant order of entrance issues in the build processing of a proximity-based network topology.
The resolved Surface topology doesn’t care.
In the ordered and structured processes to get to a practical result it does to us.

To be explicit. I employ the topology term here in formal mathematic and geometric terms and not by the sales and marketing spin definition terms of any of our favorite software vendors.
God forbid, that we continue to take the topology word in vain.

The Walking Path Forward?

More productive Civil 3D futures depend on the necessary support and capabilities for those Node and Segment Features (elementals), Optimization Styles, and Settings to help us manage and optimize them. All of these are required to support the other needed forms of design geometry.

As Civil 3D users we do need to try and stop confusing the forms of geometry we talk about.
Euclid, Euler, and others each have their place in our civil engineering and survey disciplines.

When is a point a point? Is the location we talk about a Node or Nodes?

Coming real soon now…
Why the Node Feature elemental is essential to the future of a better annotative and Style management in Civil 3D.

Manage the Future of Your Civil 3D
Get the Framework for Civil 3D Release 8

 

The Civil 3D Futures Posts