State level highway engineering projects are large, complex endeavors that involve many public and private agencies operating over a period of several years. To get from initial planning to completed construction, the project must undergo numerous phases and pass through many hands. Even though a state highway department may “own” the project, the actual work is usually done by both department of transportation (DOT) personnel and private sector companies. Coordination with federal, municipal and county agencies is often required as well.
Although computer applications have long been used across the entire spectrum of project development operations, these activities are usually performed in isolated islands of automation. Each group uses different software systems with proprietary formats and data structures that narrowly focus on that group’s tasks. Digital information has not easily moved from one island to another, causing wasteful duplication of effort.
The industry has long needed means of communicating real-world, digital design data between users, suppliers, products and agencies over the entire life cycle of a project. This is finally beginning to be achieved with the development of LandXML.
Delivering Digital Design DataThere are a number of reasons why it has taken so long for a total life cycle data exchange format to emerge. Before computers became available, the deliverable products for each phase in the pre-construction process were paper drawings and reports. Preliminary designers and planners would superimpose rough alignments onto quad maps and aerial photographs. Surveyors created and delivered a set of detailed topographic maps. Highway designers were paid to deliver a completed set of plans with profile and cross section drawings, which were put out for construction bidding.
The desktop computer revolution has changed the way that these products are developed, but the end result of each phase is essentially still electronic paper. Whether they are PDF documents, AutoCAD drawings or MicroStation design files, surveyors and engineers are delivering exactly the same type of product as their pre-computer predecessors, only in electronic format. Since drawing files are only graphical representations of the survey and design models, there is no easy way of getting the models and intelligence behind the graphics into the other phases of operations.
A set of design drawings is the end product of an enormous amount of work involving engineering analyses and expertise, compliance with design standards, computations, cost estimating, review and revision. Chances are that much of this work is performed with a specialized design system such as the Visual PE software products of CAiCE at Autodesk that creates detailed data models for the existing terrain, geometric layout, profile design, roadway design and drainage systems. The drawings contain little information about the design development process, only a graphical representation of the submitted design.
Let’s take the center line alignment shown in Figure 1 on page 15 as an example. It begins at station 10+828 with a 100-meter tangent, going into a curve to the right with a radius of 450 meters through an angle of 45 degrees. There is also a station equation part way into the curve. The electronic information for the alignment drawing is a list of graphical attributes and unrelated line, arc and text elements like that shown in Figure 2 above. There is nothing in this file to indicate that a highway alignment has been defined and it is useless for transferring usable design data from one software system to another.
Electronic paper deliverables are one of the primary reasons why digital data that should be shared with other involved groups stays trapped on its own island. For example, there is no automated way of transferring the intelligence behind the design plans to the construction process. All too often, the first step in construction automation is to manually digitize the printed highway cross section sheets, even though these were created from electronic data to begin with. Similar automation gaps often occur between other phases of the overall project development process: planning to survey, survey to design, and so on.
To make matters worse, large projects are often divided into sections that are contracted to different consultants. Thus, not only is there a data incompatibility between, say, the survey and design phases, but also between portions of the project.
Data and Software Standardization in the DOTsThe only way a state highway department could achieve some measure of smooth data flow throughout projects was to enforce data and software compatibility among its own users and its consultant community. For example, a private engineering firm producing design drawings for the Florida Department of Transportation is required to deliver MicroStation DGN files and knows exactly what levels, colors, line styles and font styles are required for every item on the drawings. This provides useful consistency, but it still does not deliver usable design data that can transfer into other areas of project operations.
The British Columbia Ministry of Transportation has achieved a larger measure of compatibility by using the same suite of software systems throughout the surveying, design and construction processes. Consultants are required to deliver both CAiCE project files with survey and design data and finished plans as AutoCAD DWG files. This ensures that they can easily make design modifications and carry the data forward into the construction process. However, this practice places a heavy burden on the consultant community, who must use different survey and design systems for different clients. For instance, an engineering company in Seattle that has to produce CAiCE and MicroStation files for the Washington DOT may also have to deliver Eagle Point and AutoCAD files for King County. Developing and maintaining expertise in multiple systems adds considerable overhead to operations.
The Advantage of LandXMLClearly, what is needed is a way of moving intelligent, digital information transparently among all of the different software systems for all groups in all phases of the projects. This is exactly what the LandXML organization has set out to provide. To ensure its usability for all facets and phases of civil engineering projects, the LandXML organization includes a broad base of professionals from federal, state and local agencies in the United States, similar agencies in Europe and Asia, software developers, instrument manufacturers, and private surveying and engineering firms. For example, the Florida DOT was an early participant in the design of LandXML. For Florida to archive civil engineering data, the state’s Bureau of Records requires an open published format to be used. Because LandXML clearly meets this requirement and solves the problem of sharing data between proprietary systems, the DOT is actively considering adopting it for long-term archival.
Figure 3 on page 16 shows the same alignment we examined earlier in LandXML format. Here, the entity is clearly tagged as an alignment, along with the name, total length, starting stations and description. The Coordinate Geometry section contains detailed geometric definitions of each element in the alignment and is followed by a list of station equations.
In short, the LandXML file contains software-independent information that any GIS, mapping, surveying or design system can use to precisely re-create the alignment. LandXML also stores survey measurements, survey points and chains, parcels, terrain profiles, alignment profiles, superelevation specifications and cross sections.
The Oregon Department of Transportation recently decided to purchase Autodesk’s CAiCE Visual Survey product for pre-design survey operations statewide. According to Ron Singh, Oregon’s chief of surveys, “The support for LandXML was a key factor in the decision to select CAiCE. LandXML makes it possible to deliver the completed survey and terrain models to the designers in a compatible format.”
The Impact of LandXML on Highway EngineeringSupport for importing and exporting LandXML data is just now becoming widely supported among industry software systems. It is still too early for LandXML to have realized its full potential in addressing the issues discussed here. Nevertheless, it is beginning to have a significant impact on highway engineering automation, and this impact will only increase as more software developers support it.
On the surveying operations side, it is already possible to transfer and combine surveying, coordinate geometry and DTM information among a variety of systems, including Eagle Point's Surveying and Civil Design products, CAiCE Visual Survey, Terramodel and Geomatics Office from Trimble, Autodesk Land Desktop and Carlson SurvCADD XML and SurveyXML. The resulting digital models can be given to roadway designers or construction engineers using MxRoads, CAiCE Visual Roads or InRoads. Software developers in other countries are also beginning to support the standard.
Another aspect of LandXML is that it makes it possible to write auxiliary software systems that can obtain data from a wide variety of sources. The Federal Highway Administration (FHWA) is a case in point. FHWA has developed a new product called IHSDM (Interactive Highway Safety Design Model) that performs crash prediction and other safety analyses on proposed highway design models. Because it is intended for use by a variety of agencies, it was essential that IHSDM be able to work with all of the commonly used highway design software systems. To achieve this, FHWA worked with the LandXML organization and several software vendors to extend the schema to include roadway definition and grading models. At the time of this writing, IHSDM is being beta tested and evaluated by several state DOTs and other agencies.
Steve Brown, PE, the application development manager for the Nebraska Department of Roads, says, “We are already converting our in-house deed description program to work with LandXML data because it gives us the ability to actually store and manage geometry and parcels. It also maintains the coordinate reference information, so we can use the stored data to validate resurveys of property boundaries. We see a great potential for using LandXML for long-term archival of design data. We need to store our data in a way that can be retrieved and used 10 or 20 years in the future. Furthermore, we view LandXML as a vehicle for sharing data across state boundaries.”