[GRASS-user] Estimating Albedo from Landsat

[Hamish]

Nikos wrote:
> > Downloaded:
> > - extra: LT50160351988258XXX03 (includes visible
> > clouds - maybe good for testing?)

in the GloVis preview I only see a few clouds in the NE corner
for that date. (Sept 14, 1988)


Maybe 1991/10/25 is another good scene for a cloud test? (looks
like 20% high cumulus with shadows)

Note the % cloud cover in the GloVis previewer is (AFAIU) using
the same ACCA algorithm as i.landsat.acca, so the result should
be similar. (??)
For the Sept 14, 1998 example the GloVis info says 0% cloud
cover, but maybe that data is old and the latest ACCA says
something else?


> # rgb colors for 742
> i.landsat.rgb r=lsat5_1988.2 g=lsat5_1988.4 b=lsat5_1988.7
> strength=96
> d.rgb r=lsat5_1988.2 g=lsat5_1988.4 b=lsat5_1988.7 #
> obvious clouds

maybe i.landsat.dehaze is worth trying before i.landsat.rgb?

> # toar
> i.landsat.toar band_prefix=lsat5_1988 method=uncorrected \
>   sensor=5 product_date=1988-09-14 date=1988-09-14 \
>   solar_elevation=48.6773844

do not assume production date is the same as acq. date; check
metadata values against values in the source code.
For the Mar 31, 2000 sample data it made a difference.

> # acca
> i.landsat.acca -5f2 band_prefix=lsat5_1988.toar \
>     output=lsat5_1988.toar.acca
> 
> # how many cats?
> r.info lsat5_1988.toar.acca -r
> min=6
> max=9

see r.category, r.stats -c, or d.legend for meaning of category
numbers. (6=cold cloud, 9=warm cloud, 2=shadow)


i.landsat.acca is in flux today, best to wait a few days ..
(some earlier improvements just got clobbered and new ones
introduced, so I'm unsure of where we are now)


> In the "acca" result:
> 
> - clouds are detected (cat=6), not that bad(ly) I suppose.
> Some filtering could push away the (rest of the) "noise". 

the cloud despeckle filter can remove some lone non-cloud cells
which are surrounded by cloud. after that I guess it's
r.neighbors or r.mfilter.


> - obvious mis-detections (commission errors) found within
>   - n=188310 s=168270 w=618870 e=636150 (bare ground?
> urban area? not sure 
> about the confusing land cover/class here...)
>   - n=219030 s=180510 w=646410 e=655740 (road)

? maybe google maps satellite view helps if the landsat is too
coarse to ID features.

>   - in the borders due to the non-identical extent of
> all bands (!?)

I've seen something similar, maybe r.series to accumulate NULLs
in all input bands and use that as a MASK?
 
> - categories 7 and 8 seem to be empty, category 9 looks
> very messy

cat 7,8 are undefined, cat 9 probably has more false positives
in warm land, cat 6 (cold cloud) probably has more problems in
snowy areas.
 
> Could it be that non-cloudy acquisitions are mistreated by
> the algorithm?

The paper by Irish listed in the i.landsat.acca man page is
worth reading, it explains a lot and points out where the
algorithm does not do well.


> I can't clearly recognise clouds in the landsat
> scenes included in NC data set 
> (both the 1987 and the 2000 scenes).

I'd guess that they were specifically chosen to avoid days with
obscuring clouds.


> Will (then) the algorithm work (only) with (very) cloudy
> data?

One thing the paper mentions, and I've observed, is that it does
not do well with thin wispy cirrus clouds. Apparently MODIS does
a bit better there because it has a detector in the needed 2um
range to pick those up, while the Landsat only has 11um which
misses those cloud tops. (IIRC)



fyi, I've just added what we know about the NC 2008 dataset
Landsat images to the grass wiki:
 http://grass.osgeo.org/wiki/LANDSAT#Sample_data

I'm downloading them now.. I expect they'll be reprocessed
versus the metadata calibration values shipped with the dataset.
(??)


Hamish