Silos in the Cloud? Thoughts from ASPRS 2013

By far my favorite session from this year's ASPRS conference was a panel discussion on "Strategies for Conducting Remote Sensing in the Cloud."  The panel consisted of the big brains from Esri, Intergraph (ERDAS), MDA Federal, Excelis (ENVI), and DigitalGlobe.  The general consensus of the panel was that the analysis of remotely sensed data will move from the desktop to the cloud in the coming years.  The advantages of the cloud are easy to see as the resource constraints we typically face, whether it be computing power or storage space diminish greatly.  New licensing models will allow us to pay for what we need when we need it as opposed to having to maintain banks of servers or buy software licenses that we infrequently used.

Esri, Intergraph, and Excelis all indicated they were working on cloud-based solutions.  There was a lot of discussion about "apps" and numerous comparisons to iTunes.  There was also a lot of mention about getting information (not just data) to the decision maker.  All this was great, but I think there are some fundamental differences in the way we extract information from imagery than from buying a song from iTunes.  If I buy a song from iTunes it sounds the same as if I had bought the CD or listened to it on Pandora.  There's no real advantage to me having a copy of the song on CD and on iTunes, it's the same song.

When it comes to extracting information from remotely sensed data I fire up 3-8 geospatial software packages on a given day to get my job done - ERDAS IMAGINE, ArcGIS, eCogntion, Quick Terrain Modeler, SOCET GXP, MARS, QGIS, GRASS, etc.  It's a mix of proprietary and open source.  I might be a bit of a software geek, but the real reason I do this is that the people I provide the information to (resource managers) are very discerning.  Each one of these software packages helps me improve the quality of the final product.  What concerned me with what I heard from Esri, Intergraph, and Exelis is that there was no mention of interoperability.  Esri mentioned that they have a deal with DigitalGlobe and they are looking at building applications around WorldView-2 and other DigitalGlobe satellites.  I use Esri products daily and I am a huge fan of WorldView-2, but I cannot think of a single dataset I can produce or a question I can answer that relies solely on these two products that wouldn't be better if I used multiple software packages and fused the imagery with other data sources.  What I want is to be able to do is grab components from each of the software packages I use, combine data from multiple sources, and process it all in the cloud.  If we limit the data sources and/or tools we will loose the ability to extract the most accurate and relevant information.

A silo in the cloud is the oposite of the interoperability we see happening on the desktop side (Integraph, Esri, and numerous open source programs support Python, allowing one call tools from multiple software packages in a single Python script).  I believe that those companies that support interoperability in the cloud will see increased adoption of their technologies.

High-Resolution Land Cover for the Greater Fairfax, VA Region

In collaboration with our friends at Casey Trees and Fairfax County we have developed a high-resolution (sub-meter) land cover layer for Fairfax County and the surrounding region, including the City of Fairfax, Fort Belvoir, the Town of Vienna, the City of Alexandria, Arlington County, the Town of Herndon, George Mason University, the City of Falls Church, and the Town of Clifton.

Communities mapped as part of this project.

We mapped seven land cover classes from 2011 WorldView-2 imagery and 2008 LiDAR: (1) tree canopy, (2) grass and shrubs, (3) bare soil, (4) water, (5) buildings, (6) roads/railroads, and (7) other paved surfaces.

WorldView-2 imagery (left) and resulting land cover (right)

My understanding is that this is the most comprehensive, accurate, and detailed land cover dataset for the region and will undoubtedly help communities better manage their landscape.  We are currently working with our partners on analyzing the data and will hopefully have it out to the public in a month or so.  Keep in mind that this dataset is not for the faint of heart, there are close to 9.5 billion pixels in it.

Basic Feature Extraction Tutorial

In this video I provide a basic tutorial on how to build an expert system to automatically extract land cover features from high-resolution imagery and LiDAR.  Sorry for some of the weird noises in the background.  That's my cocker spaniel snoring.

The data consists of a 4-band digital orthophotograph from the National Agriculture Imagery Program (NAIP) and LiDAR point cloud LAS file acquired by the USGS.  The NAIP orthophoto is from the summer of 2010 and the LiDAR point cloud is from the spring of 2011.  You can download both the imagery and the LiDAR from this link.

The process is quite simple and makes use of a few different software packages.  The steps are as follows.
1) Data exploration in ArcGIS and Quick Terrain Modeler
2) LiDAR surface model generation in Quick Terrain Modeler
3) Feature extraction using eCognition
4) View results in ArcGIS.

Please note that this tutorial is licensed under a Creative Commons Attribution-Share Alike license.

Mapping tree canopy change in the District of Columbia

We have conducted an extensive study of tree canopy change in the District of Columbia from 2006 to 2011 using high-resolution imagery.  This project was extremely challenging due to the numerous factors (sensor, resolution, look angle, offset, etc.) that made it very easy to falsely classify change.  Despite our best efforts at an automated approach, in the end it came down to good, old-fashioned manual image interpretation.  Only a human was capable of determining if the change was actual change or false change resulting from the aforementioned differences in the image datasets.

As you can see from the example below the mapping is extraordinarily detailed.  We went to great pains to map change at the individual tree level and felt that this level of detail was required to account for the fine-scale change that occurs in an urban environment.

In order to solicit input from all stakeholders we are releasing this dataset for review and comment.  You can download a zipped shapefile from this link.  Please note that the shapefile does include metadata in XML format.  The ChangeType field consists of three possible values:  1) no change, 2) loss, and 3) gain.  No change indicates that the tree canopy has not changed substantially from 2006 to 2011.  Loss indicates that tree canopy was removed from 2006 to 2011.  Gain indicates that new tree canopy was established between 2006 and 2011.

If you have the time to evaluate this dataset we would be grateful for any feedback that you can provide.

An object-based system for LiDAR data fusion and feature extraction

An object-based system for LiDAR data fusion and feature extraction is the title of an article headed for publication in Geocarto International, but what it boils down to is our experience doing high-res land cover in Philadelphia.  Before I highlight the key points (who reads anything more that 140 characters anyway?) I did want to thank Sarah Low, formerly with the City of Philadelphia and now with the Forest Service, for all of her help and valuable feedback.  Funding came from ARRA grant, "Restoring Ecosystems in Fairmount Park” (10-DG-11244419-025) .  Somehow the acknowledgements section was left off the article.

I will highlight some of the key points.

1) LiDAR is key.  We only had natural color (RGB) imagery.  It was really high-res, but the leaf-off characteristics made it less than useful for mapping tree canopy.  The LiDAR appeared to be acquired just as the leaves were coming out.  Although we had to do a bit of "canopy reconstruction" to deal with false gaps, the ability to see through shadows was amazing.

2) Object-Based Image Analysis techniques.  Incorporating contextual information was really important.  You just cannot do that without OBIA.
3) Distributed processing.  We integrated imagery, LiDAR, and vector data - literally billions of pixels, points, lines, and polygons.  Processing had to be efficient so that we could continually test and refine our approach.  It simply cannot be done using 32-bit single-core processing.  OBIA is resource intensive.  As I write this I am pricing out 192GB of RAM at Crucial.com.
4) 80% is easy.  It literally took us 2 days to exceed 80% accuracy, weeks to exceed 90% accuracy, then months to get to our target of 95% accuracy.  We did over 30,000 manual corrections (yes you read that right) for only a 1% gain in accuracy, although people said it looked a lot better after manual corrections.
5) It's the people more than the techniques.  Too often we focus on the technology, whether it is the type of data or the methods (OBIA vs. pixel-based).  Although it is difficult to quantify we felt that the expertise and experience of the people working on the project trumps just about everything.  There are all sorts of little decisions along the way that have to be made, and these decisions have to be made by people.

Planning for the end user

I often think that our remote sensing acquisition strategy is very much a "Field of Dreams," in that we hope that "if we build it, he will come."  What we hope in the case of remotely sensed data is not for long-dead baseball players to show up, but for the data to enable us to make better decisions.  This doesn't always happen.  We are far better at collecting data than we are at extracting meaningful information from that data.  Try getting your hands on NASA ICESat data, you won't be able to read it using any common proprietary or open source GIS package.

Today and tomorrow I am at a workshop in Boulder being run by NEON, the National Ecological Observation Network.  In the coming years NEON is going to start collecting massive amounts of remotely sensed data for selected sites across the United States.  NEON's Airborne Observation Platform is impressive - it includes both a hyperspectral and a full waveform LiDAR sensor.  What I think is more impressive is that NEON is thinking very hard about the data products that they will provide to end users.  There is no way they will be able to meet the needs of everyone, but it's nice to see the scientific community moving away from providing simply raw data (Level 0) or products with minimum processing (Level 1) to products in common geospatial formats that those with limited remote sensing expertise will be able to use (Level 2-6).

Getting started with eCogniton webinar recording

A recording of the AmericaView sponsored webinar, Getting Started with eCognition, that I gave today is now available for viewing via this link.  You may also be interested in another video, Segmentation Algorithms in eCognition.  The segmentation video uses the same data and contains a link to download the data from the eCognition Community site.