ArcGIS for AutoCAD at the ESRI 2009 Developer Summit
Recently my high school teammates met to play one last game in our old school’s gymnasium that is slated for demolition. Although I was not able to attend the festivities I was there in spirit. I have been reliving a lot of my high school basketball years while coaching my daughter’s teams after a long sabbatical from basketball. I have really enjoyed revisiting these memories and sharing new ones with my daughter.When I first started working in the realm of GIS and CAD interoperability I was very busy coding in AutoLISP to build sample applications for ArcCAD (ESRI's retired AutoCAD-based mapping software.) I now find myself revisiting some of those familiar experiences with the new API’s for ArcGIS for AutoCAD. Although I can use other development environments inside AutoCAD to manipulate the AutoCAD file according to the Mapping Specification for AutoCAD, the ArcGIS for AutoCAD build 200 application ships with an AutoLISP API to accomplish many of the things I want to automate with both ArcGIS Server map services and feature class information in ArcGIS for AutoCAD, and accomplishes it in the comfortable and non-threatening AutoLISP framework.
There are a couple of sessions at ESRI’s 2009 Developer Summit that will be addressing customizing ArcGIS for AutoCAD and working with ArcGIS desktop and Server applications with a CAD focus March 23-26 in Palm Springs, CA. I hope to see you there.
posted by Don Kuehne at 1:47 PM
2 Comments:
Hi Don,
I need some advise. I busy deciding on my Masters Thesis topic as part of my Masters in GIScience. I'm a GIS manager for a Civil Engineering firm called Aurecon. We were just recently merged from three firms (Ninham Shand, Connell Wagner and Africon). I'm interested in doing my thesis on CAD and GIS and the ability to access spatial information between both environments without the need to convert our data into proprietory formats on a continual basis. Is there enough literature and could you advise me how to approach this.
Peter,
I am not sure what type of literature you need to support your thesis, but I might say there is too much and too little. The topic is rather esoteric albeit it is my life's work. There are some really good reasons why GIS and CAD data are different. There are also some good reasons to at least attempt to make them conform.
My advice to you is to carefully consider the premise of your thesis and literature you read, to sift out the marketing-speak. Certain technical words for example can be tainted and loaded by marketing speak, which can distract from the actual issues. Proprietary for example doesn't necessarily speak to the issue of accessibility. A GIF file is a proprietary format, but the ability to access data in this format is pervasive and not a hindrance to access, accept when you look at software access and licensing issues. You will need to be careful to distinguish between different types of spatial information and data systems and their designed purposes.
The abstraction you use to encode reality may be better suited for one data format or another. GIS data and CAD data are not different because they are necessarily different approaches to the same problem. They are technologies designed to solve different problems, but can also be extended to cross into each other’s domain. Both GIS and CAD have multiple data constructs that can be chosen by the user to encode reality. The different data structures are optimized to enable applications to solve certain problems. The problem definitions should come first. Next a data structure is created to capture and store the required data to fuel the application, anything more is inefficient (slow, complex ...bad). To ignore the purpose for the creation of the data, or to attempt to solve all problems with a single data structure is impractical. It is in the balance of application needs and efficient abstraction that the issue of GIS and CAD interoperability is couched.
Using design data for construction is possible, but not all the design information is needed for construction. Likewise there are many details needed for construction that would be burdensome for the designer to add. A single data construct that can accommodate both design and construction data may be too burdensome to be used for both. In each phase of the cycle the same issues are repeated again and again all with their own special twist. Construction to As-Built, As-Built to Maintenance, Maintenance to Operations, Operations to Planning, Planning to Design and all over again.
Ignoring the fact that most of the data can be re-purposed would be wasteful. Again there is a balancing act, should the data store have a superset of all of reality to support every and all uses, or does the data need to be converted, reinterpreted or enhanced from one application to another.
The real challenge is not the data format, there is a bigger problem. Abstraction and application is the real issue. You could choose to support the lowest common denominator in which case your data is dumb and not optimized for any application, but it is simple. The problems you can solve are limited. Or, you can attempt to create a universal data model, in which case you must recreate reality to the sub-atomic level, which is impractical (non-optimized, slow, complex… bad). To the extent that you can define a "middle ground" you must accept the self-imposed compromises. The solution is more likely workflow, standards and clever repurposing of data with well defined interchange standards and practices.
There, my life's work.
-don
Post a Comment
<< Home