Civil BIM Object Definition

This subject seems to have a lot of opinions. That only happens though, if you ignore where the term BIM came from. It came from programs like Revit and ArchiCAD. It did not arise from people just doing 3d models of things, as everyone has been doing that forever to some degree. How long have we had TIN surfaces and never claimed BIM?

So BIM is not simply anything that has to do with buildings, information, and models. The programs mentioned above are distinct from previous design methods in that they build things with “objects” that define what you are allowed to design. They also let you define your own objects. You cannot jump in and start drawing lines and text to define things.

You do not see this in civil engineering yet. We have generic tools to model the ridges of roads, inverts or centerlines of pipes, and slope projections, but they never make a complete model, and most are too generic to know what they are.

Then you have some objects that seem like they could fit the mold of “all objects, no lines or text to define things”, but they generally break some foundational rule of design in order to simplify things for the programmers. Civil 3D pipe newtorks, gravity and pressure, illustrate this as they do not use regular horizontal and vertical alignments as their backbone. Instead, they treat things like hubs and spokes with structures and pipes. That seems to solve certain issues but actually kills the simplicity that was already there with alignments. In the end, no one needs an upside down triangular door if a rectangular one has not been provided first. The objects must match real life design first, then allow tweaks to meet custom needs. Otherwise you get a wonderfully encapsulated useless BIM object.

In the end of all discussions, its easy to spot BIM objects. They:

  • encapsulate enough data to define the real life item being modeled.
  • can be shown in 3D
  • can be shared in a way that exposes their data in ways real life people need.
  • can be edited in ways a real designer would need

Those items can be really really hard to accomplish. You must know the design and production processes of several companies in several areas to distinguish what they have in common, and also what is important and arbitrary. Then you must make objects with good foundations, and enough flexibility to adapt to variations. A programmer must be hooked up with an experienced industry person or several, to have a chance at doing it right. Then the industry people have to try various things and keep refining their ideas on storing, sharing, and editing data.

The current attempts at this have not worked, and I say will never work because there is this idea that if we just improve things a little at a time, we get there. It won’t happen. Round two is needed for civil engineering of roads and pipelines. For starters, programmers need to understand that external databases weigh nothing to a drawing until accessed. You must not make a system that always accesses all data for a model, it is too slow. You may devise a strategy to check if data is out of date, but dynamicness is not the highest goal, nor is security. Stability and speed are higher on the list for people on real projects.

Dynamicness of Design Objects and Real Life

As CAD designers, we all learn that duplication of data is a bad idea, and that leads to systems which hold the data in one place and display and provide it to whatever needs it.

Once such a system is in place, it offers the opportunity to make things that update automatically. The term dynamicness is exactly that – how does the display of some object update when its base data changes?

You might think the answer is “The faster it updates the better”. Here are some things I have learned from actual production that software makers may want to pay attention to:

  • When dealing with things whose previous state you never care much about, immediate update is indeed desired. An example might be contours on a surface or individual values on callouts or cut-fill labels.
  • When dealing with annotation and profiles, you do care about what changed and where. You may want to see how much higher the road moved from change of VC length at a PVI. With annotation, you have to deal with overlapping callouts and viewports. Its not nice to get a mess of callouts from some dynamic update. That especially comes into play on 3 line profiles where agencies require. In those cases, you generally want to be able to see where thengs were, and where they will be after the update. That needs something like a “update now, and I will say if I accept the update or not” command.
  • For items that do have the ability to delay updating, you need something to flag them as out of date.
  • For items that use hidden formulas, like Civil 3D does with expressions, you need something to easily check that they are what you wanted.
  • You need something to flag things as dynamic objects. They may look dynamic, like an exploded callout, but are they? Have they lost their data source? Many questions arise that must have good answers so designers can QA/QC someone elses work.
  • Last buy not least, an object should never, ever, ever, ever react to loss of connection to its data by erasing itself. Did I mention there is no exception to this rule? There are just no happy endings caused by such objects.

That checking issue is critical. Once you automate things like callouts to use styles, you have to have a styles checker. You check the automation, instead of checking the result. Then occasionally look at the result too :)

“Correct” Family Tree of Data for Civil Engineering BIM Objects

ok, the first small post for OSSFC…

This post is about “linear” civil engineering items. Things like roads, pipelines, walls, ditches and so on. It is not about the proper model for a light post or item that sits at a point.

Some of the most powerful things are also the simplest. This happens to be the case for civil design, and not because we never had computers before. I have a feeling a whole lot of people think we are so archaic using paper and pens sometimes, but that actually has nothing to do with how we model “linear” items.

How do we model linear items? With a separate set of horizontal and vertical data – the horizontal and vertical “alignments” as we commonly call them. Every road designer is familiar with this, computer literate or not. The system of plan and profile is trivial to all civil designers, you cannot avoid it.

The interesting thing is that separating the plan and profile allows a designer to specify the minimum of “hinge” points along the design. Hinge points are horizontal PI’s, and vertical PVI’s.  I am not saying this was originally on purpose, as it is more likely they only way people knew to facilitate design. The end result though, is a simple system for describing a very complex 3d thing. I say complex because combining a circular horizontal arc with parabolic vertical curve is complex. I recall hearing the old MX Road program used a 12 dimensional equation to do so. Computers or not, we will always model linear civil engineering stuff this way, as it exactly encapsulates our design. We may come up with a system of recording constraints that caused the design to be what it is, but we will never replace the actual design alignments themselves as the result would cause bad things.

The point of this post is to mention a critical thing about the plan and profile system. You may place your PI’s and PVI’s anywhere. They are not tied to each other by default. You may build that system into an object that does enforce constraints, but you must allow the user to turn those constraints off at any time.

In other words, do not make me put PVIs (grade breaks) at particular spots such as plan segment start/ends, and do not make me break up my plan segments if I have a PVI in the middle of a line or something.

Now you see that I am not asking anyone to make “my” kind of civil engineering BIM object, but that I am saying to take away your constraint assumptions and always allow a designer to add or remove grade breaks at will. This is real life, as all projects involve existing infrastructure you must model, that will not follow the constraints of your proposed project.

Here is an example of a sewer design that follows what I call “correct” behaviour.

Make a sewer such that it is one straight line in plan, and has several manholes along its length, yet only has two PVIs in profile. One PVI is at the start, one at the end. This is a super simple design, yet illustrates what I mean by no forced PIs or PVIs.

For that design, which is common for steep sewers that naturally drop more than 1/10th ft accross the manhole, two things must happen during editing:

  1. If I move an endpoint of the plan view alignment, the entire reach is treated as one line, and the end result is a straight line from start to end.
  2. If I modify the elevation of a PVIs, the entire profile should tilt and all manhole bases in between follow the new slope. The entire reach will always be one slope.

I know people will say “but we want a sewer model that enforces 1/10th ft drop at manholes, and minimum 6 ft cover”. That is fine. If a project or agency or alien from Mars can come up with rules they want enforced, there should be the ability to enforce those. All of us realize that is a moving target, and some rules will be more common than others. in the end though, I must be able to say “no rules for this one, its just plain horizontal and vertical design, like a road.”

If you take this approach, the base of your civil object will have two properties:

  1. Horizontal PIs (or list of segements/arcs)
  2. Vertical PVIs (list of station/elevation/VC length)

Things like pipe diameters would be implemented as a list of start/stop stations for a given diameter.

Things like manholes and other structures would be placed by a list of stations, and possibly more data like rotation, offset, vertical offset, and so on for fancy structures. The profile would provide elevations things are based off of. This could get really fancy. You always must allow the structure to not cause the profile to do anything though!

The really cool thing about all this is the editing mechanisms for such an object, will work for all kinds of specialized things derived from it. We write tools at our company using this approach, and it really works. The plan view editing works for roads, pipelines, walls, slope top/toes, and more. Same for grid editing of profile. All the specialized objects are is the base object with “decorations” along the way. What could have been 5 tools is one. Its simpler, more powerful, and expandable even further. Best of all, it really works on real projects.