The Three C's of Data: Complete

A 1.667Mb PDF of this article as it appeared in the magazine—complete with images—is available by clicking HERE

How do you eat an elephant? One bite at a time. How do you design the space shuttle? One sub-system at a time. This thought is presented and will continue to be presented to all engineering students for generations to come. The thought is very simple: a complex design can be broken down into much simpler components. This applies to designing and building a bridge, putting a man on the moon or even simply building data for machine control. The largest, most complex data building project can be broken down into simple routines that need to be accomplished without error. I prefer to use the Three C's of Data to guide my routines while building data: machine control data must be Correct, Complete and Clear. My last article discussed what it means for data to be Correct. Now, let's discuss what it means for data to be Complete.

What Is Complete Data?
In the simplest terms, complete data is machine control data that provides the end user with what he needs, when he needs it. Simple enough for me--my football coach would be proud! Complete data ensure the end user will never reach a point where the data is not meeting his needs. But this simple statement generates a lot of questions. What could potentially be provided? What is normally needed? What is actually needed? When is it needed? Answering each of these questions will help define what complete data is and how to best provide it as a data builder.

What Could Potentially Be Provided?
Every construction project is going to have a limit: the location where the proposed site meets the existing site. With few exceptions, this is the potential limit of the machine control data. In other words, unless you are providing existing site conditions in your data, this is as far as you can go. But does that mean that the surface is going to extend to the limits of disturbance? Does that mean that every single component of the proposed site that has an elevation could be inserted into a proposed surface? No, no it does not. My job as a data builder is to in essence tell the field crew `I have checked this features location and elevation and it is correct.' If I can't say that with certainty, I will not include it in my model. Period. So if there is a component of the proposed site where I cannot fully define its location and/or elevation, I am not going to include it in my model.

But does that really ever happen? Don't we need a complete model? Let me give an example. Separated from the main proposed site, there is a sidewalk being constructed along an existing building. The plans specify a specific width of five feet, and it is to stop and start at the extents of the building. No elevations are provided in plans, only a typical slope of 2% from the building. There is nothing that I can tell someone in the field with machine control data that they don't already know standing in front of that building. The location is defined by the building, the width is defined by the plans, and the elevation is defined by existing site conditions. I do *not* need to include this sidewalk into my model for it to be complete. There will be similar elements of every project: a component of the project that is not defined clearly enough in the plans to be placed at an exact location with an exact elevation. I am not in the business of guessing, and no data builder should be. But estimation and interpolation? That's a different story.

What Is Normally Provided?
If every project has a limit to what could be provided, what should normally be provided? We normally provide a finish grade surface of the proposed site along with background 2D linework as provided by the engineer. In other words, I am going to take the engineers 2D linework and copy it to layer names that make sense in the field, but otherwise leave the linework intact, although unelevated. Then I am going to build and generate a finish grade surface of the proposed site based on the construction plans. The surface will go to the extents that the plans do. Until the end of contours, until the end of spot elevations, until the daylight, until the last lot, until the end of the roadway profile and so on. The surface goes until I have to start guessing, which is typically just the end of the project design. Does that mean that every single component of the site is typically elevated? Every last sidewalk bend? That grass shoulder? Every last detail of a curb line to the extent that I have eight points defining its precise cross-sectional geometry? As with most engineering practices, there is a point of diminishing returns: a point where hours in front of the computer make absolutely no difference in the field. In other words, except for me, no will ever know that I totally nailed that sidewalk to 0.001 feet vertical. Which brings us to meeting your clients' needs without drowning yourself in unnecessary details.

What Is Actually Needed?
Seventy years ago, a huge problem was trying to figure out how to get Allied troops into occupied France during World War Two. While an amphibious assault was obvious, and most likely to be the only realistic candidate, there was a desire to search out other realistic options. One suggestion was to tunnel under the English Channel. A study was done, and sure enough, it was feasible. It would take an estimated 15,000 men one year to excavate 55,000 tons of earth. But, what would happen at the other end of the tunnel when it was time for the troops to emerge? That was the end of that idea! Just because an underground channel could be constructed doesn't mean it should be done or that it is the best option.

Just because I can design something as a data builder doesn't mean I should--or more importantly, it doesn't mean that it will even be used. Nothing irritates me more than to find out some component of my model that I spent considerable work on is never used. That happens for one reason and one reason only: failure to communicate clearly with your client and/or field personnel. The biggest ingredient to complete data lies in understanding exactly what is needed. Asking the right questions is central to this process. What is your scope of work? Are you staking or using automatics--or both? Do you want to use your GPS for the utility work? Do you need daylight-to-daylight or are you doing the driving lanes only? The list differs from project type to project type, and the answers are going to differ either from client to client or from field crew to field crew. Regardless, having open communication with those who are going to actually be using the data is immensely critical to being able to provide complete data.

Million Dollar Question: When?
When we work with new clients, we typically get asked three questions: can you build the data, how much to build the data, and when will we get the data? After we have worked with a client for a number of projects, there is only one question they ask: when? One of the most critical requirements of complete data is that it is provided on time. Late data is not complete data. All the questions from the previous section are very important, but they don't matter a whole lot if you are two weeks late. In the construction industry, time is money. Literally. Make sure that you always, always know what is going on in the field. Are they onsite? Are they just clearing and grubbing? Are they moving dirt? When there is a time crunch, it may be necessary to provide a temporary file to keep the field crews moving while you finish up the rest of the model. This is not ideal, but sometimes it has to be done. If you have to do so, make sure that the portion you provide is not going to change. In other words, make sure whatever portion of the project you do provide is correct, complete and clear. Never send half done work out to the field.

Complete Data Is Always Possible
Machine control data must always be correct, complete and clear. It's not just about your reputation as a data builder; it's about getting each and every site built to the correct location at the correct elevation. No matter how bad the design is, you can ensure that the data you do provide is complete. That the data meets the needs in the field and that it is on time. This is only possible through clear communication. If you're building the data for someone else, you cannot cut corners here regardless of how many projects you have built for them or how comfortable you are with their needs. Always communicate on each and every project. If you are building data for your own use, don't cut corners just because you know which corners were cut. Always take the time to ensure that your data hits the three C's.

Part of being a good data builder is taking the time to understand the extents of the project, what you can potentially provide, what the client needs and finally how you are going to complete your work before it is needed in the field. By doing so, you will consistently provide complete data.

Chad Cooper (BSCE) got his start in engineering design 13 years ago with a local civil design firm, and now works on data prep projects with Take Off Professionals in Arizona.

A 1.667Mb PDF of this article as it appeared in the magazine—complete with images—is available by clicking HERE

[ Back ]

deliciousrssnewsletterlinkedinfacebooktwitter