MachineControlOnline.com Exclusive Column
Data Prep: Tips, Tricks & Techniques - So you want to start building Data?

March 2009 - First and foremost, it is an honor to be part of such a solid  team. Having known and worked with many of my co-writers for years, I can assure you that you are in good company.

I have a very unique job in that I build data (3D models for use with GPS machine control) all day, everyday. That's all I do now. These projects range in size from the gas station down the road to Department of Defense projects, consisting of thousands of acres. Creating the digital terrain model (DTM) for these projects can take anywhere from one hour to several weeks to complete. Needless to say, after five years of data prep, I have learned quite a bit, mostly through trial and error, aka, the hard way.

When I began building DTM's, my methods were unproductive and clunky, a little embarrassing actually. So much of my process has changed now, improved through practice. It is my goal to present these hard learned lessons in the hope of helping others.

To start, one of the biggest clarifications that I feel needs to be made about data building is the following:

In building data, you are recreating the engineer's design, not designing the site yourself.

If this seems obvious to you, then you see something that it took years for me to clarify in my mind, in my work and most importantly, communicate to our clients. When you get a data project, regardless of whether you're a building it for your own company's use, or for another's, it's not your design. You are recreating a design. This distinction helps remind me of my role, and the bounds that I need to work within. While I can help smooth the edges on an obviously rough design job by an engineer, I need to maintain the integrity of the original design, because it is that design that the project is going to be compared to and certified against upon completion.

That being said, I can guarantee that you will never work on a project where you don't find a mistake in the engineer's design. This mistake could be a simple typo on a spot elevation. Or, it could be a critical error, where if left alone, would cause serious design issues in the field. For example, just yesterday I finished building data for a project where the engineer had water flowing to low points in the parking lot. He omitted provisions for gutter drainage. If this were my design, I would not only have to find a solution but I would be responsible and liable to do so. Since it was not my design, I built the parking lot per the engineer's design, and communicated very, very clearly to our client, both verbally and in the model itself, what the issue was, where it was, and gave my recommendation on how to correct it. And that's where my work stops.

And therein is the beauty of this distinction. Anyone who builds data has the responsibility to check the engineer's design as they build their data. The vast majority of engineering mistakes that you will see are isolated spot elevations, inverts, or similar problems. I do not hesitate to correct these obvious and isolated errors in my model. However, there are projects where the engineer's design is fundamentally flawed causing design issues.

The solution is communication. You must communicate with your client regarding the issues and work towards resolution. Sometimes the solution will be represented in your model and may include a suggested redesign component. Other times, the solution will be resolved on site. Either way, stay focused on the fact that your job is not to redesign, but to create a DTM representation of the engineers design. 

Contact the Author