We also wanted to include roads and bridges in our map. This information is available from the US Census Bureau's TIGER digital map database. Unfortunately due to its size, this database is generally not available online, and must be purchased on CD, one CD per state.
Luckily, I found out about a digital map exchange site, and was able to contact Lee Moore, who was able to send me the albany tiger data. Matt later discovered that we actually have this data in the RPI library as well, and we used the CD's at the library to fill in some of the surrounding counties.
As it turned out, getting TIGER/line data into DX was a much harder problem. My first attempt involved converting from tiger data to DLG files using a DOS-based program, then using the gis2dx software to bring the DLG into DX. This did not work correctly.
At this point, I found the vis_tiger program, which was developed for internal use at UCLA. I talked to its author, Reinaldo E Chohfi, and was able to get a copy of the software and a lot of advice on how to go about using it.
Unfortunately, we were unable to get it to work correctly. Part of the problem may have been that it was designed for a newer version of DX than what we have installed at RPI. It's really unfortunate that we weren't able to use the UCLA software after Reinaldo was so helpful.
In any case, with the help of Damien Neil, we were able to produce a perl script that was capable of extracting the road data from the tiger files and converting it to DX format. We also wrote several other variations of this script to further mangle and manipulate the data. We built in clipping and a few other key functions.
Once we had all the streets extracted, we chose a subset of major streets in the area to plot, so that the plots would not be overly crowded with small streets. Also, Matt spent at least 12 hours extracting by hand the flight path for our camera in the second part of the sequence, cleaning up excess vertices, smoothing jaggies, etc.
The first one uses some fairly straightforward rubbersheets, color maps, and direction modules to move the camera around and extrude the z data from the DEM data field. All of the caption changes, camera moves, color map and height changes are coordinated through a complex tangle of compute modules and the sequencer. We used a big switching structure to turn on and off the street data for the various counties.
The second network produces the flythrough effect. It's a bit more complex than the first network was. It builds on the same basic rubber sheet stuff to create the landscape, and uses the same color map. However, the street that we are following is rendered separately as a different colored ribbon with a smaller line down the center.
Also, in order to make the streets visible in the overhead angle, it was necessary to have two sets of ribbons for the roads, with one greatly oversized so that it would show up in the overhead shot.
The camera position is basically iterated through the path using an extract/select/select system of modules. This position is both plotted on the overhead map (using a contstructed cube), and used as the "from" position for the camera (with a fixed Z coordinate, so we appear to be flying over the road). The tricky part was aiming the camera correctly. We ended up using a big compute object that averages the next few points along the path for an average horizontal angle, then derives the vertical angle from a trigonometric function we whipped up.
The two views are superimposed on each other (with the overhead shot suitably shrunk and offset to the corner.
The final animation was created by taking the output frames of both networks (rendered on hawk.vlsc) and a few text frames created with Photoshop on the mac and encoding them as an mpeg movie.