Planning, maintaining and protecting cities requires an infrastructure of information. GIS has become an essential piece of this infrastructure, but in most cities the information infrastructure does not yet adequately represent the fullness of important three-dimensional aspects of the city, such as: How many sqare feet of commercial/office/housing might be affected by an emergency in a given area? What windows have views of a particular spot? How will a design proposal affect views and shadows in an urban scene?
A vast amount of three dimensional urban data will soon become available as cities take advantage of LIDAR and other three-dimensional imaging technology to record detailed height information. These relatively crude models will beg to be augmented with real CAD details. How will this CAD data be incorporated into urban information infrastructure?
Above, 500,000 three-dimensional faces stored in SDE.
Boston, Massachusetts is the focus of two large infrastructure projects: The Central Artery Tunnel (CAT) Project which relocates 8 miles of higwhay in the core of the city into a tunnel is one of the largest infrastructure and urban design projects in U.S. History. Boston has also been picked by the Federal Emergency Management Agency (FEMA) as one of several cities to demonstrate the use of a coordinated metropolitan three-dimensional GIS.
Both the FEMA and CAT projects will benefit from a multi-purpose, multi-user, three dimensional representation of the city. The complexity and the dynamic nature of the detail will require that this system facilitate editing of the data by multiple people in different locations. In the case of the FEMA metropolitan database, responsibility for mmaintaining the data will be distributed accross several jurisdictions. In the aftermath of the CAT project, scores of urban design teams will benefit from access to a modeling infrastructure that provides a consistent model of the urban context, and a system for examining the relationships among independent design proposals.
The most successful architectures that provide distributed management of complex data models are provided by enterprise- scale repational database management systems, such as Oracle, Sybase, POSTGRES and Microsoft SQL. These systems began with storage of aplpha-numeric data. Recently, these architectures have been augmented with the ability to store data types representing three-dimensional objects and relationships, yet no GIS yet offers practical tools for generating or editing real three dimensional details such are found in the built environment.
Data models for editing and managing three-dimensional information have largely been the province of specialized computer aided design (CAD) tools used by engineers and architects. CAD models for data management are file-based. Strategies for managing very large quantities of detail involve clever use of the file system to store multiple, inter-referenced files cataloged by file name. CAD vendors have begun to utilize enterprise databases for the storage of attribute information for objects, but to date, none have engaged enterprise models for the storage and management of geometry.
To bridge the gaps between GIS, enterprise data management systems amd CAD, Environmental Systems Rsearch Institute (Esri) has developed a CAD Client for its Spatial Data Engine (SDE). SDE is a GIS component for several enterprise database management systems. CAD Client is the interface that permits access of GIS data through CAD programs, and the storage of CAD objects in the GIS database. This combination provides a facility for managing virtually unlimited amounts of detail representing most any aspect of the built environmemnt for entire cities, along with different future or past scenarios; all in an architecture that would permit distributed access for reading and writing.
Although the CAD Client architecture has potential to support the development and deployment of the sorts of models envisioned by FEMA or Boston's urban design community, there are still many problems that need to be worked out:
There is little doubt that these problems will be solved in the next few years; the importance of having true three dimensional models for urban areas, and the coming bonanza of massive quantities detailed true three-dimensional data will require it. The remainder of this paper will discuss each of these general problems, and sodme ideas and tools developed at the Harvard Graduate School of Design.
After experiencing trouble loading the 3d faces for a building using SDE8.1 and CAD Client version 2, we discovered a pattern: faces with vertical edges are weeded out by SDE's input filter.
These illustrations show a partially-successful upload of faces from AutoCAD to SDE. 630 of 3359 faces are rejected as unsupported features.
Below, we see the successfully loaded faces:
A discussion with members of the CADClient product group established the idea the this behavior is a feature not a bug. Because there are many spatial operations such as polygon overlay that do not work with vertical features, these features are not allowed in the database at all.
Oddly enough, vbertical features can be uploaded to a personal geodatabase, using ArcToolBox, but not CAD Client. Below, we see the same geometry afte having been exported from AutoCAD as DXF and uploaded to a personal geodatabase.
The image above illustrates a few worthwhile points: ArcScene does a decent job rendiring real three dimensional detail, and the basic relational operations of a geodatabase are capable of storing relationships between building skins, floors, rooms, windows, etc. There are plenty of useful models that can be produced with vretical objects despite the fact that ArcGIS is not yet a fully functioning 3d GIS.
We should expect Esri to eliminate the somewhat arbitrary vertical edge exclusion in version 8.2.1 of SDE. In order to work in the meantime, we created a VBA program for AutoCAD which finds an appropriate axis of the selected building faces, and rotates them all by .01 degree. This fixes the vertical problem for all but very short faces. The vba tools that we have created are available for download from http://www.gsd.harvard.edu/pbcote/tools/cadclient/cctools.htm.
There are many activities one can easily expect to be in a workflow that takes advantage of interchange geometry and attributes between CAD and GIS. One quickly runs into problems that are not accomodated by functions of the CAD Client user interface. A case in point is the alteration of CAD attributes based on attributes in the GIS data. When creating a geodatabase from CAD data, Attributes that are part of the basic AutoCAD data model, such as LAYER, ELEVATION, COLOR, and THICKNESS become attributes in the GIS attribute table for SDE proxy objects associated with each CAD entity. However, the CAD objects do not react to changes in the values of these attributes if they are changed in ArcGIS. Likewise, if we are using CAD Client to download native ArcGIS geometry, there is no easy function that permits us to exploit GIS attributes to influence the layername or elevation of the CAD object.
Fortunately the application programmer interface for CAD Client is very functional, so we are in the process of creating buttons for CAD Client to do these important tasks:
Functions such as these will be necessary to assit in making SDE data models as functional as we need them on the CAD side. These experimental tools can be downloaded from http://www.gsd.harvard.edu/pbcote/tools/cadclient/cctools.htm.
The next step in planning for implementation of urban models in GIS, is to design the arrangements of tables attributes and relationships. Extending GIS data models to three dimensions and being interoperable with CAD introduces several interesting problems:
Associating Primitive Shape Objects to Represent Buildings An SDE feature class can include points, lines or polygons. A representation of a building may be composed of many of these pieces. Relationships such as "the windows, associated with hotel rooms, that have a view of the natural gas tanker" is one example of information that may be desired from a good urban data model.
Data Models Interoperable Between GIS and CAD Ideally, a distributed representation of the city would be accessible easily accessible for editing through CAD. This means that the data models built for SDE would have also to consider aspects of the CAD working environment, such as layers, blocks, etc.
Modular, Interoperable Terrain The ground plane in urban environments can be very complex, and important. For understanding urban design scenarios, models of the ground must be much better than your typical digital elevation model. We would like to have a means of storing terrain models in SDE such that small, highly detailed terrain models can be nested inside more generalized models. Ideally, parts of this model could be checked out by urban designers, edited in CAD, and checked back, in such a way that avoids gaps at the edges. We envision a system of nested modules having breaklines on street center lines.
There are important reasons to build broad-scale three-dimensional models of cities. The problem of data generation has now been overcome with technology such as LIDAR. What is left is to understand how all of these data can be organized, accessed and maintained.