GIS CAD Interoperability: March 2006

March 29, 2006

The CAD Staging Geodatabase Road Map

Suffer me another sports analogy... We had a great basketball practice yesterday, the last of the year. As the assistant coach of my daughter's freshman basketball team, I told the head coach yesterday, we can't add anything new as we head into the tournament. Like the Apollo 13 astronauts if something is broke the only thing we can use to fix it is the stuff we brought with us. Well... the CAD Staging Geodatabase is the best representation of what is available in CAD drawing that is accessible by ArcGIS. It is a collection of most all you can bring with you from a CAD file into ArcGIS.

This BLOG is dedicated to the many ways you can interoperate between CAD and GIS. One of the first tools new users find in the ArcGIS ArcToolbox is the IMPORT FROM CAD tool (although not always necessarily the best tool for them to use.) For most workflows this tools is not required since there are many ways to directly use CAD data, Cut-and-Paste and to simply append/copy/save CAD data to ArcGIS feature classes without using the IMPORT FROM CAD tool.

The primary use of the IMPORT FROM CAD geoprocessing tool in ArcGIS 9.x is to create a CAD Staging Geodatabase which is a normalized set of tables and feature classes. The tool is designed to represent a collection of one or more CAD files as a single geodatabase with all of the usable geometry and CAD properties organized in various tables. Unlike the default behavior of the ArcGIS CAD feature classes which allow you to view CAD drawings as GIS features with a virtual table of popular CAD properties, the resulting CAD Staging Geodatabase simply creates tables of properties that you may want to organize in various ways. No assumptions are made as to the relationships you may want to build from the raw CAD data. In contrast the ArcGIS CAD feature classes provide a useful default way to organize a CAD file as GIS content.

I have created a PowerPoint roadmap diagram of the CAD Staging Geodatabase that you can use as reference when working with the IMPORT FROM CAD tool on more complex data migration workflows.

There are a series of tools in my CAD Samples Toolbox that are dedicated to helping you make better use of the raw data in the CAD Staging Geodatabase.

March 24, 2006

Badda BIM Badda Boom!

I attended the 2006 JSEM/Geospatial Technologies Symposium this past week in Denver. This was a meeting of US Department of Defense (DOD) and Army Corps representatives interested in developing environmental science and geospatial systems. If the Army Corps’ CADD and GIS Technology Center is any indication of how serious the Army Corps and DOD are about BIM (Building Information Modeling) then BIM may be here to stay. There were no less than a dozen technical sessions where BIM was the topic. Many of these sessions were discussions of the goals and hopes for BIM, other pointing out some of the concerns and complexities of implementation and interoperability. There were a couple of case studies including one system built for the Coast Guard that showed some of the power of at least one implementation of BIM.

It would seem to me that many forms of BIM are just any implementation of Architectural 3D CAD applications. Autodesk’s REVIT, Architectural Desktop , Bentley Architecture or Graphisoft’s ArchiCAD are in their own right fully functional BIM applications. All of these applications existed before the BIM label was popularized. Clearly, many people ascribe more meaning to the special acronym BIM. Typically the modern buzzword BIM is married to another acronym IFC (Industry Foundation Classes) The IFC ‘standard” is a data standard for describing BIM. Its goal is to form a framework for BIM interoperability.

There are a lot of people smarter than me defining the taxonomy, data structures and applications of BIM, though 3D CAD architectural software, but what interests me is its usefulness as GIS content. The question I ponder as someone interested in GIS and CAD interoperability is, “what does BIM mean to GIS?”

I, like many are still in a wait-and-see mode for many of the details of BIM and IFC’s. However it is my gut feeling that one useful way to characterize BIM/GIS interoperability is as a form of CAD, (with more explicitly defined data schemas and that's a good thing.) Like traditional CAD applications there is a lot of flexibility in the implementation of Architectural 3D CAD applications and their interpretation of what BIM/IFC’s are, and can be.

There are several different ways one could interpret useful GIS and BIM interoperability. The easiest and perhaps most flexible would be the same way in which CAD data is handled. Like a CAD file a BIM could be opened as a Geodatabase where the objects in the BIM are abstracted into a collection of GIS Points, Lines, Polygons, Annotation and MultiPatch features. This type of view doesn’t even have to attempt to resolve all of the possible object hierarchies, collections or other relationships.

Another question worth asking is what type of file do we expect to interoperate with? Should the intermediate file be an IFC file, or the BIM’s directly in their own various flavors ? One might even consider a DXF file or the CAD file itself as the interoperable intermediate data format. If one were to express the BIM as simple CAD entities then the work of GIS is already finished. ArcGIS already knows how to read a CAD drawing… (depending on the entity types).

This topic deserves more of my time and energy; right now I think it may be to early to tell how the markets will respond. Will anyone other the owner-operators customer like federal/local governments be able to coordinate and fund a useful BIM, is that market, enough? Will the IFC taxonomy and data model definitions swell to accommodate all of everything so that the STANDARD becomes like a life size map of the world you keep in your back yard?

March 16, 2006

Data Interoperability Extension vs. CAD Geoprocessing

They don’t call it March madness for nothing. My daughter has been on three different basketball teams if you count her new all-star team. I have been the assistant coached for two of them, and a parent helper for the other. When one team plays a game I think this is my “favorite” team I really like this team best, then the next team plays and I think... you know I really like this team! The girls are great on all the teams and there is really no reason to compare them. They all have different strengths and weaknesses and play in different leagues. The all-star team is made of players that our team played against ("the enemy!") ... the girls on the all-star team really are terrific!

In my job I get asked a lot, "Which is better the ArcGIS Data Interoperability Extension or the core ArcGIS geoprocessing tools that work with CAD data?" For that matter, people ask me to compare competitive products too, "the enemy". Each of the different teams often perform similar tasks, but they are in different leagues. CAD based GIS add-on software is competing in a league at a definite disadvantage for GIS , but depending on the scope of your work they can provide useful GIS and CAD interoperability.

Like an all-star team, sometimes you find CAD-based products that embed ESRI GIS functionality into their solutions. Bentley and Bentley’s /Haestad Methods have embedded ESRI ArcObjects inside there applications to extend their GIS and CAD Interoperability solutions. These tools provide the ability to edit modern ESRI geodatabases from within both AutoCAD and Microstation as well as a host of engineering applications within ArcGIS.

ESRI provides the ArcGIS Data Interoperability Extension which is based on Safe Software’s FME (Feature Manipulation Engine). This enabling technology is customized for ArcGIS in a way that it provides direct access as well as translation tools for over 70 different spatial data formats and variants not just CAD. In terms of CAD interoperability there is yet another important, but perhaps less visible player, the Open Design Alliance. This group provides CAD access technology that is used by Safe Software, Bentley and ESRI to read AutoCAD data.

Regarding the ArcGIS Data Interoperability Extension and ArcGIS core geoprocessing tools here is how I characterize the distinction for customers. Data Interop is not just for CAD, it has 65+ additional formats. It provides the means for both file translation and direct reading of the files, both with very explicit control over schema translation, even more granular than the core database tools of ArcGIS. It also provides the means to use this functionality on one or a collection of files. I think of one example where a customer used the ability to directly read a CAD file that, based on a set of rules, created inferred pipes on-the-fly. ArcGIS then could use these inferred pipes and perform queries and spatial analysis on these pipes even though they existed nowhere in the CAD file. Instead these pipes were created based on the current status of the CAD file at the time it is opened by ArcGIS according to the translation rules defined in the Data Interoperability Extension.

The core geoprocessing tools have the decided advantage of having full integration into the geoprocessing framework and interface. The results of Data Interop schema translation tools are also integrated into geoprocessing, but the schema translation building environment called Workbench has its own visual programming interface.

I personally prefer the elegant simplicity of the table driven functionality of the EXPORT TO CAD geoprocessing tool found in the core tools of ArcInfo. However, sometimes I need to use the power of the schema translation tools in the Data Interoperability Extension for more esoteric GIS to CAD translation tasks.

So join me in rooting on the team(s): "GO WARRIORS!", GO Tustin FUEGO!", "GO Tustin All-Star X-PLOSION!"

March 14, 2006

Domain Constraints from CAD Data

My two year old has reached a developmental mile stone; in the last two days she has learned how to climb out of her crib, overcome the child safety doorknob locks and manipulate the large front door. She used these three skills in combination with her existing ability (to use most any container as a stepping stool) to make a break for it yesterday down the sidewalk!

Today’s obvious topic is domain CONSTRAINTS! My daughter’s domain constraints have to be a safe area in her home free from the perils of automobile traffic, harmful chemicals and other normally harmless everyday objects that when placed in the hands of a two year old become life threatening.

In ArcGIS attribute domain constraints limit the valid values in a column to a discrete set or a range of values. One can use a table to help set the domain constraints in ArcGIS for the valid values in a column.

Today’s suggestion is to use the ArcView FREQENCY geoprocessing tool on CAD properties to get a table that I can use as the basis for my ArcGIS domain constraints. This is common when loading new CAD data into an ArcGIS feature class. If I have lots of AutoCAD blocks with ATTRIBUTES or Microstation TAGS and want to find all the values used in the drawing for a particular attribute TAG I can use the FREQUENCY tool to build a table of all the unique occurrences of a particular value. The resulting table will be the unique occurrences and their frequency (c0unt). Even if the values are coded as symbolic variances like COLOR or LINESTYLE at least I will know how many different kinds of features or values I am dealing with in any given CAD dataset.

As a secondary benefit to running the FREQENCY tool I may find values that I consider to be invalid for that attribute domain. In this way the FREQUENCY tool is useful for many types of quality control tasks.

March 06, 2006

GIS and CAD Interoperability: Archives

This Blog's Master Index

Here are some catagorized links to past posts.

You can still view past posts in the Archives for the Month they were posted. Help me if you find a dead link.

I'll do my best to make updates to the indexes.