Stuck in Neutral
As other segments of the AEC segment move toward real-world, object-oriented design, the civil segment is stuck in neutral. A rich, object-oriented design for site civil design remains elusive.
Henry Ford is thought to have said, “If I had asked people what they wanted, they would have said faster horses.” The current incarnation of AutoCAD® Civil 3D definitely has the feel of being a faster horse. While architectural design products have moved toward utilizing terms such as walls, windows, and ducts, Civil 3D uses design terms such as feature lines, alignments, and profiles.
I asked my daughters, ages 4 and 6, what those terms meant. They easily described the architectural design terms, but the civil design terms were met with blank stares. They thought I was teasing them with made-up words.
Being a Civil Engineer, I do talk to my children about the infrastructure around them. As I drive them around I point out the curb and gutters, asphalt pavement, Portland concrete pavement, handicap ramps, and retaining walls. They understand the basic language of a Civil Engineer. Unfortunately none of those terms are utilized to describe the objects in Civil 3D.
At the release of Civil 3D 2012 I was fortunate to be invited to Media Day at Autodesk’s AEC Headquarters. One of the big new features Autodesk is excited about today and for the future is laser scanning to collect existing information. What I didn’t see expressed was including real-world objects in Civil 3D.
I found this a bit surprising, because this squarely puts the product in neutral for the future. At Autodesk University 2010, Jeff Kowalski, chief technologist at Autodesk, was illustrating the future of computing through infinite computing. The civil space was illustrated by taking a laser scan of a site and using the infinite computing to strip out the rich data of the scan into a surface. No talk of converting the rich data into curb, gutters, trees, signs, stripping, or any other real-world objects the survey was intended to capture. Instead of a rich model we get a bare bones surface with only an intelligence of X, Y, Z, and color. What benefit does this infinite computing provide the civil industry? I consider it a waste of computing power if the goal is to get to the same aerial survey product of the past.
I recently put together a proposal for a project that consists of the demolition of an existing big box store including underground piping, parking lot, and building. My workflow at this point is nearly exactly the same for a traditional aerial survey and a laser scan survey. Both surveys collect points which are then converted into lines, arcs, and points representing the real-world objects. Wouldn’t a better result be real-world objects? I could then delineate the area of demolition and get a quantity take off of items to be removed. Instead I’ll have to manage with four lines representing the existing curb. I have to make sure I count those four lines only once.
The future of scanning appears to be stuck in neutral representing methods of the past that are just a bit faster.
With the advent of NPDES II requirements, the need in the civil industry for a data rich model is paramount. Many NPDES permit requirements demand that the design take into account hydro modification and prevent the post development water runoff from exceeding the predevelopment runoff. With the current incarnation of Civil 3D this becomes a harder process then it needs to be.
If Civil 3D was driving full speed ahead, a designer would be able to model using real-world objects for pavement, buildings, and landscaping. If the surface were made up of real-world objects, it would then be possible to model the flow of a water drop across the site. The water drop could then collect information as it flowed to the low point. It could determine that it goes slow in the landscaping area and speeds up once it hits an impervious surface.
The necessary hydrology coefficients could be derived from the different types of objects that make up the surface as the water drops flow through the model. It would no longer require the manual quantity takeoffs the process now requires. In a civil industry in “drive,” the change would be made and the calculation inputs would be updated.
For the past several releases of Civil 3D, Pipe Networks appears to be one of the most neglected portions of the product. Pressure pipe capability does not appear to provide the ability to model water supply systems. The industry is stuck in neutral—having to use unintelligent objects to perform the design. Sewer laterals from the main line to the property lines remain elusive, requiring a heavily manual process of labeling (if required by the sanitary sewer utility).
Nearly all utilities require separation between sewer and water lines. The industry is still tasked with performing this check in a manual fashion—either by manually checking the distances between utilities or running a conflict report. The industry is stuck in neutral with not having the water and sewer lines dynamically react to each other.
Figure 1: Sewer network
Many public works departments have specific locations for where utilities belong in the right of way. For instance, in Riverside County, water lines are to be located seven feet from the curb and storm drain lines seven feet from the center line. Have a design change in the roadway? Unfortunately, the location of the utilities don’t update with changes to the alignment.
It may not come as a surprise to you, but buildings sit on sites designed by civil engineers. If you are a civil designer you may be excused for not knowing this, as your civil design software doesn’t seem to know it, either. The main driving force in designing sites is mainly for the construction of buildings on the designed sites. I recently created a preliminary grading plan for a small subdivision project. Unfortunately, I messed up by putting a finished floor (FF) elevation on the plans, but was grading from that FF elevation instead of the pad elevation.
With a building object integrated into the product, my mistake could have been eliminated. I could have established the thickness of the pad in relation to the FF using the building pad object. Better yet, it would be great to import a Revit model of the buildings and pull the elevations from the model.
Handicap Ramps and Driveways
In the US, nearly every project requiring sidewalks requires handicap ramps to comply with the Americans with Disabilities Act (ADA). The ADA requires strict limits on the slopes that the ramps require. Driveways are also common occurrences for roadways. Both driveways and handicap ramps are absent in the Civil 3D product.
Figure 2: Modeled handicap ramp
A lack of a dedicated object makes illustrating a design troublesome. Figure 2 shows a handicap ramp I modeled using feature lines and a surface. The results are less than spectacular from a standpoint of illustrating how the finished product will look. Can you tell what surfacing is between the handicap ramp and the curb and gutter? Without a dedicated surface, showing the design takes a lot of work, creating boundaries and individual surface types.
Corridors appear to have received an outside share of development within Civil 3D. This is most likely due to Autodesk’s push to get Civil 3D accepted into the Department of Transportation in several US states. The user interface improvements have made the product easier to use. With the inclusion of Civil View in Autodesk’s civil software portfolio, showing a corridor design in Navisworks is easier.
Corridors are one of the few parts of Civil 3D that meet the promise of Building Information Modeling. Even so, one glaring omission exists. The profile is tied to the stations along an alignment rather than a geographic location. Any changes in the alignment results in the profile not reflecting the design intent. It’s rather frustrating seeing the demonstrations of the product and not being told that the changes are reflected in the profile. This is especially frustrating on long lengths of road on hilly terrain where the changes can cause the roadway to no longer balance.
Stormwater design has been greatly improved with the addition of Autodesk Storm and Sanitary Analysis (SSA) to the Civil 3D package. Built with the EPA-SWMM, it provides the ability to perform pollution removal analysis. As mentioned previously, this article the integration could be better integrated with the Civil 3D model. With EPA-SWMM it’s possible to model how pollutants will be conveyed through a project site.
SSA also provides a way to model both the hydrology and hydraulics of a site. A closer integration between Civil 3D and SSA is needed, but I don’t see that as being possible until Civil 3D enables modeling of required information such as surface type, coefficients, and flow direction to an inlet.
While Civil 3D is an exceptional improvement over Land Desktop, it falls far short of consideration as a BIM product. Many of the benefits of utilizing Civil 3D as a design tool are the improvements over the tools found in Land Desktop. 3D polyline tools have been replaced with feature lines, surfaces have been improved to be dynamic, and pipes are easier to use.
Unfortunately if we view Civil 3D as a BIM product, then we also have to call Land Desktop a BIM product because of the same tool sets available. I’m not quite sure if you can find many who would call Land Desktop a BIM product. If all that has been done is an incremental improvement over Land Desktop, I’d have to consider the civil software industry firmly in neutral.
Christopher Fugitt is a Civil Engineer and has spent the last eight years designing government projects as well as residential subdivisions. He now provides Civil Engineering and Civil 3D services at Civil Reminders. Christopher maintains and authors the Civil 3D Reminders blog at http://blog.Civil3DReminders.com/