USGS Q&A: adding value to Landsat imagery with LEDAPS

January 16 2014 by Chris Herwig

As Bruno described last month, we leverage the Landsat Ecosystem Disturbance Adaptive Processing System, or LEDAPS, software routines to process Landsat Level 1 images to surface reflectance. This conversion is one of the most important steps in our larger imagery processing pipeline.

Surface Reflectance

Surface reflectance measures the ratio of solar radiation reflected from, rather than absorbed by, the Earth’s surface. To achieve the most accurate reflectance measurement, the effects of the atmosphere need to be taken into account. Landsat surface reflectance products contain the measurements the sensor would capture under ideal conditions — held right above the Earth’s surface without any effects caused by the atmosphere.

Surface reflectance products are ideally suited for change detection and monitoring applications, as removing the atmospheric effects makes it easier to compare images over time. Many higher-level surface geospatial analyses — including vegetation indexes, albedo, Leaf Area Index (LAI), burned area, land cover, and land cover change — rely on surface reflectance products.

The difference is striking — as you can see in the before and after over Hong Kong below.

Left: Original L1 image. Right: Surface reflectance, after LEDAPS Atmospheric Correction.

Q&A

We recently got in touch with Calli Jenkerson, Senior Scientist at the U.S. Geological Survey (USGS), and John Dwyer, Project Scientist for the Landsat Data Continuity Mission (LDCM) ground system, for a Q&A about LEDAPS' development and applications. (Note: We’ve added links to some of the concepts and resources Calli and John refer to in their answers)

What is the USGS' relationship to LEDAPS?

Calli & John @USGS: The USGS has assumed stewardship of the LEDAPS code. LEDAPS was developed by scientists from NASA Goddard Space Flight Center (NASA GSFC) and the University of Maryland under a project funded by NASA MEaSUREs. Once the NASA funding expired, the USGS worked collaboratively with the original developers to fix known issues, introduce some enhancements, and assume responsibility for maintaining the code.

The USGS assumed this responsibility because it was aligned with our program objectives to develop climate data records (CDRs) and essential climate variables (ECVs) from the 40+ year Landsat record of observations.

What does the LEDAPS software offer to end users of Landsat products?

Calli & John @USGS: LEDAPS is used to retrieve surface reflectance values from Landsat TM and ETM+ data. This involves the use of auxiliary data (ozone, water vapor, geopotential height, aerosol optical thickness) to correct for molecular scattering and absorption by atmospheric constituents.

How does LEDAPS improve on what came before it?

Calli & John @USGS: The standard Landsat products (Level-1T) that are distributed today are radiometrically calibrated (scaled radiances), and orthorectified using ground control points for precision correction and digital elevation models to correct for relief displacement. LEDAPS processes the Level-1T data to surface reflectance, which enables quantifying land surface change after having normalized the data for sensor viewing and solar illumination geometry and atmospheric correction.

Who are the intended users of LEDAPS?

Calli & John @USGS: The immediate stakeholders for these products are scientists, although accurately processed surface reflectance retrievals are useful for data visualization, academic researchers and educators.

What are some challenges associated with using LEDAPS? What problems doesn’t it solve?

Calli & John @USGS: The greatest uncertainty associated with the LEDAPS products is with the aerosol correction. The algorithms use an empirical relationship between the SWIR and visible bands to estimate the concentration of aerosols as inputs to the 6S radiative transfer model. Dark dense vegetation targets within the given Landsat scene are used to estimate the aerosol optical thickness, therefore this correction becomes tenuous when there is insufficient dark dense vegetation within a scene, i.e. semi-arid and arid regions. Desert areas and snow and ice covered regions are not handled well by LEDAPS.

Not all remote sensing applications require the use of surface reflectance data. Alternatively, top of atmosphere (TOA) reflectance can be used to normalize scene radiances due to variations in solar illumination, sensor viewing geometry, and seasonality (Earth-Sun distance).

In what ways does LEDAPS pre-processing provide a superior product to Level 1 for Landsat imagery applications?

Calli & John @USGS: Typically, surface reflectance is required for more quantitative analysis and modeling of geophysical (albedo) and biophysical (LAI, FAPAR) parameters, or to minimize uncertainties in quantifying landscape change. Surface reflectance is not necessarily required for mapping land cover, but it may yield improved estimations of changes in vegetation condition (e.g. leaf moisture content, vegetation stress).

Are there any aspects of the software routines that could use further refinement?

Calli & John @USGS: We are working with other researchers to improve methods for detecting clouds and cloud shadows at the pixel level. Others have investigated the bidirectional reflectance distribution function (BRDF) effects when mosaicking data over large areas and through time. The adjacency effect of neighboring pixels on the bidirectional reflectance function of target pixels also needs further research and understanding.

Any idea when the LEDAPS software user community can expect Landsat 8 support?

Calli & John @USGS: We hope to have a capability for surface reflectance processing of Landsat 8 OLI data sometime in 2014, hopefully in the first half. NASA is the funding sponsor for that work.


At Mapbox, we leverage LEDAPS to process Landsat Level 1 images to surface reflectance as part of our larger processing pipeline to deliver more and more zoom levels of Cloudless Atlas to our users. We’re grateful to Calli Jenkerson and John Dwyer of the USGS for their time chatting with us, and for the USGS and NASA’s commitment to developing open source code and promoting accessible open data policies.