3D GIS Seminar

Just a quick note to say that the Bentley Seminar on "Bentley 3D GIS" is now available here. You need to register for both their site and the seminar, but it is quick and painless. The main focus on the seminar is (a) the need for 3D GIS for infrastructure and other applications and, (b) Bentley's tools for integrating GIS, CAD, and BIM data for city modeling applications. This focused on Bentley Map as a primary tool for data integration, modeling, and visualization. CityGML export has been added, which may make Bentley Map one of the earliest systems from a major vendor to support the standard.

It's great to see more people thinking about 3D cities beyond just the physical models. It will be interesting to see who will be the first to market with a system that integrates model creation and collection (e.g. collect buildings in stereo, from LIDAR, or automated techniques) along with urban information management.

3D City Building Case Study

While high-fidelity 3D city models have been around for 10+ years, they have been getting a lot of attention in recent years with the advent of Google Earth and Virtual Earth. I've touched a little bit on 3D building extraction and texturing in a previous post, but recently came across an excellent case study from Magnasoft entitled "Build Virtual Cities to Plan Real Cities".

The case study provides an overview of start to finish textured city construction. The main input data consists of stereo pairs, and the software involved includes LPS, MicroStation, and ArcGIS. The final products go well beyond just buildings: they also include roads, tree canopies, water bodies, electric poles, walls, and fences. You can see from the stereo feature compilation screen shot (on part 5) that complex building structures can be modeled in high detail.

Just to explain the process in a bit more detail: MicroStation is important because LPS' main 3D feature extraction application, PRO600, is an MDL application that hooks in the LPS stereo viewer and allows users to extract 3D objects in stereo within the MicroStation environment. After the building intelligence is added in ArcGIS, the models are brought into Stereo Analyst for IMAGINE (another 3D extraction tool, which is an add-on to ERDAS IMAGINE), where a feature called the Texel Mapper can be used to automatically texture the buildings from the "block" of aerial photographs. I'll expand more on this process in a future post...

Sensor to GIS: An Example Workflow (Part 2)

In the previous post I outlined the process for ingesting raw imagery into a photogrammetric system and creating GIS data products: orthophotos, terrain, and building feature data. While I skipped what could be consider the very start of the workflow (e.g. flight planning, data download, etc) the idea was to demonstrate the major steps involved in creating GIS-ready vector and raster data.

In today's post I'll walk through loading and using the data in Quantum GIS. After downloading the software, installation was pretty straightforward. The only real software setup operation I did before getting started with the workflow below was to install the GRASS plugin. This was fairly easy: you just select the Plugin Manager from the Plugin drop-down menu, select the GRASS plugin, hit OK and the plugin gets installed right away.

Since GIS workflows aren't nearly as linear as the photogrammetric processing was, I'm just going to list bullets of operations I went through:

• Load the terrain data. I added my terrain layer (which is a GDAL supported .img IMAGINE raster terrain file) with the Add Raster button. This loads the raster and displays the layer name in the legend on the left hand side of the application. By right-clicking on the layer, I could access the raster layer properties. From there it is possible to change things like the Symbology (check out the stylish "Freak Out" color map below), add scale dependent visibility, view metadata and a histogram.
• Load the orthophoto. The methodology for adding the ortho was the exact same as the terrain since they are both raster layers. In the screen capture below I've resized the main viewer, changed the DEM color map to pseudo-color and adjusted the DEM transparency. This gives me a better idea of elevation over the various parts of the ortho: red is higher elevation while the yellow and greenish-blue parts in the bottom part of the ortho are lower elevation. If the layer is selected I can spot check specific elevation values with the "identify feature" tool in the default toolbar.
• Load the building vectors. The button for adding a vector layer is right beside the button for adding rasters on the main icon panel. Since I had saved my buildings as a shapefile, the process for adding them into the project was simple. They are displayed in the screen capture below, after changing the polygon color. Yes, I was too lazy to extract more than four buildings....
• Create a Roads layer. The next thing I did was to create a new shapefile a digitize a few roads. There are actually two ways to do this: you can use either the native QGIS vector creation and editing tools, or you can use the GRASS plugin. In the screen capture below I used the native QGIS tools, but after experimenting for a bit I like the GRASS editing tools better - for example, you just need to right click to finalize an edit procedure, whereas in QGIS you need to right click, hit an OK button on the attribution panel, and then wait a second or so for it to render. I also like how the GRASS editing tools are in a single editing panel. This makes it easy to switch between tools, perform attribution, and makes for easier editing (e.g. moving vertices) on existing features.
• Buffering Roads. After digitizing the roads layer I opened up the Grass Tools, which are available from the GRASS toolset:

I selected the Vector Buffer operation (highlighted above), which produces a new vector layer based on a user-specified buffer distance. This is a simple operation, and I buffered the roads by 25 meters (see results below). While this is a very simple exercise, what I am trying to illustrate is that by the end of the workflow I was performing pure GIS functions based on vector data. These are "analysis" operations that can be performed independently of the sensor data that was used to create the base map data layers. At this point the imagery may not even be relevant in a real world project - even though sensor data processed in a softcopy photogrammetry environment provided the original source data.

The food for thought here is that knowledge of the base "input" data to a GIS is critical: decisions you make based on your GIS analyses depend on it. Accuracy issues with the input data (sensor issues or photogrammetric processing errors) can influence the validity of the entire downstream project.

Sensor to GIS: An Example Workflow (Part 1)

I mentioned in the previous post that photogrammetry is often the relatively unknown link between sensors and GIS. Today I will walk through prepping up sensor data, creating data products and then using them in a GIS.

First of all, a list of the ingredients:

• A softcopy photogrammetry system: in this case it is LPS running on my laptop. The various modules required are Core, ATE (automatic terrain extraction), the Terrain Editor, and Stereo Analyst for IMAGINE. I'll describe what each of these are used for as I go through the workflow.
• A GIS: I thought I would give Quantum GIS a whirl. I've been playing around with it lately and it has some interesting functionality. In particular, some pluses are that it is open source, uses GDAL for raster support, and I like how it has a GRASS plugin providing GRASS access within the QGIS environment. This is handy for 2D vector feature extraction and editing, as well as performing some analysis functions with the GRASS geoprocessing modules.
• Input data: for this example I'm going to use some aerial digital frame photography over Los Angeles, coupled with GPS/IMU data. More details on the source data in a future post...

Now for the workflow. The basic flow of the workflow is to process the raw image data through to an orthorectified product, and create ancillary GIS input data from the triangulated data. These ancillary datasets are, in this case, going to be terrain and 3D feature data. I'm not going to outline each button click and every minor step, but I will cover all the major steps. Here we go:

1. Setup the "block" in LPS. This is basically where you define the project. The most important part here is to get the projection system correct. This isn't fun to fix up if you've found out it is wrong later on...
2. Setup the camera file. This provides information about the camera, it's focal length, principal point, radial lens distortion parameters, and more.
3. Add the images. At this point the images are basically raw and have no orientation or georeferencing information associated with them.
   
4. Import the orientation data. Since the sensor was flown with a GPS/IMU system on-board, then I needed to import the orientation parameters. These will provide us with X, Y, Z, Omega, Phi, Kappa orientation parameters for each image. This provides initial orientation data that will can further refine. You can see the layout of the block below.
5. Run Automatic Point Measurement. This generates "tie points" via image matching technology that can be used to refine the initial orientation parameters in the next step. Tie points are precise locations that can be identified in two or more overlapping images (the more the better). Since I started with good orientation data, measuring true ground control points isn't necessarily required (providing you have high-grade GPS/IMU hardware and didn't run into any problems (e.g. while computing IMU misalignment angles)). I don't actually have ground control for this dataset but if I did, I would measure the GCPs prior to running APM. The screenshot below shows the dense array of tie points.
6. Run the Bundle Adjustment. This reconstructs the geometry of the block and provides XYZ locations for the measured points from the previous step. Blunders (mis-measured points) from the previous step may have to be removed to achieve a good result. After the adjustment succeeds with a good RMSE, the results can be checked via a report file and the stereo pairs visually inspected in stereo. Y-parallax in stereo would indicate a problem with the adjustment. The screenshot below shows the Staples Center in anaglyph (no stereo on my laptop), where the 3D cursor is positioned in XYZ right on top of the building. Since the top of the building is 150 feet off the ground, you can see the "anaglyph effects" on the ground around the building. At this point, I now have triangulated images and can start creating data products: terrain, orthophotos, and 3D features.
   
7. Generate Terrain. For orthophoto generation, I need a "bare-earth" terrain model. Normally terrain would be generated by running Automatic Terrain Extraction, which runs an autocorrelation algorithm to generate terrain points. However, since there are so many skyscapers in the block that it made more sense for this example to simply use the APM points and filter out tie points that had been correlated on buildings. Normally this wouldn't cut it and I would need either LIDAR, autocorrelated, or compiled terrain, but for the sake of expediency the APM-derived surface model should be fine.
8. Generate Orthophotos. Orthophotos are the #1 data product produced by photogrammetric processing. Most commercial applications have orthorectification capability, and the user interface for LPS' orthorectification tool is below. After orthorectification, there may be the need to produce a final mosaic, or a tiled ortho output. Here is the orthorectification user interface.And voila: here is an ortho, in this case I also mosaicked a few of the images together:
9. 3D Feature Extraction. For the example workflow I extracted a few 3D buildings in Stereo Analyst for IMAGINE, which is an ERDAS IMAGINE and LPS add-on module. That said, there are a number of commercial software packages that accomplish a similar function. The nice thing about Stereo Analyst is that it doesn't require a 3rd party CAD/GIS package to run on top of, and you can extract 3D shapefiles, texture, and also export to KML. Here's a screen capture of one of the (very few) buildings I extracted. Again I'm working with anaglyph as I am on my laptop.

While we just touched briefly on the major steps, at this point we have all data prepped and ready to go into QGIS. This will be the topic of the next post!

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...

Welcome to the Fiducial Mark

Welcome to the Fiducial Mark!

Over the past several years the once clear lines between photogrammetry, remote sensing, and GIS have become increasingly blurred. Once rigid workflows have become fluid, which means various tools/products/methods can be used to achieve a variety of results. While the traditional photogrammetric product was an orthophoto, the various by-products used the final product generation, such as 3D terrain and feature data, have become important products in their own right - and often outside the "traditional" photogrammetry domain.

I've started this blog to discuss geospatial and mapping technologies, product developments, workflows, and industry events. My main interests lie in the areas of digital photogrammetry, specifically terrain processing workflows, orthophoto production, mosaicking, and various airborne sensor technologies. Other interests include 3D city modeling and visualization, data sharing, and enterprise geospatial technologies.

Thanks for stopping by!