Jefferson County, WV High-Resolution Land Cover

Several months ago the Jefferson County Commission (West Virginia) asked us to develop a high-resolution land cover dataset for them. Like many counties, when it came to remotely sensed data they were data rich, but information poor. In 2005 NRCS had flown high-resolution LiDAR, and the USDA acquired 1m color infrared aerial imagery as part of the 2007 NAIP acquisition. A wonderful remote sensing database by any standards, but Jefferson County found they could not answer very basic questions such as, "How much tree canopy do we have?"

To assist Jefferson County we built an object-based image analysis (OBIA) system using the Cognition Network Language (CNL) found in eCognition to map 7 land cover classes from the imagery and LiDAR. This was followed by a detailed manual review of the entire dataset. The project was not without challenges, the chief one being the slight (0.5-4m) horizontal offset between the imagery and LiDAR. Fortunately, CNL provides a robust set of algorithms, allowing us to build an expert system that yielded, accurate and cartographically pleasing results.

The end result was a high-quality land cover dataset developed with minimal costs to Jefferson County. As this project used readily, freely available datasets it demonstrated the excellent return on investment that can be had from federal remote sensing programs.

I set up a simple viewer, overlaying the land cover data in Google Maps, with a few clicks of the mouse using the ArcGIS extension Arc2Earth.

Note that the imagery present in Google Maps is more recent that what was used for the project and thus differences between the imagery and the land cover are the result of changes in the landscape. Jefferson County no has an excellent base layer to which they incorporate these changes and track them over time.

Image Processing to Improve Image Objects

A few years ago when object-based image analysis (OBIA) software was gaining popularity a number of us in the remote sensing community (myself included) went through a healthy “pixel bashing” phase. After all, applying some of the standard image processing techniques to extract features from high-resolution multispectral imagery with just a few bands just seemed silly given the importance of shape, size, and contextual information compared spectral information. Image processing techniques no longer seemed all that valuable.

My thinking has changed a lot in the past year and I now often employ image processing techniques to aid in my OBIA work, but do so at a different stage in the process than most of the recent articles I have seen in the literature. In those articles, image processing techniques are typically used to generate layers that provide additional attributes for the image objects (e.g. NDVI), which are in turn used to assign the image objects to a particular class. In this post I am making the case for using image processing routines to create more meaningful objects by employing the image processing routines prior to segmentation.

I worked on this example with Dr. Carl Diegert from Sandia National Labs. Dr. Diegert introduced Gaussian noise into an image of bright rectangles arranged in an arc. Despite the noise one can clearly see the rectangles when zoomed out to the extent of the image.

When we zoom in to point at which pixels become visible it is difficult to determine where the edges of the rectangles are.
As image segmentation algorithms work at a “local” scale they yield highly unsatisfactory image objects in a case such as this. As the image objects do not correspond to the rectangles, it is impossible to classify the rectangles by their geometric (e.g. shape, size) properties.


If we apply a median filter, the contrast between the rectangles and the background improves.

We can then use the median filter layer as an additional input layer for the segmentation algorithm. This produces image objects that better represent the rectangles.

Finally, we can extract the rectangles based on their geometric properties alone. In this example I created a function that computed the likelihood of belonging to the “bright rectangles” class based on the area (number of pixels), shape index (border length divided by 4 times the square root of the area), and asymmetry (ratio of lengths of the minor and major axes).


The advantage of using geometric properties instead of brightness is that they are likely to be more stable under varying conditions.

This was a simplified example, but the theory holds regardless of the data you are working with. Consider using edge detection layers when working with aerial or satellite imagery and slope layers when incorporating LiDAR digital surface models.
For those of you using eCognition version 8 you can download the project, data, and rule set from the eCognition Community site. There is no bouncing around between software packages - image processing, segmentation, and classification are all done within the eCognition environment.

FEMA, flood mapping, and LiDAR

A recent news article on the dim view local officials have of FEMA's flood maps reminded my own less than rewarding experience with the FEMA flood mapping program. It should be no surprise that in the last several years FEMA began using LiDAR to update flood maps. It's hard to beat LiDAR when it comes to generating high-resolution digital elevation data over broad areas. My main criticism with the flood mapping process relates not to the quality of the maps themselves, but to the contracting out of the flood maps, specifically the deliverables that the contractor is required to provide. I have never been successfull in obtaining the point cloud data from any FEMA flood mapping project. It appears the main problem is that the contractor hired to perform the flood mapping is the sole keeper of the LiDAR data. These contractors have no monetary incentive to either preserve or share this data (and I don't blame them if that's not what they were paid to do). The LiDAR point cloud is a rich source of information, something that should be preserved for long-term analysis, not thrown away by FEMA's contractors. Preserving the point cloud would also provide a mechanism for independent verification of the flood maps themselves.

What should FEMA do? In my opinion they should turn over all LiDAR contracting to the USGS. Once the data is acquired FEMA can contract out the actual flood mapping work. The USGS has an excellent track record of not only sharing data, but in getting interested parties to invest in "buy-ups" to either expand the area of coverage or improve the specs. FEMA has done quite a bit of LiDAR collection (through their contractors) in my state (Vermont), yet no one I have spoken with (VT has a very tight-knit geospatial community) has ever heard FEMA discuss collaborative opportunities. Our state USGS representative on the other hand, is constantly trying to build support for new LiDAR initiatives.

If the news reports about the quality of FEMA's flood maps are true and my suspicions about the point cloud data being tossed are well founded, FEMA's flood mapping money has not been well spent. I would encourage anyone from FEMA or anyone who has had luck getting FEMA LiDAR data to post a comment. I hope I am wrong.

IMAGINE 2010 first looks: batch processing

I installed ERDAS IMAGINE 2010 before the holidays, but only just got around to testing out the new batch processing capabilities. One of IMAGINE 2010's strong points is the ability to use multiple threads for certain batch tasks, including image compression. Most would agree that there is lackluster support for multicore processing in the geospatial software arena, so it's nice to see things are coming around.

The screen capture below is from the new IMAGINE 2010 process list. I needed to compress several hundred GeoTIFF files to JPEG 2000. My new Dell T7500 workstation has 16 cores, allowing me to compress 16 tiles simultaneously. Needless to say this is a huge time saver.