The Three C's of Data: Clear

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

Machine control data must be correct, complete and clear. Simple and straightforward. If data fails in any of these three categories, it will be of only limited use. If it fails in all three, it will be of no use. As GPS and machine control become more accurate and more widely used, there needs to be greater education for those who prepare and build machine control data. Very simply put, that million dollar machine is going to be a wasted resource if you're guiding it with bad data. My articles, both online and in print, are working towards that very simple goal: educate both those who are using the data and those who are building the data on what machine control data should be, and should not be. To help with this, I have developed my Three C's of Data. The past two articles dealt with the first two attributes: correct and complete. We will finally wrap this up with the final attribute that machine control data must have: clear.

Pounding Hubs In The Sun
I am of the opinion that anyone who has anything to do with construction has to spend time on the jobsite to fully appreciate what all this work is about. A civil engineer who has never stood in the mud on a jobsite, looking at a set of plans on the hood of pickup truck is missing the beauty of construction. By that same standard, a data builder who has never pounded hubs in the sun, set lath in the wind or tried to read a screen in the rain is going to have a hard time understanding the reality of how their data is being used, and why it is absolutely essential that it is clear in its presentation.

Machine control data must present information in such a way that it is just as equally clear in the field as it is in the office. It must be presented in such a way that standing there in the wind you can easily find top back of curb and set a stake. An operator needs to immediately know in the cab of their grader whether this surface is to finish grade or subgrade. These examples can go on forever. The simple point is that data can be correct and complete, but not clear. You can have the entire surface, all the points and linework, but everything is in such a disorganized state that no one is sure where to start. Clear data is presented in such a way that someone who has never seen a project built by you before can instantly recognize the layer that has background curb linework or the layer that has elevated curb linework. That is why I believe there are four major points of clear data: layer and color management, consistency and communication.

Bob And Cindy's Curb
One of my first steps on any project is going through the layers looking for the linework that I will need to build the project. It gives me a chuckle every time I see a layer called `BOBS CURB' which obviously is not as current as `BOBS NEW CURB' Though I am confused . where `CINDYS CURB' fits into all of this.

For those who build data, one of the greatest services that you can provide those who will actually be using your file is a clear layer naming convention. Having never seen one of your projects before, someone should be able to tell what each layer is just by reading its name. Just by looking at your layer names, can you tell which layers are elevated and which are not? Can you tell which curb is for demo and which is proposed? For those receiving the data, look through the layers before it ever gets to the field. Do they make sense to you? If they don't in the office, they will not in the field. Get with your data builder and encourage them to provide layers that are clear and intuitive.

One of the worst mistakes a data builder can make is to leave the layers that will end up going to the field with their original names from the engineer, surveyor or architect. I am sure that the field crews will really appreciate seeing layers such as 33265314.xref. prop.C.CURB.FACE.FiNaL--that will win you lots of friends in the field. Engineers and architects are using their layer naming conventions for design and drafting, and it works great for that and those no need to change what they are doing. But, when you're standing in the wind and dealing with a screen that can only show a limited number of characters, a thirty-six character layer name is not ideal. Especially when you can communicate the same thing with 2D CURB. I am a huge fan of simplicity, and I use this approach to my layer naming conventions. Any layer that starts with a 2D is... wait for it... not elevated! Whoa, I know--pretty heavy stuff. And I bet you will never be able to guess what it means when there is a 3D in front of a layer? If you're building data, go through your layer naming conventions. Do they immediately make sense? If you're the one receiving the data, go through the layers provided. Do they make sense? Is it clear that whoever built the data has put time and thought into how to provide information to your field crews or are they being lazy? Laziness is the single biggest difference between a good data builder and a bad one.

Everything Is The Same Color?!?
There was a point when one of the major GPS manufactures had just released a new version of their office software. Some new bells and whistles were added, but to my horror, whenever I brought in our work to provide to a client, all of the linework was red! It took a few days to work out the bugs and figure out where the problem was. In that time, I had to send out a few projects that could not wait. Following this were endless phone calls from the field. "Why is everything red? Can't you change the color? What's wrong with you? I hate you." Somehow passing the buck back to the manufacturer didn't pass with the blade operator. I have a greater appreciation for color management after that experience.

Good data has different colors assigned for each component of the project. This can be dictated by the data builder or by the field crews. Just as an engineer or architect relies on line weight's to make a good set of plans clear, a data builder needs to use colors to distinguish each component of the project. By and large, which colors to use for which components will be up to the data builder. In ten years of building data full time, I have been given color instructions only a few times--in other words the client told me `I want back of curb red, 2ft from back of curb green and the building pad yellow'.

Why don't more ask for this? Because it is so quick and easy to change any component's color in the office or in the field. But if they can change colors so easily in the field, why can't I just make everything red? Because not every field crew has specific colors for specific components. The majority are going to pretty much leave your colors as is. For those who build data, take the time to ensure that each layer you are providing has a color that is unique. For those who receive the data, open the file immediately and ensure that you can tell what the different project components are based on color and layer name. If your screen is bleeding red linework, have a nice, motivational chat with your data builder.

Consistency, The Fourth C
When I was working up my three C's, there was another `C' that I considered adding: consistency. But all of my Westernization told me to stick with the magic three, so I left consistency out. Regardless, consistency is one of the most critical components of clear data. Most field crews or companies will be using the same person or company to build their data. An understandable expectation is that each file is going to have the same setup as the last. The same layer naming convention, the same color convention, the same file type and the same general layout of the data. That 2D CURB now will have the exact implications that 2D CURB had on the last project. This parking lot will still be to finish grade, just like the last one. There will be a single point at the center of storm box to the lowest invert just like last time. A good data builder will be able to provide the same setup for each project--even different types of projects--without having to introduce some new layer naming convention or layout of the surface.

Granted, things change. Maybe for the last project your company was the general contractor and had to not only put in the roadway, but do all the formwork also. But on this project, you are only responsible for the sub-base and so you want a subgrade surface this time around. These types of considerations bring us to our final component of clear data.

Yes, The Phones Still Work
Communicate. Every project. No exceptions. It's so simple, but skipped so often. Each and every project needs to be talked about. Each project is going to have unique needs and considerations. Even if this parking lot is going to be built exactly the same as the last one, still take the time to go over this fact with whoever is building you data. And yes, despite what many think, the phones still do work. For those who build the data, take the time to talk to whoever you are building data for. Make sure they understand exactly what you are, and are not, providing. Make sure you understand their scope of work and specific needs in the field.

For those who are receiving the data, if your data builder is not calling you, call them. Tell them what you need and what you expect. If you don't really need the project for a month, let them know. If you needed it yesterday, let them know--but be realistic in your expectations for how fast data can be built. Good data doesn't get built in minutes. Just be honest about your scheduling and how quickly you need the file. I cannot tell you how many times someone has screamed for a project RIGHT NOW and then they call two months later and say `So I just opened your file...'

Correct, Complete And Clear
Quality equipment, competent operator and good data. If any one of these fail, you are not going to have a good machine control experience. All too often it is in bad data that the problems arise. Regardless of whether you are the one building the data, or using the data, the data must be correct, complete and clear. It takes work on both ends to ensure that this is and will continue to happen. Dealers, make sure when you sell that shiny new piece of equipment with machine control installed you impress upon your client the needs of their new addition: a competent operator and good data. Good data is more than just `converting the contours' Good data . is more than just `using the engineer's surface' Good data requires time to . be correct. Good data requires skill to become complete. And good data requires consistency to be clear.

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 2.503Mb PDF of this article as it appeared in the magazine—complete with images—is available by clicking HERE

[ Back ]