1

This question already has an answer here:

In my application of i.landsat.toar, I am coming across an issue for which there is previous precedence.

LANDSAT 8 i.landsat.toar error GRASS 7

Computer Basics: Data Used: Landsat 8; Operating System: Windows 7 32 bit; Grass version: 7.0.0.1 (Stable version) I have tried with 7.02.RC1-1 version, landsat 7 data, but there was no difference)

My metadata file records the following values:

SUN_ELEVATION = 49.52284282
EARTH_SUN_DISTANCE = 0.9939432

Also,

RADIANCE_MULT_BAND_1 = 1.2709E-02
RADIANCE_ADD_BAND_1 = -63.54622

Similarly, none of the other band's radiance parameter is zero

Issue # 01: The code is not picking up the Earth-sun distance or the Solar elevation angle from the metadata file. I even manually provided the data through the tool box 'Metadat' tab, but no difference made. There is a warning stating beforehand that it will be overwritten. Any explanation as to why?

Issue # 02: As par USGS reference: http://landsat.usgs.gov/Landsat8_Using_Product.php , at-sensor radiance = RADIANCE_MULT_BAND_X * DN + RADIANCE_ADD_BAND_X However, the output is not using the metadata values. Instead using 0. Any explanation?

I am coming across identical situation like the previous case, evident from the attached command output. Any guideline for solution (if required) or explanation for the circumstance (if this is how it is supposed to be)?

Command Output:

Mon Nov 30 02:30:07 2015)                                                      
i.landsat.toar --verbose input=LC81370442015300LGN00_B output=TOAR_B           
metfile=E:\LandCover_Classification\LC81370442015300LGN00\LC81370442015300LGN00_MTL.txt sensor=oli8 date=2015-10-27 sun_elevation=49.52284282 product_date=2015-10-27
Metada file is MTL file: new format
RADIANCE & QUANTIZE from  MIN_MAX_(RADIANCE|PIXEL_VALUE)
WARNING: ESUN evaluated from REFLECTANCE_MAXIMUM_BAND
WARNING: Overwriting solar elevation of metadata file
 LANDSAT: 8 SENSOR: OLI/TIRS
 ACQUISITION DATE 2015-10-27 [production date 2015-10-27]
   Earth-sun distance    = 0.00000000    /* Not using data from metedata file */
   Solar elevation angle = 0.00000000    /* Not using data from metedata file */
   Atmospheric correction: UNCORRECTED
-------------------
 BAND 1 (code 1)
   calibrated digital number (DN): 0.0 to 0.0
   calibration constants (L): -12921358752688410020721955688
115920665908972319060407734713394360286772747253243677217490
460072444863477515873024485329406587544102380733964553773209
470174482838252720913256857159594704835548262628428491099806
824007743633806603939891682505986476500036813488471710794679
812718339464991426221557174273397692968656770569470784372007
509468405212310749439605762528891325540967113062645506423667
906579067093107701745245095315224335459710698106660563473926
87291100325217965687908018786027399961269512990865888378880.
00000 to 0.00000
   at-sensor radiance = -0.00000000 * DN + -0.00000 /* Not using data from metedata file */
   mean solar exoatmospheric irradiance (ESUN): 0.00000
   at-sensor reflectance = radiance / -0.00000
-------------------
 BAND 2 (code 2)
   calibrated digital number (DN): 0.0 to 0.0
   calibration constants (L): -0.00000 to 0.00000
   at-sensor radiance = -0.00000000 * DN + -0.00000
   mean solar exoatmospheric irradiance (ESUN): -0.00000
   at-sensor reflectance = radiance / -0.00000 

Update: The earlier question responses suggested, the issue was resolved. However, the question is two years old and the problem reappeared in my case. So, I assumed; there was additional changes incoporated in the Metadata file. Hence, the issue reappeared and I was seeking some clarification. Since asking the question, I came across the following thread.

http://osgeo-org.1560.x6.nabble.com/i-landsat-toar-comments-have-only-0-value-td5034509.html

It seems, though the command output and r.info shows no data intake from Metadata file, using (-p flag) shows the data is indeed considered and subsequent Reflectance clculations are properly conducted. Apparently, attempts to fix the bug was done but the issue of zero in command output exists till date (Which will confuse anybody). If this question is redundant, I can remove it. However, in my opinion, a clarification for new users about the issue or finally fixing the bug is warranted.

marked as duplicate by whuber Dec 7 '15 at 14:47

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • Have you tried to do it only by giving the path to MTL and not by setting manually the parameters? Something like i.landsat.toar input_prefix=203_30. output_prefix=_toar \ metfile=p203r030_7x20010620.met ? (grass.osgeo.org/grass64/manuals/i.landsat.toar.html) – geo_dd Dec 1 '15 at 9:53
  • Yes, I have explored that scenario as well. I am trying to get at sensor reflectance (no r flag) but that shouldn't cause such situation (in my opinion). Here's the command I used, i.landsat.toar --verbose input=LC81370442015300LGN00_B output=TOARFL_B metfile=E:\LandCover_Classification\LC81370442015300LGN00\LC81370442015300LGN00_MTL.txt sensor=oli8 – İmtiaz Dec 1 '15 at 10:44
  • 2
    Well I am not sure but I think the "problem" is the "new format" of the MTL file. Take a look here gis.stackexchange.com/questions/72259/… (perhaps an update?). – geo_dd Dec 1 '15 at 10:51