Monday, March 30, 2009

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…

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…

Saturday, March 7, 2009

GIS Skills for the Engineering and CAD Professional

ENGIS: It's not Engineering or GIS; it's Engineering and GIS!
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.

Friday, February 20, 2009

As-built Backlogs Impact Accuracy of PSAB 3150 Reports

As of January 2009, Section 3150 of the Public Sector Accounting Board (PSAB 3150) requires Canadian municipalities to report on their tangible capital assets including roads, bridges, utilities, water systems, sewer networks and land. The accuracy of such a report is based, in part, on the currency of a municipality’s infrastructure inventory databases. However, these databases are often out-of-date due to the as-built backlog.

The as-built backlog refers to the delay experienced between when infrastructure has been constructed and when information about this construction is entered into the records database. These delays often span months and sometimes years and make it difficult to provide reliable information about the infrastructure for field, management and regulatory requirements such as PSAB 3150.

The as-built backlog refers to the time needed to add construction data to the records database after construction is completeThe as-built workflow can be explained with an example. A new subdivision project typically starts by assembling a collection of cadastral maps, existing infrastructure data and other information from a variety of sources to create a base map. Subdivision design is next; new infrastructure is drafted, existing infrastructure is updated and detailed design drawings for construction are created. Then construction takes place and upon completion, information about the construction is collected and compared to the design documents to create an as-built drawing. This as-built information is then used to update the infrastructure inventory database.

The as-built problem arises for several reasons:

  • Accelerated development during booming economies often means that engineering and construction firms have all-hands-on-deck to keep up with construction demand. Consequently, creating as-built drawings is sometimes just not a priority.
  • As-built drawings are often created from paper design documents that contain redline markups describing the as-constructed information. These paper documents are then re-drafted to create an electronic version that is added to the infrastructure inventory database. The re-drafting effort is error prone and time consuming.
  • As-built drawings and the infrastructure inventory database are often maintained via different systems (typically CAD and GIS) and by different departments. Loading CAD data into a records database may require translation, editing for topology and other inefficient workflows.
As you can see, workflow contributes to the as-built backlog which impacts the currency of the infrastructure database and inadequate currency impacts the accuracy of PSAB 3150 reporting. If your infrastructure database is months or years out-of-date then how can you be sure that your PSAB 3150 reports on tangible capital assets are accurate?

The solution requires a new way of thinking. Stay tuned as I discuss proposed solutions to the as-built problem in future posts.

Until next time…

Tuesday, February 10, 2009

3D GIS is Easy

Image courtesy of Dan Campbell, City of VancouverIf you thought 3D was hard, think again. Maybe a different point of view would help.

I recently had the pleasure of attending a seminar entitled “A New Dimension in GIS – 3D Analysis”, hosted by the British Columbia Chapter of URISA, in which a half-dozen speakers shared their 3D GIS experiences and insight during this one-day event.

Convergence: The opening keynote presentation by Doug Eberhard (Senior Director, Autodesk) set the tone of this event by providing us with an eye-popping vision of the future in which the convergence of design, geospatial analysis, simulation and visualization are fuelling the emerging business of digital cities. According to Eberhard, at the heart of digital cities are models. These models range from model agencies and model designers to model contractors and model operators. These models allow us to examine our world in new ways –ways that can help us become a model planet.

New Perspectives:
Dan Campbell (Manager, Graphics and Communications, City of Vancouver) discussed the City’s experiences, gathered over the last 20 years, in working with 3D models. In fact, it was Campbell that said, “3D is Easy; it’s 2D that’s hard.” His point was that we live in a 3D world and no-one needs to teach us how to interpret this 3D world. And yet, when we work with infrastructure designs, architectural plans and maps we force our 3D world into a 2D abstraction. According to Campbell, this 2D abstraction for the non-professional is equivalent to trying to read hieroglyphics - misinterpretation and lost meaning is often the result.

Integration: Dale Lutz (Vice President, Safe Software) explored the topic of integrating CAD, Building Information Modeling (BIM) and geospatial data and discussed the role of CityGML, Industry Foundation Classes (IFC) and LandXML in the creation of 3D models. Various integration scenarios were also presented including the use of 2D CAD buildings with LIDAR to create 3D extruded buildings and the use of 3D geo-referenced BIM.

Key Takeaway: For me, one of the key takeaways of this seminar was that 3D GIS is about making it easier for the users of the information and not the CAD and GIS gurus. It’s about an easier way to analyze, visualize and communicate information about our 3D world. The boundaries between design, visualization and geospatial analysis are blurring. And yet, it’s the people and processes and not the technology that remain obstacles in realizing the vision of 3D digital cities. Data integration and an open, non-proprietary approach continue to be at the heart of the solution.

Until next time...

Monday, January 19, 2009

The Five Principles of Engineering GIS

Have you ever rummaged through your toolbox looking for that certain tool only to find that you stored it somewhere else? If you have then you know how frustrating and inefficient it can be.

Well, when it comes to CAD and GIS, traditional thinking separates design tools from geospatial tools into different packages. When you’re faced with working in both domains, however, you end up switching back and forth between those packages. This means you also need to pass the data back and forth. The process is error prone and not very efficient.

Engineering GIS combines CAD and GIS capabilities into a single unified toolset. That is, the engineering design, data creation and editing tools of CAD are combined with the database, analysis and spatial data management tools of GIS.

There are five key principles of Engineering GIS:

1. Data passes through a lifecycle. Engineering GIS recognizes that data passes through a lifecycle. For example, when working in the municipal infrastructure domain, data moves through various phases from surveying and mapping, to design and construction, and finally to management. Engineering GIS assumes that the design information will be used in different ways by many people downstream from the engineering design process. Consequently, engineering drawings are topologically correct and “GIS ready” which streamlines the task of incorporating this information into an infrastructure management system and a geospatial database.

2. Access data natively. Engineering GIS recognizes that data comes in many different formats and from many different sources including traditional engineering and GIS environments, spreadsheets and databases, as well as, desktop and web-based sources. However, rather than relying on a data import/export process, Engineering GIS promotes working with the data in its native format. Consequently, data integrity is maintained, data redundancy is reduced and efficiency is improved.

3. Leverage design tools. Engineering GIS leverages CAD and engineering design tools because of their precision and ease of use for data creation and maintenance of engineering design features, as well as, mapping and other geospatial data.

4. Leverage geospatial tools. Engineering GIS leverages GIS tools because of their data oriented capabilities for automated mapping, spatial analysis and management of geospatial databases.

5. Renderings must be accurate. Whether printed to paper or published to the Web, Engineering GIS ensures that drawings and maps are accurately rendered with the point, line and polygon styles, raster and vector overlays, symbology, dimensioning and overall appearance that users expect.


As you can see, with Engineering GIS, you don’t have to choose between CAD and GIS software because both types of tools are available in one place. Together, they create a toolset that simplifies engineering and geospatial data integration.

Until next time...why not take a moment to geoExpress yourself?

Wednesday, January 14, 2009

CAD and GIS like Milk and Cookies

Milk and cookies - just plain good! There’s something about pairing the crunchy sweetness of cookies with a refreshing glass of milk that not only tastes great but satisfies too. Some things are meant to be together.

I think that CAD and GIS are kind of like that; I think CAD and GIS are meant to be together.

If you are an engineer or a drafting professional, you know all about CAD. You know the value of using CAD for engineering design and drafting; you know that when it comes to producing accurate drawings for construction purposes, CAD is the right tool for the job. In fact, there’s no better tool.

However, as an engineer, you may also have a need to place your designs within a geospatial context; you may need to combine design information with geographic data and you may need to examine your designs using spatial analysis techniques. In fact, attribute data, raster imagery and thematic mapping may help you to better design and visualize your infrastructure projects.

Traditional thinking separates design workflows from geospatial workflows. Consequently, you stick to what you know. With little experience in GIS or little time to learn new technologies, a choice is made; you focus on design and let someone else handle the geospatial stuff.

Unfortunately, this approach results in a disconnect between design departments and GIS departments, and between CAD data and GIS data. Consequently, workflows suffer which compromise efficiency, affect decision making, and impact data accuracy and currency.

However, there is an alternative: a unified approach called Engineering GIS that embraces both engineering design and GIS. Engineering GIS together with an improved understanding of how GIS skills can complement existing design skills can help overcome those workflow challenges and ensure that CAD and geospatial data are integrated in a manner that respects both engineering design and GIS requirements.

CAD and GIS like milk and cookies – just plain good.

Stay tuned as I elaborate on the importance of an Engineering GIS approach in future posts. I’ll also highlight some of the challenges encountered when attempting to integrate design information with geospatial data and I’ll review the key skills that you need in order to take advantage of Engineering GIS.

Until then… remember to geoExpress yourself.