No seriously, don't mess this part up. Every data project has some critical factor that has to be right. If not, there can be significant down stream issues for the entire project. Other times, if an error is introduced into a component of your model it will only affect that component. On a simple site, if you fat finger a single spot elevation you are not going to know about it on the other side of the project. If the finish floor elevation is smudged on your scanned copy of the plans, and you cant tell if its a 904.57 or a 904.67, its not going to break the entire project when you guess the wrong one. However, when building data for a highway project, if you make a mistake on the horizontal alignment (HAL), you just broke your project. It *must* be correct. Not only correct, but perfect. Every part of your highway model will be based on it. It is for this reason that whenever I start working on a highway project, getting my HAL's sorted out and correct is the first step.

Let me take a step back. I had a lot of fun writing my series of articles on the proper use and common misuses of contours. So with last months article I kicked off my next series: highway data building. While it can be tough, building highway data can boil down to some pretty straightforward steps and procedures. What I want to do with this series of articles (hopefully) is help others in establishing or refining their own highway data building procedures. Since there are not a lot of articles or references on building data, I hope these articles are helpful. However, there is no way anyone can fit a detailed highway data building step by step procedure into a single article. Highway design is cumbersome, complex and down right intimidating for some. No checklist or procedure can replace design experience, or make up for the lack of it. Instead, it enhances the experience you already have. With that, lets get on with this.

When starting any highway, the first thing that I do is get really comfortable with the design plans. Highway plans tend to be big. Along with the bits and pieces that you actually use, you will have hundreds of other pages or entire planset's that you will generally not need. However, do *not* use this as an excuse to not go through the entire planset, page by page. I can not tell you how many times I have found critical details on some random page in the back of the plans. If I have a hard copy of the plans, I will put a small sticky tab on the critical sheet groups and label it accordingly; such as P&P (plan and profile), TYP (typicals), XSEC (cross sections), SUPER (super elevation diagrams) and so on. If I have electonic scans of the plans, I will do the same except instead of sticky notes, I will rename the scan itself; such as 004 TYPICALS, or 053 XSEC. Once I have been completely through the plans and have done any necessary fancy footwork to get the electronic files from the engineer to a workable state, its time to get started with the HAL's.

Now that we are comfortable with the plans, the next thing we need to define is what are we actually building. Sure we are working on State Highway XX from Station such and such to Station such and such, but what are you actually building? To help define this, I grab a piece of paper and go back to the planset. I write down each and every roadway that I will be building and defining in my model, along with the station ranges that I will be building. The quickest way to determine this is by going to the profile sheets. If they are giving you a specific profile for a roadway or site feature, you are more than most likely going to be building this roadway or feature into your project. But this is not always the case, so some judgment is necessary to determine which ones are needed and which ones are not. I just want to have the specific Station ranges of what I will be building for each and every roadway or feature. I have found that this list is used numerous times both while building the model, and later down the road to refresh my memory if I need to revisit the project.

The next step is the most critical one. Once we know which HAL's we need for our work, we need to get them defined in our software. We need a specific, distinct HAL established in your software for each segment of roadway that we will be working with. Many times the plans will have a geometric plan and/or tables to help assist with establishing your HAL layout. If you are really lucky, this will include Northing's and Easting's, bearings and distances, and curve data for every major HAL. This information *must* be correctly represented in your work. All those PC's and PT's must match up. Those station tick marks should match your alignment. I can not stress enough how critical it is that your HAL's be precise and accurate. I have no hesitation in taking extra time during this step to get things right. Out of all the types of data work that I do, I spend much more time double checking my HAL's than anything else I do. Did I mention they must be correct?

This is great and all, but what about if there are significant mistakes in the HAL geometrics? What if segments of the engineers provided linework are not drawn how they should be? Then its time to switch hats from a data builder to an engineer. You need to correctly recreate the busted HAL, but use discretion. There are rare circumstances when you will want to use the engineers busted HAL. For instance, what if the original HAL was busted and the engineer based their design on this busted HAL? Personally, I would get our client involved, let them know what's going on and recommend that we use the busted HAL since that's what the engineer used. But I can not stress enough that this is a rare, rare circumstance. The other nine hundred and ninety nine out of a thousand times, you will need to manually rebuild the HAL in your software to the exact specifications in the plans. It is a general rule of thumb for data builders to not make the mistake of just blindly trusting the engineers linework. You need to know, without a doubt that all of the HAL's in your project are correct.

Once you have your HALs identified from the plans and positioned in your software, you are ready to move on with the rest of your work. During this general step, the next thing I address is the horizontal locations of roadway edges of pavement, shoulder, median, ramps and so on. Nearly all highways will have a changing edge of pavement width. Different software's may require special inputs, but I prefer to use the actual linework provided by the engineer for defining these critical edges, but obviously only after confirming their correctness. Depending on your software, you will also need to come up with a consistent system of nomenclature. For instance, if working on I-40, I would call my outside edge of pavement on the East bound travel lanes: I40_EB_EOP_OUT. On a bigger highway project that has numerous ramps and side roads, its not uncommon to have a couple dozen critical edges, so make sure your nomenclature system is solid. Regardless of how you personally go about doing it, getting these critical edges defined in your software, relative to the previously established HAL's is a critical step.

And with this, we still have only scratched the surface of working with HAL's. While I feel like we have gone over some of the major points, many of the finer points have to be left out and left to your experience and judgment. Learning how to *properly* design and build a highway in the software of your choice as an engineer takes years of experience, schooling and field time. For example, an engineer may have spent months or years desiging the site. You have a couple of days to build the data. As you start that process, working with HAL's has to be your first stop. It defines everything else in the project. It has to be correct. By dealing with the HAL's first, you set yourself up to hit the rest of highway building process running. For me, the next stop is profiles.