[GRASS-user] Estimating Albedo from Landsat
Nikos Alexandris
nikos.alexandris at felis.uni-freiburg.de
Wed Sep 15 09:14:40 EDT 2010
Nikos wrote:
> > ... I realised that I don't really have the "correct" metadata file for
> > the scene I was given. The "meta" file available at Glovis is not really
> > the complete set of meta-information (is my guess -- missing
> > "sat_zenith=" value for example).
Hamish wrote:
> fwiw with Landsat-7 downloads from GloVis I get files like
> L7*_MTL.txt which works with the i.landsat.toar metfile= option, it
> includes SUN_ELEVATION and SUN_AZIMUTH but nothing obvious about zenith
> that I can see.
Check that out (got some metadata files finally -- no ".met" file though) --
just a part of one of the ".lea" files, i.e. the lea_01.txt:
--%<---
------- Map proj. ancillary rec. number 1 -------
record sequence number = 3
1-st record subtype code = 36
record type code = 36
2-nd subtype code = 18
3-rd subtype code = 9
length of this record = 4320
input line nom. number of scene pixel = 7452
input image nom. number of scene lines = 6884
nominal scale of input inter-pixel... = 30.0000000
nominal scale of input inter-line... = 30.0000000
image skew at scene centre = 2.9918563
UTM datum and zone number for input... = GRS80 34
nom. WRS northing of centre in metres = 0.0000000
nom. WRS easting of centre in metres = 0.0000000
northing of input image centre in metres= 4309451.5000000
easting of input image centre in metres = 723735.5625000
vert. offset of scene centre to WRS... = 0.0000000
horiz. offset of scene centre to WRS... = 0.0000000
orient. of input image centre in degrees= -8.8923416
blanks =
num. of pixels per line of proc. image = 6336
num. of lines per line of proc. image = 6884
scale of proc. inter-pix. distance... = 30.0000000
scale of proc. inter-line distance... = 30.0000000
UTM zone number for processed image = 34
line number in proc. image at WRS... = 3442.0000000
pixel number in proc. image at WRS... = 3726.0000000
orientation of proc. image centre... = -8.8923416
nomimal satellite orbital inclination = 98.1999969
nomimal ascending node = 103.0374985
nomimal altitude in metres = 712278.3125000
nom. ground speed in metres per second = 6746.4267578
satellite heading in degrees = 10.5169640
spare =
cross-track field of view in degrees = 15.3900003
sensor scan rate in scans per second = 13.9934511
sensor active sampli. rate in samples...= 104047.4453125
sun elevation angle at WRS centre... = 52.4986238
sun azimuth angle at WRS centre... = 142.9811328
top left latitude = 39.8559723
top left longitude = 22.3088074
top right latitude = 39.7971458
top right longitude = 24.9181290
bottom left latitude = 37.9956665
bottom left longitude = 22.2750587
bottom right latitude = 37.9405975
bottom right longitude = 24.8173637
first ten zero fill =
------- Radiom. ancillary rec. number 1 (total 1) -------
record sequence number = 4
1-st record subtype code = 63
record type code = 36
2-nd subtype code = 18
3-rd subtype code = 9
length of this record = 4320
band number = 1
lower radiance limit = -15
upper radiance limit = 1521
blanks =
offset coefficient = -1.5000000000e+00
gain coefficient = 6.0235294118e-01
[...]
radiance to reflectance conv. factor = 2.0569763e-03
--%<---
Is "satellite heading in degrees = 10.5169640" the "sat_zenith" value ?
> looking in the source code, landsat_met.c (which parses the metadata file)
> isn't looking for satellite zenith- it only comes from the command line,
> and in landsat.c it seems that only the DOS2b, DOS3, and DOS4 correction
> methods actually use it. So for uncorrected method (which I guess is the
> appropriate one if the task is cloud detection??) ...
I think this is the appropriate way to go for "acca"
> ...that variable doesn't matter.
ok.
# so, here it goes... seems to run fine
i.landsat.toar band_prefix=landsat_postfire_east_sterea_ellas
method=uncorrected sensor=5 date=2007-09-05 solar_elevation=52.4986238
product_date=2007-09-05
> > the output values (even if the sat_zenith value I used is
> > non-sense) seem to be as expected for radiance/reflectance values
>
> good.
>
> > (e.g. band 1,
> > min=-0.00308741863579021, max=0.39202091888652) .
>
> I think this already got answered a couple of days ago, but is the
> reflectance on a scale from 0.0-1.0 (0-100%)?
>
> and what are the W/m^2-like units for radiance used for the output maps?
# hmmm...
r.info landsat_postfire_east_sterea_ellas.toar.6 -r
min=203.36601783578
max=319.083636050686
No way the min value is true ( 203 K = -70.15 C -- irrational for Greece - for
the moment! -)
The max value (319 K = 45.85 C) seems to fit for Greece but not for September!
Maybe for July/August.
> > Is the following the problem (you expect-ed)? I see strange
> > characters, e.g.:
> >
> > -------------------
> >
> > BAND 1 (code 1)
> >
> > calibrated digital number (DN): 1.0 to 255.0
> > calibration constants (L): -1.520 to 193.000
> > at-sensor radiance = 0.76583 � DN + -2.28583
> > mean solar exoatmospheric irradiance (ESUN): 1983.000
> > at-sensor reflectance = radiance / 492.32067
> >
> > -------------------
> >
> > BAND 2 (code 2)
> >
> > calibrated digital number (DN): 1.0 to 255.0
> > calibration constants (L): -2.840 to 365.000
> > at-sensor radiance = 1.44819 � DN + -4.28819
> > mean solar exoatmospheric irradiance (ESUN): 1796.000
> > at-sensor reflectance = radiance / 445.89406
>
> no, that is something else, it's a non-ASCII char in the fprintf()
> string. Maybe it will show up in the email: it's the dot multiplier "·".
Yep, it shows in the e-mail and I now understand that I was to fast "reading"
those lines before.
> for me in "less main.c" it shows up as <B7>, in nedit and vi I see the dot.
> I guess that should be %c + the code for it, or just "*" ?
or simply "x" ?
> .. displaying it will be terminal and locale dependent ..
More information about the grass-user
mailing list