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…