Loading

Cultivating Spatial Intelligence

Site Modeling in Context

This web page serves as a hub for a set of tutorials related to three dimensional modeling of places as they are and how they might be changed. The term context in the title indicates the importance of modeling the surroundings of sites, but also to the context of the modeling enterprise -- which is almost always a collaborative effort that benefits from the exchange of information about places and about the processes of modeling and model exploitation.

Consider site modeling as the intertwining of two important threads. First, the ancient principles of topography that boil down to understanding the critical aspects of a place in context. And the new problems of representation that have a lot to do with understanding topography in the ancient sense but also a bunch of new lore about the lifecycle of data: from observation through modeling and argumentation. One of the most exciting and challenging aspects of the technology these days require us to understand workflows that involve strategic exchanges of data among a host of specialized tools. At the same time there is a history-of-technology dimension to it: as human beings are working out ways of sharing information that might (hopefully) lead to a societal infrastructure for building shared representations of the observed and the speculative landscape. The hope is that students will learn to create useful representations and also play a role in the greater evolutionary progression.

Work in Progress: This document is a work in progress. It may be a little rough here and there but it may still be worth taking a look at.

Demo Data & Tutorial

You may download a dataset and several documents that demonstrate the concepts discussed in this document, and connect to a nuts and bolts description of a workflow that starts with acquiring data, and some transformation and visualization in ArcMap, and exchange of information with CAD programs, and articulation of terrain using the RhinoTerrain plugin through the links provided below.


Modeling Goals

Our goal in these pages will be is to develop workflows for experimenting with the three dimensional form of landscapes. It is useful to get more specific about our goals since these will determine what things and relationships need to be represented and to what precision. SO we will define our goals for site modeling as follows:

Logical Connectivity with Surrounding Grades and Drainage: One of the important problems of site modeling is that the terrain of the site must connect logically with the terrain of the surrounding area. This is not only a hope that the terrain we design will not require retaining walls around its boundary, but also that our design will not disrupt the existing drainage patterns across and around the site. Often, students will get around this problem by stating thart the terrain of the site and the surroundings are flat. If this is true then the problem of logical connectivity is easier, however in nature no landscape stays flat for very long. Where drainage is not designed, nature will create it. IN areas that are draied through sewers, the designer should be aware of how water wil run off the site in the event of storms that overwhelm the artificial drainage system.

Logical Connection of Groundplan with Terrain: Groundplan in this case covers the distinct areas of a site and srroundings that are diferentiated in terms of material and use. This includes building foundations, roads, walkways, bridges and innundated areas, planting beds etc. These elements each has a special requirements for grading. And so the terrain model must be created with reference to the groundplan and vice-versa.

Views and Occlusion: A key aspect of a place and the way that people move over and around it. As an an observer approaches a site, parts of it become visible other parts are occluded. The way that the site design creates and blocks views as users approach or move through the site is one of the more sbtle and artful effects that a landscape architecct can create.

Need for Visualization: To evaluate the model we have to be able to use it. All of the requirements stated above can be accomplished wi5th pen and paper, or by cutting a physical model out of chipboard. We would like our models to be visualized in real-time 3d on a compute rscreen or sent to a computer Numerically Controoled Milling machine and/or a 3D printer. Note that this goal does not require us to create construction drawings that will be carried out with earth-moving equipment -- although this is something that we might hope to do if our visualizations and models can sell anyone on our site design!

Our desire to use the terrainmodel for milling reuires that we construct a surface that has no holes, rips or ruptures. The software that creates the milling instructions is sensitive to the number of faces. We should try to keep the number of faces in our terrain mesh lower than 10,000. Even for visualization, you will have problems with surfaces that have more faces than necessary. People often confuse the quality of a model with the number of vertices and faces. Actually, once we understand the modeling workflow we can learn to make models that perfom very well with surprisingly few faces. And nice streamlined models make each phase of the modeling and visualization process much more fluid!

Other: there are many other aspects of site design that we might consider in other tutorials. These include shadows and microclimate, soil stability and erodability and probably many others, but for now we will stick with the above.

Conceptual Model

The statements of goals made above can be reduced to a set of elements that we must consider in the site design problem. These elements include: Groundplan, Terrain, Vegetation and Buildings.

Model Extents

Our statement of goals helps us to be specirfc about the spatial domain of our model. How large should it be? One interpretation of our goals establishes that there the model may have three different extents: The Design Site os the area within which we can rearrange our conceptual elements. Within this extent our model must be precise enough to express and evaluate the changes that we intend to make with regard to the logical connection of groundplan and terrain grading, the buildings and vegetation. Beyond the site boundary there is the area that must connect locically with the edges of our site model -- the Site Surroundings. The terrain and groundplan site surround can be modeled with less precision that the site itself but the surroundings needs to be locically consistent with the site for visalization purposes and for considering local drainage patterns. Beyond the surrounding area there a broader area that includes the approaches to the site from which we may wish to understand how the site is seen, or those places that people may view from our site. The groundplan, terrain, buildings and vegetation in the site context area can be modeled with less precision that the surroundings but should have a good enough representaton of elevations so views are roughly revealed or blocked by hills as they would be in reality. We might be able to disregard vegetation in the surround and context, since vegetation may be removed or pruned. The three model extents nest within eachther. The design Site and the surround are each delimited by a three dimensional match ring that provides the precise three dimensional match l;ine wher ethe models come together.

Decomposing the model into the three extents discussed above provides us with a modular model structure that permits us to create a re-useable surround and context ring that provide a setting for any number of site alternatives that are limited in extent just to the extent of the site design. This modularization faclitates collaboration and comparison of a multitude of alternative site designs with a minimum of duplication of effort and a prcisely maintained frame for comparison of such things as estimated cut and fill volume.

A detailed workflow for creating georeferenced registration frames for your model is given Creating a Geo-Registration Frame and Groundplan Image

A Servicable Model

Now that we have Conceptualized our problem, we can set about to gather the information and tools that we need. The conceptual model of information needs and technical needs will give us a means of evaluating the results of different choices we make. Our goal is not to make the Best Possible Model it is to make a model that is adequate to service our goals. ANd it will be nice if this model and our tools are easy and fast to create and experiment with.


Groundplan Image

A logical place to start with a site design alternative is with a 2-dimensional ground plan. Ground plan includes, circulation, paved and planted areas, drainage and water-coverd areas -- and of course the logical relationships among these things. The groundplan may be created and modified using a vector-based tool AutoCAD or GIS or Illustrator, or you may use PhotoShop, or simply print out an ortho photo and use this as a base for a pencil sketches or even watercolors. One very useful thing to consider is to create a frame for your groundplan that can be used to register it in the various tools that you may use for other phases of your site design, such as Terrain Modeling or Visualization.


Groundplan Image with Registration Frame

Groundplan Strategies

It is useful to begin your groundplan with a georeferenced aerial photograph. When we start reworking the groudplan and the 3d terrain it is especially useful to have an image of your groundplan that can be draped onto your terrain model. IN the Elementary Sketchup/Google Earth workflow this is obtained via the Google Earth tools in Sketchup. The Google Earth snapshot does not have a vextor face around it, but this frame can be easily created. In ArcGIS, you would create a frame as a polygon, then you can export an image of your map as a georeferenced image This process saves a World File that is used to registert the image when it is opened again in arcGIS. If you alter the image or rename it, you can also rename a copy of the world file so that your altered groundplan image will also register correctly in ArcMap or ArcScene.

If you are using a vector editing tool for modifying your groundplan, export the ground plan image frame as a vector polygon to CAD which will provide the reference frame for re-registering the groundplan in your CAD editing tools. If you rework the image in photoshop or illustrator just stay within its extents and don;t change the size of the image. This way new versions of the image can be easily substituted in ArcMap (just rename copies of the .jgw and .aux.xml files), or in Sketchup (use the edit tools in the Materials window to swap the image., or Import the image as a texture and stretch it over a copy of your vecto image frame.


Modeling Terrain

IN our conceptualization of site, Terrain has several critical characteristics and roles.

Conceptual Model

Information Model for Terrain

A useful model for terrain will provide us with an efficient way to control the terrain surface that will allow us to affect the shape a in a predicatble way without excess effort. We often think of Contours as such a descriptive language -- yet it is more true that contours and drainange lines provide a very useful 2D visual portrayal of a terrain surface. There are common things that happen in sites that is very difficult to represent with contours. And not all contours are equally important. If a person tries to control the shape of a surface by manipulating a complete contour map. She will find herself spending 90 percent of her time fiddling with infomration that is actually of no consequense in determining the shape and performance of the surface. What is needed is a set of gestures that describe those critical places in the terrain where there are breaks in grade, peaks, ridges and valleys. Once we have interpolated our controls into a logical surface, we can us it to generate contours at any interval we need.

Terrain Controls Referencing Groundplan. Detail 1, Detail 2,

Interpolated Surface with Draped Groundplan Image. Detail With Edges

Another Detail. Detail 2 with edges.

To take a tour of this model yourself Download this file and open the docs/arcschene2.sxd document.

Constrined Delaunay Triangulation

Civil engineers have long understood an efficient conceptual vocabulary for describing and manipulating virtual terrain surfaces. This alphabet of Hard and Soft Breakines and Spot Elevations provides a very efficient means of indicating the citical aspects and relationships of a terrain surface. Understanding this efficient language of surface behavior provides us with a very effective way of creating and modifying terrain surfaces that we can evaluate. There are only a few tools that provide interfaces, interpolators and analytical tools that use this vocabulary.

Delaunay Triangulation is an algorithm for interpolating values between points. The Rhino Pointset Reconstruction tools perform delaunay trangulation using points alone. This works OK when you have a regular array of points. But when your point spacing is not regular, such as what you would get when you use the vertices of contours, odd thhings can happen, especially when the interpolator decides to connect points that are on oposite sides of a contour. This violates the logic of contours. The simplest sort of Constrained Interpolation takes the contour lines as constraints and prevents interpolation to happen across contours. While contours are always planar by definition, a good delaunay interoplator can also use 3d breaklines as constraints. The best Delaunay Interpolators can also allow for Hard and Soft Breaklines Here is a Nice page about delaunay interpolation from Spatial Techniques.

Interfaces for Terrain Modeling

There are seveal tools that facilitate authoring and modification of these efficient terrain descriptors. These tools also offer useful ways of visualizing and analyzing terrain surfaces -- though it should be noted, that for visusalization, there are often better tools that specialize in visualizing terrain surfaces. Therefore it is nice to be able to ecxhange terrain descriptors, or at least the resulting surfaces to different tools.

THe following are some popular tools for manipulating Masspoints and hard and soft breaklines:

Terrain Modeling Practice and Exercise

A terrain modeling process begins with assembling terrain data -- which is these days most often stored and distributed as rater elevation models. These need to be converted to our shorthand of masspoint and breakline gestures. See Obtaining and Transforming Elevation Data covers how to obtain terrain and groundplan information. Our Rhinoterrain Tutorial discusses how to transform existing terrain models into easy-to control, crisp terrain models for exploring and evaluating alternative future terrain scenarios in context. If you would rather use ArcGIS, see Terrain Modeling and analysis with ArcMap for another method and the demo database.

Storage and Exchange of Terrain Information

Another issue of using terrain that bears mention here is the idea that there are some tools that are useful for visualizing terrain, and others that are good for evaluatin it, and yet others that are good for authoring, and yet another class of tools that is good at storing, integrating and serving terrain information in a scalable way. One of the largest difficulties in modeling sites is exchanging data among all of these tools without losing important information. For example, the good authoring tools are often 3d editing tools like rhino or autocad, while the tools for accessing existing terrina infomation and for managing terrain data spanning multiple projects would be inb the GIS/Database category of tools. Tools that offer good viaualization of terrain, are usually 3d modeling tools that are not particularly good at authoring or storage. The current difficulty of exchanging terrain data between tools is a particularly interesting frontier in the evolution of human society. Thankfully this is an area that is changing fairly rapidly, with all sorts of interesting consequenses for people involved with asking and answering questions about places! There are a few notable projects to develop community standards for exchanging terrian information, include:

Case Study: Exchange of ESRI Terrain, Building and Groundplan Data with Sketchup

For years ArcMap was the onl;y decent tool for modeling terrain and it currently is the chief platform for integrating very large quantities of terrain and groundplan information, among other things. In particular, ArcMap provides a very good set of tools for assimilating and transforming terrain information, for digesting information in various forms and transforming it into streamlined descriptors and surfaces, expressed as Triangulated Irregular Networks, and for analyzing these surfaces in hundreds of useful ways.

While it is fairly easy to move the simple terrain descriptors out of ArcMap, it has been notoriously hard to get TINs out of arcmap! Until a few years ago when ESRI and AtLast software joined forces to make a plugin to exchange site information with Sketchup (later acquired by Google.) This plugin is certainly a welcome device, but the fact that it is somewhat flakey to install in some conditions, and its very existence depends on a very fragile social relationship between two competing mega-giant corporations, points out the need for a more reliable, community-standard means of exchanging data!

References:

The Idea of Model Views, Versus Manuscript

SketchUp, simple as it is offers many powerful ways of investigating, experimenting and creating useful visualizations concerning terrain and its key relationshipos with groundplan, buildings and vegetation. Unlike most other tools of this sort, sketchup combines modeling capabilities and rendering and animation facilities in one easy package (with georeferncing!.) However Sketchup is really terrible as an interface for authoring and modifying our vocabulary of key terrain descriptors. While you can modify a the terrain surface in sketchup, and this can be useful for quick experiments, one must not spend too much work doing this, since the edits made to the TIN are not going to be reflected in the manuscript for terrain, which in our case, remains in ArcMap. When we want to cut contours out of our surface at a specific interval for laser cutting, or measure the amount of fill needed, we will need to have our modifcations reflected in our TIN in arcmap. Furthermore, since Sketchup does not enforce the logic of TIN models, we will discover that surfaces that have been modified in sketchup may have rips or twists that will freak out many of the tools that we may want to use on the surface later (such as masterCAM, an essential step in the creation of milled models. There are many situations that arise as one moves through a multi-tool workflow where one needs to keep in mind that some aspect of the model one is working with should be regarded as a view of a model component that lives and needs to be managed in its Manuscript form that resides in another tool. A useful concept for understanding when this is the case is whether or not the information exported from one tool to another can make the Round Trip back, and and be functionally identical with the original.

Visualization Through Physical Models

Virtual models are very quick and fun to play with. A great thing about them, is that we can put ourselves into the model very easily, and to take others on tours of critical aspects of our site, by creating animations. Movement is usually a very important part of understanding the spatial nuances of a place. Another great thing we can do with our virtual terrain is to use it to create physical models. At the GSD, we make lots of Chipboard models using the laser cutter, and we can be happy that our terran surfaces can be automatically sliced into contours of any interval we choose. A good Chip model can also convery complex groundplan infomation at the same time -- the trees and buildings are a bit more difficult. We also make models on the Computer Numericaly Controlled Milling Machine..

For an easy and reliable CNC milling workflow, we can transfer our buildings and our terrain out of Acrmap as a sketchup file, and into rhino, which can export an IGES file to Mastercam, a tool that can transfer our terrain into into a language that the Milling tool understands. See this tutorial

Physical models are a great example of a Model View of our data model. We might consider the possibility of creating new scenarios on this view, say, by adding clay and things to the model. We might even be able to round trip this information back into the digital world by use of a 3d scanner, but this would be the beginning of failrly a complicated process akin to that of surveying and photogrammetry, which is how our real site information makes its way into GIS at the very beginning of its lifecycle. I would not expect this round trip to be an easy process at first!!!


Buildings and Structures

Buildings and structures are an important part of many landscapes. It is possible to make very complex conceptual and data models of buildings that answer a lot of very complex questions. YOu can takle a look at the standards efforts in Building Information Modeling by the (IFC Standard), or the simplere building models incorporated into the CityGML standard of the Open Geospatal Consortium.

In our conceptualization of Site, buildings are important for the way they relate with Terrain and intermediate visual connections within, across, out of, and to our site. For more information on visual site studies, seeStudying Urban View Corridors. For a simple demonstration of a very useful data model for buildings, we will consider Sketchup's PhotoMatch capability for buildings. It is very interssting to see how well this tool embodies the concepts of the apearance Model on page 36 of the CityGML spec!

Here is a demo dataset that will let us demonstrate the great Photogrammetry Capabilities of Sketchup .

We would be remis if we did not mention some important connections here. First, through the agency of a community standard (COLLADA for exchanging georeferenced, texture-mapped 3d objects, such as the ones created by Sketchup, vast databases of these models can be organized and shared in very large collections, such as 3d Warehouse. These models can be discovered and compiled using Google Earth. It is also interesting that ArcGIS can also manage infinitely large collections of these these models.


Trees and Vegetation

By now we are used to the idea that site modeling always means strategic exchanges of information among diverse tools. With Vegetation it is more of the same! In our demo we will use some of the wonderful vegetation capabilitires of Onyx Garden Software developed by GSD Grad, Dr. Bojana Bosanac and her husband, Pier.. Onyx Garden can model a vast herbarium of different plants, and does a great job of modeling the temporal changes that plants go through, seasonally and as they age. This is very exciting. The software also is capable of making representations of the same plant in various forms, including images, and 3d files at user-defined levels of detail. Note how this is similar to what is included in the cityGML spec on pages 85 and 86.

In our in class workshop we will explore how we can use the Sketchup Schema of layers and object hierarchies to model trees in all of their tempotral splendor and levels of detail!

Download demo dataset here.

Resources