Monday, March 16, 2009

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…


Rod said...

Another obstacle is the complexity that all of the different data formats have on the process.

The Safe Software group this morning posted a blog that over 225 data formats exist (

This obviously has an impact on the process. Obvious this is something that a asset manager needs to keep in mind and design their work flows around.

Many of these data formats are foreign to CAD folks which also introduces a set of issues as well.

Obviously a simple solution is to try to keep data flowing smoothly regardless of format and conversion issues which means picking a format that can cater to all groups CAD, GIS and asset management. I have seen it work in several organizations that have taken a hard look at the data flow process and tried to optimize their workflows into the process.

Just a few more thougths

Michael Schlosser said...

Agreed. With 225 data formats and more on the way, this obstacle has a huge impact on workflow and clearly needs addressing. The typical solution relies on import/export processes. However, a more efficient approach relies on connecting to the data natively (ie without import/export). In fact, Feature Data Objects ( has developed some traction in this regard. Thanks for your comments!

Steven said...

I think the "What's in it for me?" aspect is significant, and the path though this needs to be lead from the GIS team.
As the final step in the process the as-builts and their associated loading are always the hang over at the end of the party. The budget is spent and if there are issues the contractor doesn't want to know about it.

The GIS team needs to set out a standard and communicate the requirements through to the portfolio manager, to write into the contracts.

Although I'm quite fond of the idea of setting up a version on your database for the contractor to write to themselves, which you QA and post. This helps ensure they are also working with the latest data.

Michael Schlosser said...

Yes - new standards are needed - standards that embrace geospatial requirements yet respect the accuracy and efficiency of engineering design and CAD. I see these new standards representing collaboration between both CAD and GIS teams. Thanks for your comments!

GaryM said...

Great article and something I come across everyday in the UK. A major factor is the organisational structure, often find I GIS Managers just do not think of CAD Users. I’m actually doing a presentation in a couple of weeks aimed at IT and GIS managers, “Don’t leave your CAD users out in the Cold” on this subject.

I was at a client’s site looking at ways to improve the CAD/GIS integration, it turned out they had Oracle containing a large amount of spatial data, the CAD users did not know about Oracle and the IT team did not know AutoCAD Map could access it. With the aid of utility AutoZoom Pro , which make accessing geospatial data much easier and quicker for the typical CAD user, I had the whole team up and running in a matter of hours.

It was win win for all, the IT team where happy, I had just reduced their work load, no need to covert to CAD formats, and the CAD users had the latest up to date.