Archive for the 'Scale Issues' Category

Nov 19 2008

Immersive 3D article in BAAMA Journal – GIS in OpenSim and Second Life

The San Francisco Bay Area Automated Mapping Association is our local URISA chapter, and publishes a twice-yearly journal that covers some interesting local geospatial projects.  The latest,  BAAMA Journal Volume 2, Issue 2 was released today for GIS Day.  It contains one article that provides an overview of the work blogged here: “IMMERSIVE 3D SIMULATOR-BASED GIS: SHARING THE 3D EXPERIENCEThe shot below details Mulford Hall on the UC Berkeley campus where our local GIS Day event was held again this year.  Thanks to the GIF, ASPRS, and BAAMA organizers!

Detail of 1:16 Level 2 model, in Second Life Agni grid, Amida region, on 2008 11 19 GIS Day

Detail of 1:16 Level 2 model, in Second Life Agni grid, Amida region, on 2008 11 19 GIS Day

No responses yet

Oct 30 2008

GIS Day Video of Miniature OpenSim Builds in Second Life

One thing about these tiny builds is that they’re easy to see from one end to the other, so why not make a video of these miniature builds in Second Life?  I offer this for the amusement of Geospatial Information Service (or Geographic Information Systems if you prefer) folks who may be introducing themselves to immersive 3D.  International GIS Day will be here in a couple of weeks, so I’m posting this now.

 I’ve also challenged myself to improve my video production standards.  Who knows, maybe more than 1300 people will view it if I make it more fun to watch with a bit of editing and title-based metadata?  Nothing deep is intended with the score, it just caught my attention as matching the length of the machinima rushes tonight.

I’ve tried to improve the video with some titles to explain what’s being seen at the Level 1 (bare earth with draped ortho) 1:42-scale build, Level 2 (first-return reflective LiDAR gridded surface with draped ortho) 1:16-scale build, and Level 3 (full immersive 3D vector features in Second Life primitives with real world textures) 1:3-scale build.

If the embedded link does not work, the video is hereколи под наем which is at

One response so far

Oct 28 2008

Glimpses of Berkurodam in Second Life for GIS Day

The 10th annual GIS day is arriving on 2008 11 19, and an article on the techniques that I’ve been blogging may be published on that day. In anticipation of that article, I’ve taken some time to upload selected strips of the Open Berkurodam model that has been built at 1:1.024 scale on 40 OpenSim simulator regions to Second Life. In that way, many more people may find this work and take a closer look.

In the article are three terms I’m suggesting be used for work that involves translation of GIS data into immersive 3D simulator environments: Level 1 build, Level 2 build, and Level 3 build. Level 1 is like Google Earth or MS Virtual Earth, basically bare earth gridded terrain with draped orthoimagery. Level 2 is what I’ve got as a placeholder in the Open Berkurodam 40-region 1:1-scale build, with a reflective LiDAR gridded surface draped with orthoimagery. Level 3 is just standard immersive 3D vector features that fill so much of Second Life, but in the special case of an immersive 3D build based on GIS-grade scaled mapping of building exteriors and possibly interiors.

The Level 3 build was what inspired my efforts starting back in October 2006 (Darb Dabney just has his second Rez-day celebration), but the Level 2 seems like the most important one for actual civic builds, because the grid of LiDAR data brings full-scale, full coverage data to hold the place and fill the mass of both buildings and trees, until one can afford to create the Level 3 build.

So now at the SIMGIS land in Stanford, there is both a Level 1 model (bare earth terrain with draped orthoimagery) of the entire 40-region sim at a reduced 1:42 scale, as well as a Level 2 model (gridded LiDAR first-return surface with draped orthoimagery) from the Berkeley BART station up Center Street, and on to the UC Berkeley Campus at Mulford Hall at a reduced 1:16 scale. It’s fun to see these tiny models, and it helps to convey some of the value that OpenSim offers those of us who would publish entire cities. A copy of these two models has also been placed in Amida, just across the channel from Gualala.

My selection of that path between BART and Mulford Hall was made to offer an entertaining Level 2 swath for those who would be taking transit to an ASPRS – BAAMA – GIF GIS Day event.

First the view in Second Life from Amida toward Gualala, with my Level 1 (1:42 scale), Level 2 (1:16 scale), and Level 3 (1:3 scale) (full immersive vector features with interiors) models of the downtown Berkkeley BART area. Second is the view of the SIMGIS Stanford site, with the same Level 1 (1/42-scale) and Level 2 (1/16-scale) builds.

Level 1 (1/42 scale) at base, Level 2 (1/16 scale) and Level 3 (1/3 scale) in distance

Level 1 (1/42 scale) at base, Level 2 (1/16 scale) and Level 3 (1/3 scale) in distanceAnd here's a view of the new SIMGIS Stanford region site, as viewed from Hawthorne region. The Level 1 model 1/42-scale is just above the water, and the Level 2 model 1/16-scale is above it.

Level 1 (1/42-scale) above water, and Level 2 (1/16-scale) above that.

Level 1 (1/42-scale) above water, and Level 2 (1/16-scale) above that.

No responses yet

Sep 11 2008

Case Study: USGS terrain in OpenSim, a GIS approach

ABSTRACT: When creating sims based on real-world terrain, there’s usually a lot more extent and detail available than is typical when one must hand craft every region landscape. When compared with commercial multi-user virtual environment (MUVE) hosting, OpenSim has extremely low marginal cost for adding more simulator regions. Whenever a real-world region of interest has free 1/3 arc-second DEM data available for download from the USGS seamless server, then with a bit of GIS help from someone at a local university or interested government office, the free DEM data can be converted to a fine 1/10 (1:10) scale sim of terrain in OpenSim. This case study takes an idea posted to a blog, and turns it into a sim of 54-regions in OpenSim based on real-world terrain available at a 10-meter posting interval. To run all the regions, one first obtains OpenSim, then downloads the 54 terrain tiles, the 54 region definition XML files, and a loader script available from this post. The region definition files will likely need to be regenerated with the supplied PHP script to point to your machine’s IP address.

The Case Study tour video is nearly 10 minutes, and if it doesn’t embed in your browser is here at

Two days ago I was intrigued by Brian White’s posting of a Tutorial for real-world terrain in OpenSim and I followed several of his well-documented steps. Then I read all the way to the end of his posting and realized that he wasn’t fully satisfied with the results. I’ve helped a couple of folks with generating specific terrains before, and Orcas looked like an intriguing bit of topography–sort of a miniature version of how I imagine Greenland might look in, say, a couple decades…

So without an intent to cross-talk Brian’s posting, I’ll offer my own parallel perspective on how I’d approach making a recognizable, maybe even fun-to-have-around model of the Orcas Island in OpenSim. Starting from where he did, I’d like to emphasize the profound opportunities for following this approach, as it would work virtually anywhere in the continental USA (CONUS) where the 1/3 arc second seamless DEM is pretty much complete. In other words, what I’ll show here could be applied in an hour or so’s effort to produce an OpenSim version of Yosemite Valley, for example.

First, choose thy locale. The USGS seamless server is a worldwide resource, but the greatest detail available seems to be in the “lower 48” states. A digital elevation model (DEM) with postings on 1/3 arc second interval has samples about every 10 meters in Y (north-south) and more closely spaced than that in X (east-west) everywhere off the equator. The 1/9 arc second data that Brian mentioned was actually not available for Orcas, although some urban areas may have it at this time. In this case, Orcas Island offers a nominal 10-meter DEM downloadable from server.

Second, define thy scale for the sim. If one will be hosting on a commercial sim, even like Linden’s Open Space sims in Second Life’s Agni grid, then there are very strong reasons to scale things down and perhaps pack everything into a single region or four. With OpenSim, unless you’re going to have tons of prims and game-grade dynamics running, it may be possible to balance the number of regions you set up with the terrain quality that you desire. For the Orcas, I downloaded the islands (using the default format which seemed to be an ESRI GRID) and explored them in ESRI ArcGIS. With that I had the sense that I wanted more or less 24 km in X, and 16 km in Y, to cover the Orcas. Since OpenSim allows me to load floating-point terrain samples on a 1 meter posting interval, I knew that my available (1/3 arc second) DEM would support a 1/10-scale sim, analogous to a 1:10 scale map. That way, I would not discard too much of the terrain information on its way into OpenSim.

Third, do the math to tile the regions. It’s not too hard, but it’s fairly unforgiving. After a bit more ArcGIS exploration, I found a way to crop the DEM to exactly 23.04 km in X, and 15.36 km in Y. Sounds wierd, or compulsively precise? Not really. Since each of my terrain samples was planned to be on a 10-meter grid interval in real-world, and my sim scale is 1/10, that means that every region would cover a 2560-meter square, or 2.56 km on a side. The dimensions that I chose were simply six regions north-south and nine regions east-west, for a total of 54 regions of 1:10 scale sim.

Fourth, get your DEM gridded. Sure, it comes from USGS that way, but the seamless server works world-wide, and that requires a geographic (Longitude / Latitude) way of defining its coordinates. To do this rigorously, I used Geographic Information Systems (GIS) software to re-project the DEM from geographic, the way it downloaded, into a projected grid [World Geodetic System 1984 (WGS84) datum, Universal Transverse Mercator (UTM) zone 10 north projection, with distances measured in meters]. The UTM grid system is defined world-wide, with the proviso that at any given spot, only one of the sixty (60) grids in the system would be the best choice. For the Orcas, it’s zone 10. For the reprojection process, I used a remote sensing package, Leica ERDAS Imagine that provides precise control over both the reprojection and the resulting data’s sampling interval. I used ERDAS Imagine to grid the UTM-projected DEM into a Cartesian grid of 10-meter interval in both X and Y, and cropped the projected data to 2304 by 1536 samples.

Fifth, dice the DEM. This is necessary for multi-region sims where your grid has more than (and exact multiples of) 256 samples in X or Y. ERDAS Imagine dices, so i used it. If you’re trying this in Photoshop, be sure to keep the pixels in 32-bit (single precision) floating point values, and don’t go to integer grayscale or the flatter terrain will get stair-step artifacts. The naming convention used in ERDAS Imagine starts at the top row and increases downward for Y, and also puts Y first then X in the tile name so that the south-westernmost of the 54 regions is called “orca_6_1”

Sixth, reflect each diced DEM tile, this reverses the direction of samples in Y dimension. What starts out as the top, northernmost row is moved into the bottom-most position, and vice-versa. This does not change the size of the tile, nor any of the gridded elevation values themselves. Another way to describe this is to flip the image around the X axis. ERDAS Imagine has a geometric correction function that allows one to specify this as an affine mapping, which I did. I’d expect that most of the world uses GIMP or Photoshop to do this, too. Although it would appear that this will scramble the terrain, it is necessary to do this to adapt the data to the sequence in which OpenSim reads the terrain file when loading it into the region.

Seventh, export the reflected DEM tiles to f32 raw binary. After trial and error, I found that using IEEE 32-bit single precision float with Motorola “swapped” byte order works for OpenSim. This is true even though my machines (both Windows and Ubuntu) are running Intel processors. Go figure.

Eighth, place the f32 terrain tiles in a directory within OpenSim’s ./bin for easiest referencing in the region definitions. For this case, I have prepared 54 tiles for Orcas that can be downloaded, unzipped, and placed in ./bin

Ninth, create the appropriate region definition XML files in OpenSim’s ./bin/Regions directory. Long before one gets up to 54 terrains, it makes sense to have a bit of code to help this process. I started modifying a sample provided with OpenSim a while ago, and include it, along with 54 region files for Orcas that can be downloaded, unzipped and used to replace your Regions directory.

Tenth, create a command script to load the terrain once your 54 regions are running. I include such a script that can be downloaded and invoked from the OpenSim console with “command-script terrain54.txt”.

Et Voila: A 10-minute tour of most of the sim has been recorded and is being uploaded to YouTube

No responses yet

Aug 28 2008

OpenSim Screen Shots – An OpenBerkurodam-40 Deluge

I took a bit of a rest after the ESRI International User Conference (actually, it was more like catching up with real work). Sadly, I missed out on the call for images by Adam, and I can’t even blame it on there being so many time zones between here and Perth.;^)

So in the interest of sharing stuff in bulk, please accept the following pile of shots. All of them were made from the 40-region OpenBerkurodam (OB40) model that has been taking shape over the past few months. All of them are from the 1.024:1 scale model of the UC Berkeley campus and adjacent downtown environs that have been built (precisely 2.5 square km. worth).

Unlike the attractively detailed SketchUp models one finds for selected UC Berkeley buildings in Google Earth, the OB40 sim has every building, every moderately large tree, a lot of light poles, and even a construction crane imaged in 3D. This was because it was built wholesale with reflective LiDAR data. Lots of data, and very little artistic craft!

The resulting mismatch between the LiDAR bump-map surfaces and the 10-cm natural color orthoimagery that I have draped over them create an effect that is quick, dirty, and very complete. At first glance, one might think that we can’t decide where we are–on the continuum between representational and surrealistic art, or that perhaps the trees have not lichen, but a rather different kind of fungus affecting them. Hey, I’m just saying…

The OB40 model was demonstrated live on two and three higher-end laptops running the standard Second Life client; they had NVIDIA Quadro graphics cards and they did OK. The sculpties imaged a little bit differently than they do with fully approved graphics cards but the client never crashed outright.

Some senior ESRI system folks got a look and a see of what OpenSim was about with GIS data loaded into it. Several public safety people expressed some interest in the possibilities. The presentation was not at a booth, but rather in a corner of the showroom floor given to the “User Applications Fair” that was a spot for about 32 non-commercial folks to show their stuff. Strictly speaking, the ESRI software was not the application on display, but without the ESRI (and ERDAS) software, I wouldn’t have been able to get my GIS data loaded into OpenSim in time for the conference.

What sort of shocked me in terms of response was a huge non-linearity in acceptance based on the age of the person viewing the demonstration. At one point, I was describing some obscure details with an experienced GIS person, and within 15 seconds, a group of three teen-aged 4H Club members (I’d seen them in another part of the conference) sat themselves down without questions or introductions and began going all over the place 3X. They had no questions about the SL client interface, the purpose of the OB40 sim, or any of that. They just sat down and started exploring.

For me, the experience of seeing the 4H kids using OB40 intuitively provided great hope that some day not too far off, people will just accept a Multi-User Virtual Environment (MUVE) as readily as I would read a map from the American Automobile Association (AAA). I mean, for me there’s some effort involved in using the SL client, although at this point it is about as familiar to my hands as the ‘vi’ editor is—I just use it, kind of like reading a book without mouthing the words. But for the younger people who interacted with OpenSim, the interface did not seem hardly present for them, they focused at once on the content and enjoyed it for just the fun.

OK, enough blather – I’ll try and share all the shots, including some that did not make it to San Diego. The actual date for all of the shots was 20080731.
Shattuck Ave and Center Street in Berkeley, view westerly

This is downtown Berkeley, the BART station, same area that has been modeled at 1:3 scale in Second Life Agni grid, Gualala region. In Gualala, everything has been built in detail by hand, with custom real-world texture shots. In OB40, the scale is nominally 1:1, but at the moment only a LiDAR drape fills the region (and 39 adjacent regions, too.) There is an avatar above the Power Bar building, the tower on the left.

Pictometry-style shot of Civic Center

This is synthetic “MS Virtual Earth” or Pictometry high-angle view of the Martin Luther King Jr. Civic Center building, Berkeley’s city hall. There is an avatar on the near-left side of the roof, enjoying a brown-bag lunch.

Shattuck Ave and Hearst St, view Swly

This is Shattuck Ave and Hearst St, view SWly. Oscar’s hamburger grill is on the right with all the ducting on the roof.

Berkeley Arts Magnet school

View Wly across Shattuck Ave toward the Berkeley Arts Magnet school campus.

Farms in Berkeley

View toward Oxford St, near sunrise. Strawberry fields in foreground.

Farms In Berkeley?  You bet!

Farms in Berkeley? Indeed, this strawberry field was imaged on 2006 07 01 just a couple of blocks from the UC campus. View SEly near sunrise.

View up Hearst toward Euclid

View uphill on Hearst St towards Euclid, northerly side of UC Berkeley campus. TECHNICAL DETAIL: in the far distance toward sunrise, there are huge eggs floating above the ground, but textured with the orthoimagery. These are the LiDAR megaprims after they have received their photo texture, but before they have rezzed with their bump map. Depending on bandwidth, how much of the model the client may have already visited and cached, and the phase of the (virtual) moon, it might take anywhere from 15 seconds to a minute or two for the bump maps to fully rez out when one arrives near a region. When shooting these pictures, and typically in OB40, I keep the SL client viewing out 512 meters with “ultra” quality graphcs.

LBNL synchotron view Ely

Above the top of Hearst, the Lawrence Berkeley National Laboratory (LBNL) sychotron and nearby buildings, view Ely, including some really large Blue Gum (eucalyptus) trees.

Foothill student residences, view Sly

Below LBNL, the Foothill student residences, with Sather Tower in view, far right

The UC Berkeley Greek Theater, view Ely

The UC Berkeley Greek Theater, site of a great many fine performances over many decades, view Ely, and just Sly of the Foothill residences.

UC Berkeley International House, and California Memorial Stadium

View NEly, of UC Berkeley’s International House, with California Memorial Stadium in background. Avatar is hovering over the cupola of the I-House, sneaking a free look at the football scrimmage (or is it cheerleader camp?) 2006 07 01

View Nly up Piedmont toward I-House

View Nly up Piedmont Ave, in the Greek housing section of campus. View toward International House with California Memorial Stadium in background. Horizontal scale 1.024:1, vertical scale 1:1; those trees have scaled height and bulk thanks to LiDAR first return gridding.

View Wly of UC Berkeley campus near Wurster Hall

UC Berkeley main campus near Bancroft and Piedmont. Large red-roofed building in mid left frame is Boalt Hall, lighter building in right mid-far range is Wurster hall, home of the Urban Planning folks. Here’s looking at you, kids!

Long shot Enely of Sather Tower

Finally, UC Berkeley campus toward LBNL, long shot near Sather Tower. All these shots were from the OB40 sim, sometimes running on

No responses yet

Apr 29 2008

Megaprim terrain ’til the cows come home

Published by under BART Station,OpenSim,Scale Issues

There has been a bit of head scratching as other distractions apparently clouded an obvious scale issue. The first terrain megaprim sculptie project done last month, had available imagery at 30cm.  For that, it only made sense to oversample to 25cm to make 512×512 textures.  That decision led to my adding a collar around the original 512’s until they clicked into the proper size without rescaling on a quarter-region megaprim. With Berkeley, the source imagery is almost 10cm (103mm pixels) and the challenge has been to size the resample so as to make best use of the 1024×1024 texture size limit per prim.

Where I took a wrong turn was trying to proportion the collar that was added to the 512’s, rather than going back to basic principles with sculpties. Bottom line: my efforts of the past week went astray as I allowed confusion to set in, casting about for the proper maximum texture dimensions working down from 1024. (and I’ve got the awkward attempts at 1008, 994, and 978 pixels to prove it).

In fact, the answer is very simple in reference to basic sculptie principles, as the maximum dimensions of the sculptie bumpmap are 32×32, and due to the need to wrap it around to an apex underneath, this can only represent a 30×30 terrain patch. Thus, the maximum imageable area is simply (30/32)*1024, or 960 pixels square, collared out to 1024 square to make each orthophoto tile. This means that an OpenSim 1.024:1 model can accomodate 130mm orthophoto imagery, and I now have 160 tiles ready to go with the bumpmaps.

So far I’ve configured twelve regions with their megaprims, and only one seems to have issues with the height of the sculptie to stay 30cm afloat the terrain surface. Nine of these reigons use the flattest setting, one uses the intermediate, and two use the steepest. Here’s some shots for update’s sake. The full set of orthophoto textures have been uploaded (450 MB of Targa files) and seem to show up reasonably well in inventory. I am using a local MySQL instance on the OpenSim machine for prim storage.

OpenSim Berkurodam 40-region sim More OpenSim 40-region Berkeley model OpenSim 40-region Berkeley model

No responses yet

Apr 23 2008

Terrain megaprim refinements

Published by under OpenSim,Scale Issues,SL In General

After spending plenty of time getting all the terrain megaprims stamped out, and starting some refinements of how to squeeze the imageable part of the ortho into a portion of the 1024 square texture, I found myself rather unhappy with how lumpy the megaprims were in the flat part of the model. Berkeley has this sort of dual terrain personality (no comment on the residents) that has certain types of details in the distal fan and floodplain parts of town to the westerly, and very different types of details in the hilly and steep areas.

When one loads the natural terrain into OpenSim, the values are 64K of single-precision floating points per region. When loading terrain into a megaprim, there are a mere 900 usable values that must be mashed into an 8-bit integer of Z values. So when the whole sim ranges from 45–267 meters (and it could go up to 581 meters if a sim ran all the way up to Vollmer Peak) , one gets dynamic range issues if all the terrain megaprims are scaled to fit over the entire sim. So to mitigate this, I divided the sim into distal (the “flats”), proximal (the “foots”) , and hills proper (easterly of the Hayward Fault).

The upside of this extra work is better fidelity in the different parts of the model when the floating point values are approximated by 8-bit integers. When I used the entire elevation range for the whole UC Berkeley sim, each integer Z value was 87 cm, or close to three feet. With the sim broken into three regions of megaprim Z-scaling, I have each integer worth 11 cm in the distal, 31 cm in the proximal, and 63 cm in the hills, so everything is a little better everywhere. I’ll fess up to not having the prim placement fully automated, otherwise it would be practical, and perhaps desirable, to use the full dynamic range over just those elevation values in the region (or even in the quadrant of the region that the terrain megaprim covers). But by that point, I’d consider even denser grids of terrain megaprims, and it would then be a different process for representing the terrain.

After all, the whole point of this exercise is to devise a work-around for not being able to load the ortho imagery directly into the region as a draped terrain texture!

Enough blabbing – please enjoy the graphics.

Three zone design for terrain Here is how the terrain maps out versus the buildings

Terrain that has three zones Not intended as digital Cubism, this odd-looking approach makes better terrain megaprims. Really, it does!

Overlay of ortho with 3-zone terrain In case one knows particular buildings on the UC Berkeley campus or environs, this is how the zoning worked out. There is a certain logic to it, geomorphically.

No responses yet

Apr 11 2008

OpenBerkurodam and the well-tempered scale

Published by under BART Station,OpenSim,Scale Issues

Enough carefree hours in the main SL Agni grid, already! Back to matters of creation.

Next big thing should be a terrain prototype for civic application. No special business process in mind here, just a demo of the draped imagery on real-life terrain in a way that could scale up city-wide. For starters, there must be a better correspondence between the US National Grid and the dimensions of the simulated region. Sure Neal Stephenson may have suggested binary 2^n dimensionality, and there may be plenty of reasons in the simulator code to make use of the full range of 256 meters. But after more than a handful of regions, the starting corners get downright ugly.

So I won’t do it that way. By scaling up, larger even than real-life, the regions can be built sixteen-to-a square kilometer. In a worldwide sense, except for the matter of 62 or 64 matchlines, the US National Grid (a.k.a. Military Grid Reference System or MGRS) has the whole world in its hands, so harmonizing region design with that grid plan covers a whole lot of ground. To minimize my effort at constructing regions, while planning for worldwide sim grid extensibility, I have chosen to configure the overall sim to represent 250-meter square patches of real earth using each of its 256-meter square regions.

This scales the real-world up a shade in the sim, to (1.024 : 1) but allows every fourth region in X and in Y to start on an exact grid kilometer. That scale produces 16.0000 regions per square kilometer, rather than 15.2588 regions/square km. From the geography side of things, this harmony is attractive since every fourth region will snap to a grid kilometer instead of every 1000th region. Even at that, the grid kilometer that 1000 of those 256 meter regions snap to is 256 kilometers, which is much clumsier to locate by name.

Thus the “well-tempered” moniker for this scale is well deserved, as any real-world USNG/MGRS grid coordinate could then be used to search for the relevant simulator region from a moderately simple bit of string manipulation. For Berkeley, and the western part of California, the zone is “10S” and the 100-kilometer grid within that is “EG” for San Francisco and Berkeley area. Put together, the US National Grid designator for the 100-km square is sometimes called “10SEG”, depending on where folks do or don’t put spaces.

If we always have exactly sixteen (16) regions per square kilometer, then we can use the shorthand version of the USNG grid names that only detail down to 10-meter increments. In this way, a region with its southwesterly corner at WGS84 UTM zone 10 north, 564000 meters Easting, 4191250 meters Northing, can have the US National Grid 10-meter designation of “10SEG 6400 9125”, which could be mashed together without spaces, or used to name a simulator region such as “10SEG_6400_9125” in a slightly more readable form. For those of us who no longer have youthful eyes, the tiny little display on the Second Life client for the region name motivates the use of spaces.

So here’s a graphic of the plan: a 40-region prototype (5 x 8 regions), which will be configured with only Basic Physics, but real-life LiDAR-based terrain, and four megaprim sculpties per region to drape imagery (10 x 16 terrain sculpties) such as 10cm natural color orthophotography. Here’s where I hope to take this:

Charter Design: US National Grid standardized OpenSim regions for Berkeley Downtown / Main UC Campus

No responses yet

Mar 26 2008

Whew! A new multi-resolution 1:1 terrain is modeled

Published by under OpenSim,Scale Issues

Terrain from a CAD-GIS data integration

Over the past four weeks I’ve participated in a burst of effort that has involved multiple resolutions of GIS data to describe a campus terrain in an eastern US state. It’s been over twelve years since I’d worked with a 3D CAD design for a slope design, and this one brought back memories and put detail into a much finer scale, working with 30cm contours around one new building, where my earlier efforts were more like 2m contours over a large industrial site. All the same, having once “written” a slope design, I found it possible to “read” the design work that existed in various layers, some 3D and some 2D, in a new site design.

One of the beautiful and satisfying aspects of GIS work can be the integration of disparate data sets into a spatially coherent whole. In this case, I sought to make an OpenSim terrain that would be home to a very complicated build where two CAD drawings held structure details, a third held the site and design terrain, and as is often the case, a merge with surrounding seamless USGS DEMs was desired.

The first step was to ensure that the site base map and structure plans matched scale and could be lined up. A combination of grounding mat and retaining walls in the site plan made that possible, and in ArcGIS, the AutoCAD DWGs for the structure were translated onto the site plan drawing. That was a lot of work, with over 2Meg of polylines in the structure, and I knew from my Berkurodam build that keeping a complex structure square with the region grid would be frequently appreciated by those working this build.

To earn the appreciation of the build workers while merging the region with the surrounding world, it was necessary to define a projection-referenced local coordinate system for the campus. Mercifully, the site plan contained many building footprints across the street from the construction site, and these were easily identified in publicly available regional 30cm orthoimagery. I chose a well-defined corner of one building as my pivot point, calculated both WGS84 UTM meters and local campus grid inches (converted to meters) for that point, and defined grid north as 014 degrees azimuth on the UTM grid.

The facility for defining a local grid this way is easy in ESRI ArcGIS, and with it I could create a Feature Dataset dimensioned in meters for the campus grid. I was able to export the CAD drawing polylines into an inches-denominated version of the campus grid, then select a fistful of layers and export those into the meters-denominated campus grid for editing and 3D terrain work. It was especially helpful to have ArcGIS’s ability to project the UTM-based orthos into the local grid, as I was not able to figure out how to include an arbitrary grid rotation in an ERDAS custom projection. Once I knew that I had a projection-based local grid definition and could move GIS features and imagery back and forth from UTM, I imported two 1:24,000 sheets’ worth of 10-meter DEM data, about 6km by 7km of 30cm natural color imagery, and I was comfortable diving into the grading plan model knowing that regional context would be available.

The greatest labor involved reading the site plan drawing in detail, clipping out regraded areas from the existing terrain which was a 3D drawing, then editing each segment of each contour in the grading plan (sadly a 2D drawing) to have the proper elevation attribute so that it could flow into the existing terrain contour. A lot of this took careful contour reading and switching views between the multilayer DWG view in one ArcMap session (where I could read all the annotation like contour labels), and the imported polyline contours being edited sans annotation in another ArcMap session (where I had not had success importing the CAD annotation). One of my first realizations when I started keeping two ArcMap sessions running (to keep an eye on the CAD annotation) was that I had misread the drainage swales and had grown them out of the terrain, placing drainage lines farther upslope that was actually in the design.

After a couple of weeks calendar time, I had completed what might be the first 3D CAD model of the site as it was designed. At least, if a 3D model already existed, I did not have access to it. When every segment of every contour had the proper elevation attribute, I regenerated the 3D polylines with Z values only from the attributes. Then using typical techniques, I created a TIN with hard breaks on the contours, and ground out both 1-meter and 0.5-meter postings of gridded terrain from the TIN. This provided highly detailed terrain for at least one OpenSim region.

Grid merge of CAD terrain with regional DEM terrain

Merging this 1-meter posting terrain with 10-meter regional data that had been rotated 14 degrees was the next challenge. First, I made an effort to harmonize the vertical datums. The regional DEMs had typically excellent metadata and with very little interpretation, made it possible to define them as WGS84 NGVD29 meters, which I recalculated to WGS84-Geoid2003 NAVD88 meters. The CAD site plan fit most closely with the resulting grid when I just defined it as WGS84-Geoid2003 NAVD88 meters (from design Z-inches), although it remains about 1.5 meters lower at its edges than regional DEM, when overlaid on the regional data.

The typical challenges of oversampling coarse grids were quite graphic in the regional data. After using ArcGIS to project a WGS84 UTM copy of the regional DEM into the campus grid, I used ERDAS Imagine to resample that 10-meter source into a 1-meter working model. Having 100 grid cells with identical elevation looked unnatural at best, so I used an ERDAS focal analysis with a 7×7 kernel to estimate a mean value for every cell in the 1-meter resampled version of the local-grid-projected version of the regional DEM. While normally this would be an extreme focal analysis, it seemed to produce a reasonable result for the 10×10 oversampled regional DEM.

When the regional grid was prepared, I used ERDAS mosaicking to overlay the detailed site plan, and then found a desirable origin point and clipped a subset 768m by 1024m area that, based on the co-registered 30cm ortho imagery, just covered the campus area with 1-meter posting terrain and could be stood up as 12 OpenSim regions at 1:1 scale.

For texturing purposes, I used ERDAS to resample the campus grid version of the orthos that had been reprojected by ArcGIS, from the original 30cm to 25cm pixels. This allowed clipping of a subset of the model area as a 3072 x 4096 image, providing a 1024×1024 texture for each OpenSim region after dicing. For demonstration purposes, and as a guide to build-out of less detailed structures around the campus, these ortho tiles are used to texture on a 256m by 256m by 0.4m horizontal megaprim plate centered on each region. These textured megaprim plates make it easy to calculate sim region coordinates for buildings and objects visible in the ortho imagery.  These calculations should be useful when synchronizing real-world activity with its simulator facsimile.

Easterly view of 12-region campus-wide model

No responses yet

Oct 30 2007

With Imagery, now too

Published by under OpenSim,Scale Issues

What’s real-life terrain without real-life imagery to top it off with?

Kentfield and Greenbrae, California

This is a view of Kentfield, Greenbrae, and the Corps of Engineers-enhanced portion of Corte Madera Creek.  The College of Marin athletic fields are on the left, Marin Catholic High School fields in the upper right, and Marin General Hospital in the lower right.  The NAIP imagery is textured on a flat 256 meter square prim fixed at 15 meters scaled elevation, so the sim’s terrain shows above it in several hilly places.

Phoenix Reservoir and Mt. Tamalpais

Here, another sim has Phoenix Reservoir and Bill Williams Canyon, both above Ross, California.  Mt. Tamalpais East Peak is behind the lake but does not yet have specific texture on it.  The edge of another 256-meter square prim with the next orthoimage tile to the west is visible in the right.  Two sims farther west, all of Bon Tempe reservoir imagery has been nestled within its proper terrain.

I wish that I could simply use my orthoimagery as a drape over the terrain; alas, that does not seem to be an OpenSim (or Second Life) priority at this time.  None the less, I have already created the first seven sims’ worth of image tiles, and they can be used to provide horizontal control for a great amount of future construction.

2 responses so far

« Prev - Next »