[GRASS-user] Estimating Albedo from Landsat

Hamish hamish_b at yahoo.com
Tue Sep 14 03:01:14 EDT 2010


I've just made some small changes to i.landsat.acca and i.landsat.toar in
svn which shouldn't change the behaviour of the module at all, just do
some more error checks and make better use of libgis (writes out more
metadata etc. e.g. added units=Kelvin to band 6 metadata, not sure about
W/m^2 for others or how safe it is to include non-ascii chars in the units
field? (micron "u", etc.)).

there were some troubles if e.g. production date was not set, it would
continue anyway with a very old date. (it would be nice to have a check
that production date is not before acq. date as well, but that's not
in it yet.)
also if the date format was not right it would continue anyway with a
bogus value and crazy value for solar distance, etc.

I've got an old landsat-5 TM scene here from 2004 which seemed to run ok.
i.landsat.toar didn't recognize the header.dat metadata file, so I had
to enter some values by hand.

band 6 temperatures do not look very plausible (30 degC ocean and -6 degC
land) on a sunny autumn day.

i.landsat.acca then does a really bad job finding the clouds, but I think
that's just because the toar.6 band is so badly wrong. ISTR doing the 
temperature calc with r.mapcalc from Markus and Helena's book some years
ago, I don't remember it being so badly wrong then. there's some commented
out landsat-5 code in i.landsat.acca though, maybe it is as yet unfinished?

It would be good to compare with i.atcorr, but I haven't figured out the
exact recipe for that module yet.

Probably we should concentrate on the North Carolina dataset for common
tests... its landsat mapset has:


not enough metadata for toar, might have to redownload the scene from


metadata from hist/ file:

should we be calculating the sat_zenith= param from SUN_AZIMUTH in the
metadata file, or is that something else? I just used the default 8.2 deg.

> > > 1. the "LT51830332007248MOR00.meta" isn't read correctly or
> > > the module is  looking for a string other than the "date_acquired =
> > > 20070905" string which is the only "date-string" included in the
> > > ".meta" file

the program wants "yyyy-mm-dd". (the test for that could still be improved)

> > > 2. does not recognize the solar elevation value

for me that worked (at least it was reported as given on the command line
when the -v show settings flag was used)

> > > 3. after manually providing the "solar_elevation" and the
> > > "product_date" and using the "-v" flag, some random (?) segfaults
> > > occur.

do you still get those with the new svn version?

> > > 4. without the "-v" flag it runs but seems to take too much
> > > time? OK, the image set is large ( 7654 cols x 7127 rows x 7 bands).

were any other values bogus? e.g. earth-sun distance not near 1AU?
probably a memory bug if the time variable was in the millions, etc.

> Oh man, I guess I am doing something wrong [ again :-( ].
> It takes too much  time here. I broke the process after >30 min
> and set up a new (smaller) computational region (of my interest).

AFAIU at least i.landsat.acca ignores the region settings (why?), and
I'm not sure if i.landsat.toar does or not, I suspect it ignores it as
well and works on the full image.

> I'll give it another try and report back.


> Thanks for all of your work Hamish, Nikos

really I've just made some minor tests and tidying of the code, the credit
belongs to others. I'm still learning these modules as much as anybody
else ..


ps- the grass7 patches will be badly out of date now, as they are a pain
to update for each rev, I'll wait at least until the libgis/libraster
G_fatal_error() and other messages are sync'd with the standardized
versions before cutting a new one of those. or at least until a little
dust settles.


More information about the grass-user mailing list