Defining Your Own Raster Basemap in ERDAS TITAN

Something I forgot to mention in yesterday's post is the ability to define your own raster basemap in TITAN. So what does this mean???

Most virtual worlds have pre-cooked imagery that they serve up as their "skin of the earth" basemap. But what if I want to define my own default imagery, just for my own personal use? Some applications allow loading imagery as layers, but one of the useful features of the TITAN Client is that you can use your own imagery as the default skin.

So how do you do this?

First, load your imagery in TITAN's Geospatial Instant Messenger. The screen capture below shows an ECW orthomosaic that I have loaded.
Next, right click on the layer and choose the "Copy WMS URL" option.

With the URL copied, navigate over to My Services, where you'll see a few difference service options. For the next step, double-click on the WMS service.
This opens up the "Select Services" interface.
Here you can paste in the URL of your image that you copied earlier. Accept it and you'll see the WMS show up in the list of services, displayed below.
Right click on the newly-added WMS service (displayed above) and choose "Set as Default Basemap". You should see it turn red, indicating it is the default basemap.

Finally, fire up the TITAN Viewer. You can see the results of the example I ran through below. Note that my only layers are a terrain layer (see yesterday's post) and a KML file. I don't have any image layers, as my orthophoto is being used as the skin for the virtual world. It's a nifty workflow and can be useful if you operate in the photogrammetric world and create/display/use your own orthos or if you purchase orthos and just want to use them locally as a basemap, without having to deal with layer management.

3D Buildings and Terrain in Virtual Worlds

One the the problems I've grappled with in the past is the challenge posed by modeling accurate photogrammetrically extracted 3D buildings in virtual worlds with a less accurate base terrain layer. The folks over at the Bluesky blog have outlined the same challenge in this post. Here's an example of the problem: when I import my KML 3D buildings into Google Earth, they float off the ground due to the accuracy of the base terrain layer. Here's a screen capture depicting the problem:
Even if you modify the terrain exaggeration the buildings still float. There's a few different methods for resolving this. One method suggested in the Bluesky blog post is to model terrain and imagery right into the KML file and then load it up in GE. This certainly works. Another method would be to take a look at a different system for visualizing the data.

The latest update to ERDAS TITAN has a good technique for sorting out this problem: it allows you to specify your own terrain layer. Once you add your data as layers in the viewer, you'll see a similar problem as depicted above - again due to the accuracy of the default terrain layer. The only difference is that instead of seeing floating buildings the buildings are embedded under the terrain layer, so that some of the smaller buildings are not visible. Here's a screen capture that displays the issue:

You can see that some of the buildings in the foreground appear very "flat", and there are others that are not even visible.

The solution is to add a terrain layer. In this case I processed my own digitial orthomosaic along with a terrain layer during the photogrammetric processing part of the project. I added the digital elevation models as layer, right-clicked on it and chose the "use as terrain" option.
The layer gets shifted to the terrain folder and the TITAN viewer updates to reflect the new base terrain. The result is that the buildings sit perfectly on top of the terrain. Here is the result, from the same perspective as the screen capture above:

In summary, take a look at TITAN if you're interested in this kind of workflow. The ERDAS TITAN Client is free, so you can download it from the ERDAS site and give it a whirl with your data.

New ERDAS YouTube Channel

We have just setup an ERDAS YouTube channel at: http://www.youtube.com/user/ERDASINC

This is a good way for us to walk through new features and workflows. Instead of learning about a feature as a bullet point on an email or brochure, you can see it live in action. Right now there are a couple of TITAN videos there, and we will be adding more. Feel free to check them out, and I'll post when I put any photogrammetry/mapping videos up!

Between Sensors and GIS Content

One of the things that has always struck me as unusual is that there does not seem to be a lot of insight into the role of photogrammetry in the broader geospatial community. For example, google “GIS data” and you’ll get a lot of hits on various GIS data sources, including street maps, census data, building footprints, cadastral data, and so forth. However, it is important to keep in mind that this data typically is not first generation, but rather a derived product. Often the data lineage is not tracked (or at least not tracked back directly to the sensor), so users making business decisions based on the data do not have insight into how the data was developed, potential problems with the data, the true accuracy, and other issues…

At any rate, the point of this post is that photogrammetric processing provides the link between satellite/airborne sensors and GIS data. How and why? This is because geospatial data frequently derived from some sort of sensor, be it airborne imagery, satellite, LIDAR, GPS, or any other of the measurement sensor technology. This is how we get the “Geographic” part of GIS. All that great orthorectified imagery you see as a layer in a commercial GIS or in Google Earth, Microsoft Virtual Earth, and ERDAS TITAN typically goes through some sort of photogrammetric processing. The Virtual Earth 3D blog has a good post on how UltraCamX sensor data is processed for delivery in Virtual Earth. The post doesn't contain the technical details of exactly what sort of processing is applied, as the exact nuts and bolts of the workflow is likely a Microsoft/Vexcel trade secret at the moment. The general workflow is fairly well-known though, as photogrammetric processes can produce all sorts of primary base map and other data (mainly orthos, terrain, and 3D feature data) as input into a spinning globe app or a GIS...

Stay tuned for the next post and I will walk through an "photogrammetry to GIS" technical example...