Showing posts with label terrain. Show all posts
Showing posts with label terrain. Show all posts

Monday, July 13, 2009

eATE: Automatic Terrain Extraction Webinar

If you're interested in automatic 3D terrain generation technology, please consider participating in our "Terrain from Imagery" webinar tomorrow (11am ET). Details are on the ERDAS homepage and the registration info is here. I'll be discussing some new technology that we've been working on for some time now, and are looking forward to releasing later this year. The webinar will cover a bit of introductory material, and then move into other areas such as point cloud generation (versus TINs and Grids), RGB-encoding, achieving throughput through parallel processing, and an overview of the user interface and some of the results we've generated thus far.

GeoEye-1 Color Terrain: Hobart, Australia

Wednesday, July 1, 2009

Downloading ASTER Data and More...

With all the recent media attention, it seems like it is best to wait a bit before trying to download any of the data. The Japanese site (ERSDAC) published a warning earlier today that downloads may timeout, and I had a challenging time even getting the USGS site to load:

I have mentioned this before, but here is a paper on hydrology/glacier mapping in the Tien Shan mountain range using both ASTER and SRTM elevation data. One of the benefits of ASTER and other satellite sensors is that they are very applicable to remote area mapping operations.

So while you're waiting for ASTER traffic to subside, why not check out the ASTER User Handbook? It contains a wealth of background information on the sensor, data products, processing, applications, and FAQs. Here it is:

Wednesday, June 10, 2009

Terrain Point Cloud Extraction from High Resolution Optical Images

If you've been to ERDAS Labs then you probably know that we are developing a new automatic terrain extraction solution. One of the unique things about the project is that it has given us the opportunity to think carefully about how we persist terrain data, and last week I had a chance to discuss this at the ISPRS Workshop in Hannover, Germany. I don't have a recording of the presentation, but here are some of the details:

1) Digital imagery is achieving increasingly high resolutions. We are now at a stage where airborne sensors can achieve higher than 5 centimeter pixel resolution.

5cm Resolution ADS80 Imagery

2) Many softcopy auto-correlation systems (XYZ terrain point matching system) were initially developed upwards of a decade ago, and were not designed to take advantage of high resolution sensors. Our own LPS ATE module was originally released in 2001 as "OrthoBase Pro" (timeline here). One of the features of some more modern systems is the ability to attempt correlation on every pixel - which can yield a very large volume of data.

117 Million Auto-Correlated Terrain Points

Detailed View: Terrain Points on Individual Boats

3) TINs and Grids, the traditional formats for persisting terrain data in softcopy photogrammetry and GIS, may not be optimal for high resolution terrain data: hundreds of millions of points at a high density. Both have pro's and cons, which Gene Roe has outlined here. Grids can be redundant (particularly for flat regions) and while TINs are very flexible in this regard, they have no standard format. Each vendor has their own implementation, making data translation and transportability a challenge - not to mention long-term storage.

4) The LAS format, while designed for use with LIDAR sensors, may be a viable alternative to TINs and Grids for autocorrelated terrain data. Why? There are a few different reasons:
  • LAS is an ASPRS-administered standard and has a high adoption rate among geospatial software vendors.
  • The LAS 1.2 specification supports attribution, for example the ability to encode an RGB value for each terrain point. While it isn't commonly used within the LIDAR community, it is very useful for auto-correlated terrain. This allows RGB-encoded terrain to be used for applications such as visualization. Capabilities such as this are not possible with the traditional TIN/Grid approach.
  • When correlating on every image pixel, terrain data can be very dense. A compelling research area involves applying LIDAR classification and filtering techniques to autocorrelated terrain data.
Point Cloud with Color Attributes (CIR, Red, Green: ADS80 Imagery)

Detailed View: Point Cloud with Color Attributes (CIR, Red, Green: ADS80 Imagery)

The images above show color attribute encoding for an LAS 1.2 point cloud that was processed from stereo ADS80 imagery. The bottom image is a zoomed in perspective view showing a lot of detail: solar panels on the roof, cars, and a feeling of depth in the empty pool. These images show the point cloud rendered as a TIN within the FugroViewer. As you can see, the terrain representation is quite different from a traditional TIN or grid.

Thursday, June 4, 2009

LPS eATE at ERDAS Labs

You may have seen the press release regarding the new ERDAS Labs website. One area I would like to highlight is the LPS eATE Preview section. This features a movie and a blog post (New Algorithm for Automatic Terrain Extraction) by Dr. Neil Woodhouse, who has been involved with our new terrain project since the start. As he suggests in the post, we chose to develop a completely new solution rather than incrementally improving the current LPS ATE product - which was originally released as Orthobase Pro back in 2001.

Both the movie and the article feature Neil working with and discussing auto-correlated terrain persisted in the LAS format, which is more commonly associated with LIDAR data but also makes a great deal of sense for dense (high resolution) terrain data as well. Note that the software used to present the data Neil discusses in the movie is the FugroViewer, which I discussed here. One of the nice aspects of the FugroViewer is that is shows RGB-encoding for both the point cloud and a derived TIN - which is great for visualization of the terrain surface.

One other thing to note is that eATE is still under development, but we are looking forward to releasing the initial version!

Monday, May 18, 2009

ISPRS Hannover Workshop 2009

The ISPRS Hannover Workshop is coming up at the start of June covering "High Resolution Earth Imaging for Geospatial Information." The topic areas look good, covering:

  • Digital aerial cameras
  • Handling of high resolution space images
  • Impact of web-based access to, and use of, remote sensing images (Google Earth, Microsoft Virtual Earth)
  • Potential of small satellites for topographic mapping
  • Airborne laser scanning
  • Synthetic aperture radar (SAR) and interferometric SAR
  • TerraSAR-X
  • Sensor and system calibration and integration
  • Direct georeferencing
  • Sensors and methods of DEM generation
  • Aerial and satellite image analysis
  • Rapid change detection and update for environ mental applications
  • GIS driven updating and refinement of geo spatial data bases
  • From experimental systems for object acquisition and updating to commercial solutions
We'll be there on the Tuesday "DTM" session to present research we've been conducting at ERDAS pertaining to terrain point cloud generation from high resolution optical images (see here for for some initial concepts, more details coming later).

Monday, March 2, 2009

A Look at the Open Topography Portal

It was announced in early December, but I just recently came across the Open Topography Portal. The portal has made a large amount of LIDAR data available for active fault areas in both California and Washington. One of the unique aspects of the portal is that it provides web-based tools for processing raw point cloud data prior to download. The download interface is fairly slick, featuring a Google Maps interface allowing you to interactively select an area and then returning the number of points in your selection (guest downloads are limited to under 50 million points). The system displays the bounding coordinates and then allows for the definition of the delivery format.

The portal provides access to standard DEM products, (e.g. filtered bare earth), point clouds, as well as customized DEMs. Here are some of the options for creating a custom download:

Based on the selection area and processing options, the system provides the estimated processing time and then sends an email when the job is complete and ready for download.

I selected a small area and downloaded the point cloud data, which I then imported into ERDAS IMAGINE and created a shaded relief. Here's what it looks like (note that vegetation and buildings are all included, as filtering has not been applied):

Personally I think the user experience of the Open Topography Portal is more intuitive than the broader USGS CLICK (Center for LIDAR Information Coordination and Knowledge) portal. However portals are developing all the time and it is good to see progress in the ease of use and accessibility of advanced processing and download options.

The other notable news regarding the Open Topography Portal concerns the San Diego Supercomputer Center (SDSC) starting cloud computing research - with a special focus on the GEON LIDAR workflow application. This is something to keep an eye on, as LIDAR data is massive and as of yet I haven't heard of any attempts to use cloud-computing for processing or data management - although there have been initiatives in terms of storing LIDAR data in a database (e.g. the folks at LASERDATA use PostGIS). The Open Topography Portal is a collaboration between scientists at the SDSC and earth scientists at Arizona State University.

Wednesday, February 25, 2009

FugroViewer: Viewing 3D Data

As announced in their newsletter, Fugro EarthData has released a 3D point cloud viewer called the FugroViewer. This appears to be the latest in an assortment of freeware LIDAR/point cloud viewers on the market. In The Scan has some interesting commentary on these here (and there is also the LPViewer from QCoherent in addition to the ones listed).

Lately I've been taking a look at the various viewers, as we have an R&D effort focusing on 3D terrain in the ERDAS photogrammetry group. It is exciting technology to work on and we're very much looking forward to getting it out our of the lab and into our commercial software later this year.

After giving the FugroViewer a whirl it became immediately clear what the competitive advantage is: it is blazing fast in terms of the point rendering, refresh, and tinning. I was working with LAS datasets between two and twelve million points and both the load time and performance (on my laptop) were great.

Here's what a LAS file looks like loaded in FugroViewer. The initial view when you load a file is from a top-down perspective.

The user interface is fairly intuitive, and there are options for viewing the file in 3D, drawing/visualizing a user-defined profile, and numerous options for display (e.g. point coloring, TIN display, contour display, etc.). When you press the 3D button a new display panel opens on the right and a navigable 3D view is rendered, displayed below.

Here I have drawn a profile in another scene: you can see the profile overview in the left panel and and the profile view on the top right display. In this case the profile starts on the bank of a river and moves up a hill, with a church on the right hand side (which can be seen clearly if you click on the image to take a look at the larger view).


The software also displays file information about the LAS file - point count, points by return, LAS version, and so forth.

Overall I'd recommend giving it a try out if you're a regular using of LIDAR data, the performance is excellent and you can't beat the price.

Monday, February 16, 2009

Stereo Imagery as a Data Product

Considering the number of geospatial data products that can be derived from stereo imagery, it can seem surprising stereo images are not a widespread data product in their own right. Currently the main vendors of stereo data products are satellite operators such as DigitalGlobe (see here for their basic stereo pair product). Data derived from stereo imagery includes terrain, 3D vector data, and digital orthophotos: three of the most common products in the industry. Also consider that there are plenty of software packages on the market for creating orthophotos, generating and editing terrain, as well as working with vector data.


So why is it rare for stereo imagery to be sold as a "product"?

Personally I think there are a few reasons for this. These include:

  • There's no practical standard for storing photogrammetry metadata (e.g. image exterior orientation parameters). Although there are efforts underway, photogrammetric metadata is typically stored in proprietary formats. This inhibits the ability of the data to move from system-to-system. For example, if the imagery was triangulated in System X and then provided to a person using System Y, they invariably have to go through some pain and suffering to ingest the data (running an import job at a minimum).
  • Airborne flight operations are expensive. Data providers are typically contracted to fly specific jobs for clients such as regional authorities and so forth (here is an example). Times may be changing, but I haven't seen too many companies out there flying stock imagery and then reselling it. This is partly tied to the point above - without a common system for storing photogrammetric metadata, it is difficult for data vendors to deliver a one-size-fits-all solution.
  • The workflow is perceived as being difficult. For example, you need specialized and expensive stereo viewing hardware, domain knowledge in photogrammetry, etc. It all depends on the application, but if you're not performing stereo work all day long as your primary job, then it is still possible to get high-accuracy results working in split-screen or anaglyph mode. As for the domain knowledge, once the imagery is triangulated, then derived products such as the ones above are very easy to create - although they can be time-consuming depending on the project size.
It will be interesting to see if stereo imagery develops as a data product or if there will be a migration to photogrammetry-oriented web-services that essentially hides the process from users. For example, perform server-side orthorectification with a catalogued RPC image and terrain model and then deliver the orthorectified image as a WMS or WCS. This kind of functionality is on the market now, and I think it could be poised for growth...

Friday, January 30, 2009

Value-Added GeoPDFs Part 2

In case you want to check out the example GeoPDF from the previous post, I have now uploaded a couple versions of it to the Adobe Acrobat.com site. The file size is fairly big, so I created two versions:

Higher quality (compression factor of 60) at 119MB.

Lower quality (compression factor of 15) at 55MB.

In both cases the imagery looks decent, but the shaded relief in the 55MB version shows the effects of over-compression. If you haven't had a look at it before check out Acrobat.com as well - 5GB of online file storage are available for free!

To adjust the layers, open the files in Adobe Reader and click on the "Layers" icon on the left side. The bands are as follows:

Bands 1/2/3 = RGB orthomosaic
Bands 4/5/6 = Shaded Relief
Band 7 = DSM

In the example below the Shaded Relief bands are loaded, and as you can see they can be adjusted in a number of combinations.

Monday, January 26, 2009

Terrain From Imagery

In 2009 the need for accurate high resolution terrain data is only growing. One can see increasing numbers of applications that use terrain all over the geospatial industry and beyond. Part of the reason for the proliferation of terrain and applications that use it stems from increased usage in all methods of collecting and creating terrain. The SRTM mission provided course-resolution terrain for large portions of the world. LIDAR sensors continue to sell briskly, and of course automatically-generated terrain from triangulated oriented images (stereo pairs) continues to grow as increasing numbers of sensors capture image data.

Automatic terrain generation, which involves producing TINs and grids by correlating XYZ points from a pair of overlapping oriented images, is nothing new. In the context of softcopy photogrammetry the technology is over a decade old, and at ERDAS we have produced automatic terrain extraction solutions since the release of OrthoBase Pro back in 2001. Since then most photogrammetry practitioners have worked automatic terrain generation into their production workflows, particularly as a source for orthophoto generation. While I believe sensor fusion (capturing optical and LIDAR data simultaneously) will have an increasing role in the future, the reality is that automatically-generated terrain is also likely to play an important role for years to come. Why? Because data is becoming captured at increasingly high resolution and software solutions are evolving in their ability to generate corresponding high-density terrain data. A good example is the ADS80 sensor from Leica Geosystems. It can capture imagery at a 5 centimeter pixel resolution. Data captured at this resolution allows for very dense (and accurate) automatically extracted terrain.

In the photogrammetry group at ERDAS we’ve been putting effort into new techniques for automatic terrain extraction from imagery. Specifically we are looking at automating as much as possible, updating terrain extraction algorithms, and supporting modern IT infrastructures by adding distributed processing capability. After all, generating massive terrain datasets can require some serious computer power.

The image below shows terrain with a 10 centimeter density (post spacing) processed as an LAS file and displayed in GeoCue's PointVue LE viewing software (designed for visualizing LIDAR data). Color is based on elevation, so you can easily see the buildings and other surface features. Using a LIDAR viewer as a QC tool helps because of the density of the data.

In the image below I've rotated the view and applied intensity shading. This displays the detail quite well: it is possible easily discern the buildings, roads, crops and vegetation.

And a view of another area:

Monday, November 3, 2008

ERDAS Photogrammetry Movies

Something about the new ERDAS website that I would like to highlight is that there are now movies available for most of the products. If you navigate to the product pages, they are typically under the "Demo" tab.

I've embedded one of the LPS Terrain Editor movies below. The movie basically goes through the process of eliminating terrain points located on the tops of buildings to produce a bare earth terrain model suitable for orthorectifying the imagery. It is important to note that the Terrain Editor contains a stereo viewer (for 3D measurement) so the left and right images are, in this case, displayed in anaglyph mode.

As we expand the site we'll continue to add new movie content!



Monday, October 6, 2008

Now Released: LPS 9.3

We are pleased to announce the release of LPS 9.3 today! This is a major milestone for ERDAS, as we're launching new releases across all product lines today, which is a first. Additionally, we've completely updated the website at www.erdas.com. Each product can be downloaded from the site from the various product sections via the "Downloads" tab. For LPS 9.3, go here and click on the Downloads tab. Note that you'll need to register to access the download. You can also get a new 9.3 license from the link on the www.erdas.com front page.


The main theme of the LPS 9.3 release is 3D feature extraction, with the introduction of "PRO600 Fundamentals for PowerMap XM": PRO600 Fundamentals is a streamlined stereo feature extraction software. Basically we've made PRO600's PROCART module (3D feature extraction) available for Bentley PowerMap XM, which is a GIS-oriented application for map production in a 2D or 3D environment. PRO600 Fundamentals also includes LPS Stereo.

I wrote about a couple of the new benefits in previous posts, but I've also included the entire list of improvements below.

In LPS Core, the following improvements have been added:

  • Export to KML: This new LPS 9.3 feature exports an LPS block file or group of block files to the KML (keyhole markup language) file format. This feature allows for the export of both image footprints as well as point measurements associated with the block file.
  • Improved Automatic Point Measurement (APM) point correlation quality in cases with less than 50% overlap, variable flying height, and in sidelap areas.
  • Added support for NITF NCDRD format in the orbital pushbroom QuickBird/WorldView model.
  • The Triangulation Point Review user interface has been extended to support Satellite Sensor Models.
  • New Support for Image Chipping for NCDRD Sensor Model.
  • Registration free .NET and COM: New Registry Free LPS allows users to install different versions of LPS on the same machine.
  • Synchronized units of measure for the Average Flying Height (Frame Camera) and Average Elevation (Orbital Pushbroom) defined in the Block Property Setup with the units reported in the block file.
  • The Average Elevation, Minimum Elevation and Maximum Elevation units in RPC Model projects are now displayed in the project vertical units in the Frame Editor.
  • Synchronized units of measure for GCPs and residuals in the Refinement Report.
  • Enhanced Importer for ISAT projects with multiple flight lines.
  • Support for EMSEN Hand Wheels.
  • Added the LHN95 Geoid model (Switzerland).
  • Added Latvian Coordinate System (LKS-92) support, which includes the Latvian Gravimetric Geoid (LGG98).

LPS Automatic Terrain Extraction (ATE)

  • DEM Accuracy: Added an option to enter a tolerance in the vertical units of the terrain source to set the accuracy range for the predicted surface value of the area. The Min and Max Z Search Range will change with respect to the accuracy value entered. Providing a reliable tolerance will result better matching quality.
  • Added support for all currently supported sensors in Adaptive ATE (not just frame cameras and ADS sensors).
  • Reliability has been improved with better memory handling.

LPS Terrain Editor

  • Drive to Control Point: In 9.3 a new panel in Terrain Editor enables the display of GCPs and tie points associated with the currently loaded block file. An additional new dialog called “Control Point Display Settings” allows users to filter points in the cell array and choose the rendering settings for the Ground Control Points panel. The user can load some or all of the image pairs that a GCP is projected into. This new tool lets users check the quality of the DTM with respect to GCP, check points and the tie points. This tool can also be used for visual inspection of triangulation results after a bundle block adjustment.
  • Post Editor hotkeys: allow a user to quickly move through points by using keyboard arrow keys and adjusting the Z value for selected points in gridded terrain files.
  • Enhanced jpeg image display.

ERDAS MosaicPro

  • Save to Script Functionality: With the release of LPS 9.2, users were able to batch script the entire MosaicPro process and then execute the script from an MSDOS prompt. In 9.3 it is possible to generate the batch script automatically from the MosaicPro user interface. The script generated from MosaicPro may also be used as a template which can be easily modified. This new feature builds a script file from a combination of the currently open MosaicPro project and/or from previously saved settings from image dodging, color balancing, seam polygons, and exclusion areas. The MosaicPro process can then be run in time-set, batch mode from the MSDOS prompt.
  • Improved performance for seam polygon generation with "most nadir", "geometry", and "weighted" options.
  • Various reliability improvements.

STEREO ANALYST for ERDAS IMAGINE

  • Extend Features to Ground: this new feature uses a 3D Polygon Shapefile and extends the segments of each polygon (as faces) to the ground to form solid features (e.g. Buildings).

PRO600

  • Ability in PRODTM for the user to specify the extent within which to load terrain data. This allows very large terrain datasets to be used in PRODTM, in a piece-wise manner.

ORIMA

  • For triangulation projects using AD40 data, multiple ADS40 flown at the same time are now supported. This required the change of some file formats. This new approach leads to shorter project creation times.
  • CAP-A Release 8.10: New Handling of Orientation Data for ADS40. This new data handling has two primary advantages:
o The amount of disk space to store the project is drastically reduced.
o The startup time of CAP-A is much faster as there is no need to read the *.ori files and find the corresponding orientation for each point.

Defense Productivity Module (DPM)

  • Users in classified environments can now process NGA MC&G imagery in LPS photogrammetric workflows if the DPM is installed. This support includes access to AMSD ground and imagery points.
  • A new Image Slicer has been created to facilitate cutting of the original imagery into smaller segments for extraction. After slicing, an RPC model may be generated to provide support in ERDAS products without a local DPM license. If an NITF module is licensed, the RPC segments may be exported to NITF with RPC00B tags for interoperability with a wide variety of software packages.

Saturday, September 27, 2008

LPS 9.3 Preview: Control Point Review Tool

Last month I highlighted the ability to export LPS Block Files to KML. I'll do a full round-up of the new functionality as soon as we release, but for today I will focus on another new feature: Ground Control Point Review in the LPS Terrain Editor module.

The background for this feature came from many requests we received for the ability to review points either by themselves in stereo or as a means of checking terrain accuracy. Thus, we added a new panel in the Terrain Editor "View" drop-down menu: View > Panels > Ground Control Points.

In the screen capture below, I have launched the Terrain Editor and have opened the GCP Review Tool. I haven't loaded any imagery. The GCP Review Tool automatically loads in all points (ground control points and tie points) from the Block File that the Terrain Editor was launched from. You can see from the column settings that it provides some basic information such as ID, point type, coordinates, the number of images the point intersects, and the description.

In the Terrain Editor, the usual method for loading stereo pairs is to drag and drop them from the image pair list (on the left above) into the stereo viewport. One of the nice features of the GCP Review Tool is that you can automatically load images by double clicking on a particular point (double-click anywhere on the row). This is beneficial because it removes the need to know exactly which stereo pair to pick when you would like to review a particular point. In the screen capture below, I loaded a stereo pair associated with Point ID 30 by double-clicking on it. You can see that this is a full GCP, and it is even possible to see the target in the imagery.

Point symbol and label graphics can be turned on or off by using the icons on the bottom left of the panel. Additionally, the "Settings" button can be used to modify the behaviour of the tool. For example, it is possible to filter the points (e.g. only display full ground control points). It is also possible to customize the graphics (size, color, and label font).

Monday, May 19, 2008

LPS Terrain Editor: Terrain Editing Tip

For today's post I thought I would share a tip for a method of quickly editing TIN terrain datasets in LPS. In the LPS 9.2 Terrain Editor, we added a new "Terrain Following Cursor" mode. This was added as an icon in the Terrain Editing panel:Here's how it looks in the panel:
The terrain following cursor snaps the floating cursor to the height of the terrain for whatever XY location you move the cursor to. It operates in either an "on" or "off" mode, so you can easily roam around your imagery and the Z value (height) of the floating cursor will adjust automatically based on the terrain.

So why is this important?

Because it allows you to remove erroneous elevation spikes very quickly! When used in conjunction with the "Delete Tool" you can quickly identify points that are off the ground and delete them, or alternatively adjust them to their correct height. You can use the Terrain Following Cursor mode with any edit tool - here it is while using the delete tool:This means you can use it to easily locate problem areas such as the one below. See how the post is off the ground - the elevation of the point is 551 meters, when it should be at 569 meters.
Here's what the surface looks like after removing the post (a single-mouse click). This can be quite useful as a quality control tool - perhaps after completing area editing operations. After deleting posts, the floating cursor snaps back down to the surface. This allows you to quickly maneuver through a scene removing (or adjusting) TIN mass points. On a final note, you can even map Terrain Following Cursor mode as an event on your input device (e.g. middle-mouse button, or a Topomouse button).

Wednesday, April 23, 2008

Triangulated Irregular Network (TIN) Formats and Terrain Processing

One issue in the mapping community is that there is no standard format for Triangulated Irregular Network (TIN) terrain files. Most geospatial applications use proprietary formats, which presents serious interchange problems when moving the data around (e.g. from clients to customers, or even within an organization). Unfortunately we are guilty of this as well in LPS, with our LTF TIN format. Many people get around the limitations of proprietary formats by using ASCII as a common interchange format, where the TIN mass points are listed in XYZ for each row (separated by commas, tabs, or whitespace). Some systems also support the notion of points codes for breaklines, which are a critical part of the TIN structure. The main problem with ASCII is that once you get over several million points, the file can be cumbersome to deal with - which means it may be necessary to divide up the data into tiles. Alternatively you can convert the TIN to a raster format, but this can be undesirable if you have dense mass or unevenly distributed points, or if you have breaklines in the TIN (since rasters don't support breaklines).

A case in point is the LIDAR data from the Washington State Geospatial Data Archive. While there are standards for LIDAR data, most commercial applications do not (yet) natively support it. Hence there is a need to make the data available in alternate formats. The data is available in ASCII and TIN format for each quarter quad, but the TIN format is in .e00 format, which is an old interchange format developed by ESRI. Hence, the site recommends Importing the .e00 files into ArcMap in order to use them. The only issue with that is that you need ArcMap... This is likely a reason for including XYZ ASCII as an option as well. Another option is a 3 meter DEM for the entire coverage area, which is possible to download from here. It is in Arc/Info binary grid format though...

So how do we handle all of this in LPS?

There are a few different options here, and the LPS and IMAGINE groups have been working on a solution. Prior to the LPS/IMAGINE 9.2 release, users had to either use the 3D Surface Tool in IMAGINE or the terrain Split and Merge tool in LPS Core. In 9.2, and moving forward in future releases, we are consolidating our efforts by extending the LPS Split and Merge tool and making it available in IMAGINE, which we have renamed to the "Terrain Prep Tool". It is available in Data Prep > Create Surface in IMAGINE, or from Tools > Terrain Prep Tool in the LPS Project Manager.
The Terrain Prep Tool adds new split/merge functionality inherited from LPS as well as resolving some longstanding limitations associated with the 3D Surface Tool (e.g. it dramatically increases the number of points that can be handled). For 9.2 we also added a few formats such as LAS and two flavors of ASCII (with and without point codes for breaklines). The 3D Surface Tool will likely remain available for a few more versions, until we have fully replaced it's functionality in the Terrain Prep Tool.

Tuesday, April 8, 2008

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.

Sunday, April 6, 2008

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!

Saturday, April 5, 2008

Article Update: Photogrammetry Workflows, Present and Future

In this post I thought I would update an article I wrote last year that provides an intro to photogrammetric workflows and some thoughts on the latest technology. Originally published last May in GIS Development, this version has updated content and I've also added in links to further information on the various topics discussed throughout the article.

Hope you enjoy!


Introduction

The photogrammetric workflow has been relatively static since the advent of digital photogrammetry. Numerous application tools are dedicated to various parts of the workflow but the actual photogrammetric tasks have seen little change in recent years. However, we are beginning to see changes in the workflows. The growing proliferation of “new” technologies such a LIDAR, pushbroom, and satellite sensors has caused many commercial vendors to re-examine the application tools they offer. In addition, advances in information technology have opened up the possibility to processing increasingly large quantities of data. This, coupled with improved processing capabilities and network bandwidth, are also causing a change in traditional photogrammetric workflows.

Background

ERDAS has a long history in providing both analytical and digital photogrammetry solutions. As a Hexagon company, ERDAS’ mapping legacy dates back to the 1920’s with the founding of Kern Aarau and Wild Heerbrugg. These companies were consolidated into Leica and over the years offered analogue, analytical, and digital photogrammetry and mapping solutions. LH Systems, ERDAS, and Azimuth Corp. were acquired by Leica Geosystems in 2001. These acquisitions allowed Leica to enter a number of spaces in the digital photogrammetry market and offer comprehensive photogrammetric solutions to the production photogrammetry, defense, and GIS markets.

ERDAS’ initial photogrammetric offerings, Orthobase and Stereo Analyst for IMAGINE, were targeted at the GIS user community. As demand for 3D data grew in the GIS community, Leica Geosystems sought to provide easy to use tools for producing “oriented” images from airborne or satellite data and extracting 3D information such as building and road data. With the acquisition of LH Systems in 2001, Leica Geosystems inherited a staff and customer base skilled in production photogrammetry. This new customer base required engineering-level accuracy and primarily worked with large-scale airborne photography in the commercial arena and satellite imagery in the defense market. In early 2004 Leica Geosystems released the Leica Photogrammetry Suite (now LPS). This new product suite initially used updated components from OrthoPase and OrthoBase Pro, and developed new technology for stereo viewing and terrain editing. Shortly thereafter mature products such as PRO600 and ORIMA were integrated into the product suite and numerous update releases increased productivity. In April 2008, Leica Geosystems Geospatial Imaging division was re-branded as ERDAS.

Current Workflows

When asked about the “photogrammetric workflow” most industry professionals will refer to the analog frame camera (e.g. RC30) workflow. Analog frame cameras were prevalent during the transition to digital photogrammetry and still remain a common source of imagery. Numerous software tools have been developed to guide users through the traditional analog frame workflow. Popular vendors include BAE, INPHO (now owned by Trimble), Intergraph, and ERDAS. A brief outline of the mainstream analog frame workflow is provided below.

· Scanning process: Airborne camera film is scanned and converted into a digital file format. Some high performance scanners perform interior orientation (IO) as well.

· Image Dodging: Scanning may introduce radiometric problems such as hotspots (bright areas) and vignetting (dark corners). These can be minimized or reduced by applying a dodging algorithm. Dodging, in the digital photogrammetry sense of the word, generally calculates a set of input statistics describing the radiometry of a group of images. Then, based on user preferences, it generates target output values for every input pixel. Output image pixels are then shifted based on several user parameters and constraints from their current DN value to their target DN. Typically there are options for global statistics calculations for a group of images, which has the net effect of balancing out large radiometric differences between images. Overall this has the effect of resolving the aforementioned problems and “evening out” the radiometry both within individual images and across groups of imagery.

· Project setup: most photogrammetric packages have an initial step where the operator performs steps such as defining a coordinate system for the project, adding images to the project, and providing the photogrammetric system with general information regarding the project. Ancillary information may include data such as flying height, sensor type, the rotation system, and photo direction.

· Camera Information: the operator needs to provide information about the type of camera used in the project. Typically the camera information is stored in an external “camera file” and may be used many times after it is initially defined. It contains information such as focal length, principal point offset, fiducial mark information, and radial lens distortion. Camera file information is typically gathered from the camera calibration report associated with a specific camera.

· Interior Orientation (IO): The interior orientation process relates film coordinates to the image pixel coordinate system of the scanned image. IO can often be performed as an automatic process if it was not performed during the scanning process.

· Aerial Triangulation (AT): The AT process serves to orient images in the project to both one another and a ground coordinate system. The goal is to solve the orientation parameters (X, Y, Z, omega, phi, kappa) for each image. True ground coordinates for each measured point will also be established. The AT process can be the most time-consuming and critical component of the digital photogrammetry workflow. Sub-components of the AT process include:

o Measuring ground control points (typically surveyed points).

o Establishing an initial approximation of the orientation parameters (rough orientation).

o Measuring tie points. This is often an automatic procedure in digital photogrammetry systems.

o Performing the bundle adjustment.

o Refining the solution: this involves removing or re-measuring inaccurate points until the solution is within an acceptable error tolerance. Most commercial software packages contain an error reporting mechanism to assist in refining the solution.

  • Terrain Generation: Digital orthophotos are one of the primary end-products in the photogrammetric workflow. Accurate terrain models are an essential ingredient in the generation of digital orthophotos. They are also useful products in their own right, with uses in many vertical market applications (e.g. hydrology modeling, visual simulation applications, line-of-sight studies, etcetera). Terrain models can take the form of TINs (Triangulated Irregular Network) or Grids. Once AT is complete, terrain generation can typically be run as an automatic process in most photogrammetric packages. Automatic terrain generation algorithms typically match “terrain points” on one two or more images (more images increase the reliability of the point). Seed data such as manually extracted vector files, control points, or other data can often be input to help guide the correlation process. There are usually filtering options to remove blunders, also referred to as “spikes” or “wells” in the output terrain model. Filtering can also be used to assist in the removal of surface features such as buildings and trees. This can be of great assistance if the desired output is a “bare-earth” terrain model. It is important to note that terrain may also be acquired via manual compilation (in stereo), LIDAR, IFSAR (Interferometric Synthetic Aperture Radar), or publicly available datasets such as SRTM.
  • Terrain Editing: Digital terrain models (DTMs) that have been generated by autocorrelation procedures typically require some “cleanup” activities to model the terrain to the required level of accuracy. Most photogrammetric packages include some capability of editing terrain in stereo. It is important for operators to see the terrain graphics rendered over imagery in stereo so that they can determine if automatically generated terrain posts are indeed “on the ground”. That is, that the DTM is an accurate representation of the terrain, or is at least accurate enough for the specific project at hand. Terrain can usually be rendered using a mesh, contours, points, and breaklines. The operator usually has control over which rendering method is used (it could be a combination) as well as various graphic details such as contour spacing, color, line thickness and more. Terrain editing applications usually provide a number of tools for editing TIN and Grid terrain models. In addition to individual post editing (e.g. add, delete, move for TIN posts, adjust Z for Grid cells), area editing tools can be used for a number of operations. These may include smoothing, surface fitting operations, spike and well removal tools, and so on. Geomorphic tools can be used for editing linear features such as a row of trees or hedges. After a terrain edit has been performed, the system will update the display in the viewer so that the operator can assess the accuracy and validity of the edit. Once the editing process is complete the user may have to convert it into a customer-specified output format (e.g. one TIN format to another, or TIN to Grid). DTMs are increasingly a customer deliverable and product, as mentioned previously they have many uses and are becoming quite widespread in various applications.
  • Feature Extraction: Planimetric feature extraction is usually an optional step in the workflow, depending on the project specifications. Automatic 3D feature extraction algorithms are under development, but manual stereo extraction is still the predominant method. Feature extraction tools in digital photogrammetry packages typically allow users to collect, edit and attribute point, line, and polygonal features. Features can be products in themselves, feeding into a 3D GIS or CAD environment. Alternatively building futures may be used again in the photogrammetric processing chain in the production of “true orthos”, which take surface features into account to produce imagery with minimized building lean – which can be particularly beneficial in urban environments.
  • Orthophoto Generation and Mosaicing: Digital Orthophotos are usually the primary final product derived from the photogrammetric workflow. There are many different customer specifications for orthos, including accuracy, radiometric quality, GSD, output tile definitions, output projection, output file format and more. A mosaicing process is usually included in the ortho workflow to produce a smooth, seamless, and radiometrically appealing product for the entire project area. Mosaicing may be performed as part of the orthophoto process directly (ortho-mosaicking) or performed as post-process later on. Generally, orthophoto production follows these steps:
    • Input image selection: the operator chooses the images to be orthorectificed.
    • Terrain source selection: the operator chooses the DTM to be used for orthorectification. This is a critical step, as the accuracy of the orthophoto will be determined by the accuracy of the terrain. A terrain model with gross errors (e.g. a hill not modeled correctly) will result in geometric errors in the resulting orthophoto.
    • Define orthophoto options: Operators typical select a number of option for the orthorectification process. These may include output GSD, the image resampling method, projection, output coordinates and more.
Aside from defining the various parameters, the orthorectification process is not usually an interactive process. However, the mosaicing process usually does involve some degree of operator interaction. After images are chosen for the mosaic process, there is usually some method of defining seams (polygons or lines used to determine which areas of the input images will be used in the output mosaic). While there are many automatic seam generation applications, there is almost always some element of user interaction to either define or edit seams – or at least review the seams. Operators will typically edit the seams so that they run along radiometrically contiguous areas. That is, they do not cut through well-defined features such as buildings. This is because the ultimate goal of seam editing is to “hide” the seams so that they are not visible in the output mosaic. Once seams are defined, they can usually have smoothing or feathering operations applied to them so that their appearance is minimized.

Another important aspect is radiometry. While some operators will tackle radiometry early on in the workflow (as previously discussed in the “Image Dodging” step), others will dodge or apply other radiometric algorithms during the orthomosaic production process. The goal is to make the output group of images radiometrically homogeneous. This will result in a visually appealing output mosaic that has consistent radiometric qualities across the group of images comprising the project area.

A project area may be several hundred square kilometers in size, so a single output mosaic file is not usually an option due to the sheer size. End customers cannot usually handle a single large file and would prefer to receive their digital orthomosaic in a series of tiles defined by their specification. Most photogrammetric systems have a method of defining a tiling system that can be ingested by the orthomosaicing application to produce a seamless tiled output product.

In recent years the introduction of high resolution satellite imagery and airborne pushbroom sensors such as the ADS40 have added new variations to the traditional workflow. Both types of sensors product data that are digital from the point of capture, alleviating the need to scan film photography. Commercially available satellite imagery (e.g. CARTOSAT, ALOS, etcetera) has been available at increasingly high levels of resolution (e.g. 80cm resolution for CARTOSAT-2). While this is sufficient for many mapping projects, some engineering level project applications still require the resolution available from airborne sensors.

Pushbroom sensors such as the ADS40 can achieve a ground sample distance in the 5-10cm range. Modern digital airborne sensors are also usually mounted with a GPS/IMU system. GPS (Global Positioning System) technology assists mapping projects by using a series of base stations in the project area and a constellation of satellites providing positional information accessed by the GPS receiver on-board an aircraft. IMU’s (Inertial Measurement Unit) are increasingly used to establish precise orientation angles (pitch, yaw, and roll) for the sensor platform in relation to the ground coordinate system. GPS and IMU information can be extremely beneficial for mapping areas where limited ground control information is available (e.g. rugged terrain). They also assist in the triangulation process by providing highly accurate initial orientation data, which is then further refined by the bundle adjustment procedure. GPS and IMU information can also be used for “direct georeferencing”, which bypasses the time-consuming AT process. However, direct georeferencing is not a universally-accepted methodology within the mapping community. The caveat to direct georeferencing is that project accuracy may suffer – however this may be acceptable for rapid response mapping and other types of projects where lower accuracies are adequate for the end customer.

Thoughts on Current and Future Photogrammetric Workflows

We are beginning to see some shifts in the currents guiding photogrammetric workflows. These shifts are being driving by advances in computing hardware, new sensor technology, and enterprise solutions.

Data storage and dissemination is dynamic area in the industry. While imagery was traditionally backed up on tape systems, the cost of storage has dramatically declined in recent years. As customer demand for high-resolution data increases, it is becoming less practical for users to store data directly on their workstations. Users are increasingly storing imagery on servers, employing different methods for accessing it. Demand appears to be in the increase for tools to manage and archive data. Organizations are also examining the possibility of sharing and publishing data. The data may stored on servers and published via web services or made available for access, subscription, or purchase via a portal.

Sensor hardware is also rapidly changing the photogrammetric workflow. LIDAR has now been widely adopted and accepted, providing extremely high-density and high-accuracy terrain data. In addition to LIDAR, there is a growing trend of integrating LIDAR with digital frame sensors, which enables the simultaneous collection of optical and terrain data, enabling rapid digital orthophoto processing. This is much more cost-effective than flying a project area with multiple sensors for image and terrain data. When coupled with airborne GPS and IMU technology, terrain and georeferenced imagery – the primary ingredients for orthos – can be available shortly after the data is downloaded after a flight. IFSAR mapping systems are also a growing source of terrain data.

Coupled with explosion of imagery is the need to efficiently process it. One method that researchers and software vendors have begun exploring is distributed processing. Under this model a processing job is divided up into portions which are then submitted to remote “processing nodes”, which results in a significant improvement in overall throughput for large projects. Most commercial efforts, such as the ERDAS Ortho Accelerator, have focused on ortho processing. However there also several other photogrammetric tasks that lend themselves to distributed processing solutions (e.g. terrain correlation, point matching, etc.).

With data increasingly stored on network locations and the general adoption of database management systems, enterprise photogrammetric solutions will likely change the face of the classical photogrammetric workflow. With imagery and other geospatial data increasingly stored on servers, the processing framework is likely to change such that the operator interacts with a client application that kicks off photogrammetric and geospatial processing operations. Rather than running a heavy “digital photogrammetry workstation”, or DPW, the operator will be operating a client view into the project. Also, geospatial servers will enable organizations to store and reuse project and other data. For example, automatic correlation processes could automatically identify and utilize seed data stored in online databases, or terrain data stored from previous jobs. The notion of collecting data once and using it many times will be prevalent. Large quantities of data such as airborne and terrestrial LIDAR-derived point clouds will be able to be stored and have operations such as filtering, classification and 3D feature extraction applied to them. With a shift to enterprise solutions, industry adoption of open standards (e.g. Open GIS Consortium) will be critical. Providing open and extensible systems will allows organizations to customize workflows to meet their specific needs, fully enabling their investment in enterprise technology.

Conclusions

This is an exciting time for those of us in the photogrammetry group at ERDAS. Recent trends discussed above have opened up new avenues for changing, modernizing, and empowering what was until recently a relatively static workflow. Our customers drive us to deliver solutions that meet a variety of needs. While there is the constant need to pay attention to existing workflows, it is important to keep an eye on technology trends that will guide future workflow directions. Enterprise integration will likely change the face of classical photogrammetric workflows, making photogrammetry a ubiquitous component of modern geospatial business decision systems.