GIS Databases Negatively Impacted by As-Built Problem

I just returned from Dallas, Texas this week where I delivered a seminar discussing data to design workflows and CAD/GIS integration. During the seminar, which was hosted by Expert Computing Solutions, an interesting discussion on the topic of the as-built backlog arose. Recall from one of my previous posts that the as-built backlog refers to the delay between when infrastructure has been constructed and when information about this construction is entered into GIS and records databases. According to seminar participants, that delay ranges anywhere from a few months to several years. Some participants revealed an indefinite delay; in other words, their databases were never up-to-date!

So, what are the problems of such a delay? What are the consequences of not having an up-to-date GIS database? Well, the impacts are many; listed below are just a few…

Poor decision making: Out-of-date information about the type, location and other related attributes about the above and below ground infrastructure can lead to inaccuracies in predicating future repair and maintenance requirements which can lead to decreased infrastructure life expectancy and premature replacement.

Decreased efficiency: When work orders are based on out-of-date databases, field activities are impacted; for example, when crews are dispatched in response to a repair or routine maintenance request only to find that upon arriving at the field location that they have the wrong equipment, crews must make a trip back to the warehouse to retrieve the correct piece of equipment. The result is an inefficient use of resources with time, dollars and fuel all wasted.

Re-work: Re-work occurs when the information in the GIS database must continually be verified against paper as-built drawings simply because this as-built information had not been loaded into the database yet.

Data confidence: When users know that the corporate database is not current, confidence in the data can be eroded to the point where users stop relying on the corporate database in favor of their own records. The result is data redundancy and all its corresponding problems.

Insufficient budgets: When infrastructure budgets are derived from out-of-date databases, a budget shortfall becomes a real possibility, especially in areas of rapid growth.

Environment and public safety issues: Worse yet, when users trust out-of-date information, bad decisions can be made – decisions which can harm the environment, impact public safety and create liability exposure. For example, according to the National Post, trusting old design drawings proved to be a costly mistake, when a contractor ruptured a crude oil pipeline in Burnaby, BC almost two years ago. The result was a toxic geyser that spewed almost a quarter of a million litres of crude oil onto residences, streets and into the Pacific Ocean.

Inaccurate regulatory reports: The accuracy of reports on capital assets in response to regulatory requirements such as PSAB 3150 and GASB 34 becomes suspect when based on GIS databases that are suppose to have a current inventory of above and below ground infrastructure but instead are potentially years out-of-date.

I’m sure the as-built problem generates additional consequences. However, given the above, can corporate GIS databases that are months or years out-of-date really be trusted? Caution is prudent.

If you know of other as-built related issues or have related comments, I would enjoy hearing from you…

The Obstacles to CAD/GIS Integration

In my last post, I discussed a need to address the issue of CAD/GIS integration during the design and data creation phases of a project rather than waiting until the data was ready to be moved into a corporate database. The responsibility to address this issue would rest with the creators of the data (ie the engineering and CAD professionals). The reason, I argued, was one of efficiency; that is, data that was properly structured during the front end of the data lifecycle would be easier to integrate throughout all downstream infrastructure related activities, thereby, saving time and collectively, billions of dollars.

So, why does the problem of CAD/GIS data integration continue to persist and negatively impact organizations? Why do so many continue to struggle with import/export workflows, work-arounds and the old way of doing things? Why does CAD/GIS integration remain an issue today?

Well, a number of reasons come to mind…

Data Issues: First there’s the data. Sometimes CAD/GIS data integration problems really are due to the differences in the data – differences such as the use of project coordinates versus geographic coordinates; the need for annotation (ie dimensions, callouts and other explanatory text) versus topology; the use of complex geometries (ie spline curves and 3D objects) versus the limitation of geospatial databases to store them. To a lesser extent, data formats can also be an obstacle as one attempts to massage the data from one format to another potentially introducing errors and redundancy in the process.

Organizational Structure: The way an organization is divided into its various departments and workgroups impacts communication and the flow of data throughout the organization. With respect to GIS, organizations have typically assigned GIS responsibilities and functions to the GIS Department or to a subgroup of the IT Department. This organization based separation of CAD and GIS, can create a communication gap between the data creators (ie the engineering and CAD professionals) and the maintainers of the geospatial data. Then the only time one group communicates with the other is when as-built information needs to be passed to the GIS folks for inclusion in the corporate database. Consequently, the GIS folks don’t understand the problems that can arise when attempting to use geospatial data in CAD and the CAD folks don’t understand the issues related to using CAD data in a GIS. In an attempt to overcome this communication gap between departments, organizations have held Corporate Demo Days, GIS Days and other events aimed at sharing and promoting departmental information, ideas and accomplishments.

Silo Syndrome: Organizational silos occur when departments seem to focus on their own needs without recognizing their impact on other departments or to the organization as a whole. For example, when communication between departments is poor, when the exchange of information is inefficient, or when job related requests are queued and delayed, individuals find ways to work around the problem. They begin to create copies of the data; they create their own databases; and they stop sharing information to help drive their own efficiency. Unfortunately, this can perpetuate the CAD/GIS integration gap and result in greater corporate inefficiencies. To help reduce departmental silos and ensure that both corporate and departmental needs are met, some organizations have embedded GIS responsibilities at both corporate and departmental levels.

Culture Clash: The very things that make us experts in our field also lead to differences in professional cultures. Whether it’s the contrast in educational and professional backgrounds, the knowledge and experience that we gain and share as a group, the jargon, or the type of projects we work on, they all lead to differences in the way we communicate and approach a task. These differences are often additional obstacles to CAD and GIS integration. For example, while a CAD professional is focused on documenting a design in such a way that it can be built to exact design specifications, a GIS professional may be more interested in how this information can be used for planning and analysis after construction. Culture clash seems to become most evident when people balk at the technologies used by others. What’s needed is a respect for both ends of the spectrum. It’s not about CAD or GIS; it’s really about embracing both.

Myths: Myths surrounding the capabilities of CAD continue to persist in spite of significant advances in this technology. Today’s CAD includes model-based design and rule-based workflows; integrates engineering designs with other CAD and GIS data; provides support for geographic coordinates, topologically structured features, spatial analysis and geospatial databases; and simplifies integration with web-based mapping. Rather than continuing to do things the old way because of an outdated view of CAD, current capabilities and new workflows should be examined for gains in efficiency and improvements in data integration.

Lack of Metrics: In the software industry, metrics are used to measure a wide variety of characteristics pertaining to a program’s performance. However, when it comes to the subject of CAD/GIS integration, few organizations monitor the amount of resources required, in terms of time or dollars, to move as-built information into a corporate database. The lack of metrics hides the inefficiencies and the corresponding costs associated with the CAD/GIS integration issue. So, integration challenges go unnoticed and opportunities for improved efficiency escape. Metrics are needed to highlight the CAD/GIS integration problem and to make a case for change.

Discipline Specific Tools: Discipline specific tools were created for a reason. For example, there’s nothing more powerful than the data creation and editing tools available in CAD for creating and documenting an engineering design. Similarly, GIS tools excel at spatial analysis. These discipline specific tools can perpetuate the CAD/GIS integration problem by isolating users from other ways of doing things. Users become accustomed to creating data without topology, storing their data in proprietary formats or using out-dated import/export workflows to facilitate data exchange. While some have attempted to re-create CAD-like functions as custom extensions to their GIS, others have embraced an Engineering GIS approach where CAD and GIS come together exploiting the advantages of both.

What’s In It for Me? Sometimes it just boils down to incentive. Perhaps Rod said it best: “Engineers as consultants or as in house departments are incented in such a way that they do not really care about the life cycle of the data... They just want to hammer out a design and their work stops.” In other words, significant advances in CAD/GIS integration might be made if the creators of the data are contractually obligated to create the data with a new end in mind. CAD standards have been in effect since the dawn of CAD. Perhaps it’s time for a new CAD standard - one that also addresses the downstream data requirements.


The above list represents those obstacles which I have encountered most often in my conversations with a variety of engineering, surveying, CAD and GIS professionals. I’m sure other obstacles exist. If you know of additional obstacles, if you have ideas for solving or eliminating them, if you have related experiences or comments, I would enjoy hearing from you…

GIS Skills for the Engineering and CAD Professional

Last week I had the pleasure of visiting Calgary, Alberta and facilitating a half-day seminar aimed at demonstrating the crucial GIS skills needed by engineering and CAD professionals. This well attended seminar, hosted by Pacific Alliance Technologies, highlighted the differences between CAD and GIS workflows, reviewed the obstacles to CAD/GIS integration and discussed the importance of an Engineering GIS approach.

I was expecting the audience to consist mainly of engineering and CAD folks. So, I was surprised to discover that there was a 50:50 mix of both CAD and GIS professionals. It turned out that some of the geospatial participants were looking for a better understanding of CAD related workflows. They also wanted information on how to work and better communicate with their engineering and CAD counterparts so that they could potentially simplify their geospatial data integration tasks and drive productivity. Similarly, some of the engineering and CAD participants were seeking pointers on how to overcome resistance to GIS within their own engineering organizations.

So, why is there this resistance to GIS by some engineering firms?

Well, engineering is about design; it’s about creating documents that have the exact amount of detail necessary to construct what was designed and then ensuring that construction proceeds according to specification. To these firms, construction represents completion and so their design documents and as-built drawings reflect that.

However, according to the National Institute of Standards and Technology, the cost of inadequate interoperability for U.S. capital facilities during the operation and maintenance phases is estimated at $9 billion US. If you include infrastructure, like bridges and roads, then these costs sky-rocket even further!

Design documents and as-built drawings must be created with a new end in mind.

Engineering and CAD professionals must create their design documents in such a way that the embedded geospatial data can be utilized throughout the infrastructure lifecycle. Design data must be easily integrated with corporate databases so that this information can be used during infrastructure operation and maintenance activities. Engineering GIS can help.

As the original creators of our infrastructure data, I believe engineering and CAD professionals have a responsibility to ensure that this information can be easily integrated throughout the infrastructure lifecycle. To do otherwise, simply contributes to the billions of dollars already wasted due to the lack of interoperability and poor data integration.