#### Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

# Interested in BIM for civil engineering?

I was thinking about the BIM abilities of bricscad, which I know little about.

I have seen how revit and other progs model buildings, but not a single example of a program that understands how civil engineering BIM objects should be.

That idea of how they "should be" could go a lot of different directions, but what I am referring to is roads and pipelines. I do not mean things like pump station buildings.

I am also not confused about calling 3d things as BIM. BIM objects must contain the industry defined design data required to show in 3D, but its the data that is the part you need to get right to have useful things.

People that do civil design for a living, know that we use a thing called an alignment for linear design. An alignment consists of 2d lines and arcs which define the position in the xy plane (plan view), and a set of lines and parabolic "vertical curves" that define things in the Z axis (profile).

Then we combine those two things to know where something like a road centerline or pipeline invert sits in space. Sometimes we involve another alignment for when the profile is defined along some construction centerline, then projected out to the real, somewhat parallel, location. The data and math are simple though. We do not have native objects like a spline or something, that show the 3d thing. Its always tessellated with a bunch of little straight segments.

Then you add in things like manholes and other structures at certain stations (2d distances from the plan view start of the alignment), as well as pipe diameter start/stop locations. Roads are similar, but much more complex. Roads involve several alignments tied together with cross sections, they are a beast and even involve areas of arbitrary curvature we model with 3d lines floating in space that help control the surface created for the road. How you contain that data is something to be discussed, as it involves compromises.

I'd at least like to see a pipeline/conduit BIM object though. Autodesk did theirs wrong, so the dwg industry suffers from lack of 3d utility models.

Grading is another beast, and is similar to a road with sections and all. We usually make a triangulated surface to model it, which is dumb and non-parametric, thus not BIM. The lack of real BIM objects on the civil side has led many to start calling anything 3d as BIM. They also make heavily compromised things that can take the shape of pipelines, but are not based on the plan and profile data. You must have the original data contained or the editing becomes ridiculous.

We did tools for pipes that use the alignment data and they work great. There is a ton of room for improvement, but I'm just saying the whole civil engineering community is designing these things, and the autodesk crew got it wrong for pipes so a good chance to jump ahead of them.

•  James, have you had a look at Advanced Road Design by Civil Survey Solutions? I've been meaning to give it a trail to see how it compares with the civil design stalwart "12d" here in Australia. ARD looks like it might be good for roads and grading but light on the pipeline and sewer design when compared to "12d".
Cheers,
Ben
•  James, have you had a look at Advanced Road Design by Civil Survey Solutions? I've been meaning to give it a trail to see how it compares with the civil design stalwart "12d" here in Australia. ARD looks like it might be good for roads and grading but light on the pipeline and sewer design when compared to "12d".
Cheers,
Ben
• not yet, but one of the developers Laurie Comeford (spelling?) is a long time Adesk DG guy.

Its funny because the bigger progs seem to be really good at roadway modeling in general, then you get to see how they handle details like in subdivision design with multiple intersections, knuckles, and so on. The issues with roadway design tend to be how the data is shared, and if the interface is easy enough to use.

Then, when the same bigger programs deal with pipes, they fall apart. They have forgotten that pipelines are roads that have diameters instead of a pavement section.

For the ARD pipelines, the question is if they are based on true alignment data like a road centerline. In other words, the profile is not controlled by anything going on with the structures, or horizontal segments. Pipelines are not "tinker-toys" with hubs that connect pipe parts. They are more like railroad tracks, that you could run any train on. The train car wheels do not control the track, the track controls them. Same with pipes.

What has happened is the software makers have misunderstood the difference between schematic models used for drainage and pressure analysis, and tried to turn them into design tools. The schematic tools treat things as nodes and connectors, aka "tinker toys". I use those kinds of models for pressure analysis with watercad all the time. That model is ridiculous for making plans from though.

Once you have that pure unconstrained model, then you can optionally add constraints if the user wants them, like minimum cover, but you will also have to be very careful how those rules change thing in real time. Most designers will want to know what "needs" to change, then see what the change will be, then accept it and deal with the annotation changes it causes.

I have not looked at ARD close enough yet though. Let me know if anyone has to know if its pipelines are true alignment based.

• From what I am seeing on the ARD site, their pipe networks are exactly what I describe as "tinker toys". The most awesome tinker toys ever made, but not alignment based.

That is my impression, worth about nothing until I get a chance to ask them....

• Tho I know nothing about this world, beautifully explained James
• Tho I know nothing about this world, beautifully explained James
• From what I am seeing on the ARD site, their pipe networks are exactly what I describe as "tinker toys". The most awesome tinker toys ever made, but not alignment based.

That is my impression, worth about nothing until I get a chance to ask them....

James this is classic problem that I ran into years ago - I referred to this as a relative object.  A simple example is a rural pipeline that is always offset 20' from the property line.  Before GPS, when base maps were not accurate, the same problem was encountered with transmission towers.  Their location could be defined relative to a property line.  When the property line was updated, the tower would move automatically.

Now within ARD, they do indeed have the ability to link a sewer network horizontally and vertically to an alignment.  I've attached a screen cap from the ARD tutorial that shows the basic process.  You can also set additional constraints such as minimum cover etc.

Now if we can just get rid of the BIM acromymn for outside infrastructure.  Seems to me this modeling side is GIS but then Autodesk does not want to give any edge to Esri so we follow blindly behind.

ARD-Sewer.png
• What you are describing is the hubs from your utility model being hooked to offsets of some construction alignment.

You can see that programmers like to model utilities as hub and spoke, as that simplifies certain things, and seems to fit drainage systems at first.

It may be that some designers want one thing to control another, but that would be a subset of the general pipeline BIM object. Changing horizontal alignment or vertical, automatically would be a big deal for most designs I have seen. I normally do not lay out a pipeline and want it moving until I decide its in the wrong place.

I think what happens is when you get into certain things like catch basins, people start saying they want them at some offset and so on. Maybe the same for water meters. That kind of control again is a subset, yet programmers focus on it and sometimes let it drive things.

90% of most designers just want stuff that lets them record a horizontal and vertical alignment, add some metadata like diameter to show in 3d, and have labeling tools for plan and profile that pull numbers for the label location. We will manage moving stuff and checking things, we need the basics first though.

•  Hi James,

Shane O'Rorke here (Technical Services Manager at Civil Survey Solutions).  We got into some dialogue a little while back about what Advanced Road Design does for pipes and structures, and I was remiss in not sharing that back to this post.

Our pipeline design is currently based on a ‘network’ of connected pipes and structures that are routed to a single outlet per network.  Having said that, the system behaves similarly to an alignment and profile arrangement – selecting an upstream structure will then display all pipes and structures along the branch, all the way to the outlet.  This includes documentation of the station from the downstream to the upstream end.  Our network understands it’s inherent connectivity and manages flows throughout.  You can start the layout from polylines if you like.  Each structure acts as a horizontal and vertical control (in which case it differs from the separated horizontal geometry of an alignment and the vertical geometry of a profile).

Published profiles are automatically created along the pipeline centreline, similarly to how it is managed for a traditional road and alignment design.

Our core customer base is from Australia, and in Australia the ‘trunk’ pipe network typically runs along the side of the road where the inlet structures are – they aren’t funnelled into a trunk main in the centre of the road (which looks to be a normal approach in the States).  If the focus was on the trunk mains (with few contributing inlets along the way) then treating the stormwater system as a ‘road’ with pipe and structure elements could deliver significant benefits (both in moving multiple 'structures' by realigning the nodes of the pipeline alignment and allowing a more interactive approach).  Water mains design would definitely be more streamlined with an alignment/structure approach, because the vertical and horizontal grade changes can be treated quite separately and there aren’t often ‘drops’ between pipes along the water mains.

Structure drops are a main driver in the stormwater in Australia – because the inlets come in over the ‘trunk’ pipe system, drops between upstream and downstream pipes across the structure are critical.  Managing these on a profile basis, conceptually, might be more challenging than telling the customer ‘Hey, here is a structure and this is the drop across and these are the pipe diamters either end.  Not happy, shake the pipes up and down to get the desired drop’.  Sumps also make life interesting.

Our development team are very interested in pursuing your process for pipeline design - users would establish the plan geometry (alignment) and then add 'structures' (like PVI's) where required for the vertical components.  I expect that in the future there will be options in our software to create and manage pipelines similarly to how you suggest.

• Hi Shane,

That makes sense, as you have pursued a particular problem and introduced constraints to do that.

I do find it interesting though, that software makers seem to approach pipe design from the part based idea, when those same software makers likely started out doing road design tools first. You would think the patterns of product use, in plan and profile and 3d, would make them see that pipes are roads, but simpler in that they just have a diameter (or constant section) and structures along, instead of some varying section hooked to curb profiles and so on. As a programmer myself, I always try to re-use objects, and add properties as needed. Gravity systems do get interesting though, as the structure drops tend to heavily influence the desired profile editing behavior.

That's ok, but you have to be careful because your team must realize they now have a specific pipe object, not a general utility object. A general object could do so many things, as we have discovered. Thanks for commenting though, I am clear on your progress. Holler if you want to go into how an alignment based object can be used.