Opened 7 years ago

Closed 6 years ago

#1997 closed defect (fixed)

i.landsat.toar for grass-dev is missing the option for landsat8

Reported by: vesnikos Owned by: grass-dev@…
Priority: normal Milestone: 7.0.0
Component: Imagery Version: svn-trunk
Keywords: i.landsat.toar Cc:
CPU: Unspecified Platform: All

Description

Hi,

I just noticed that i.landsat.toar module for grass7 is missing the option for the new landsat8 satelite , while i.landsat.toar for grass64 has is.

for reference for grass64 the sensor id is sensor=ot8 when invoking the module.

Change History (12)

comment:1 Changed 7 years ago by neteler

Type: enhancementdefect

The updates (fixes) in GRASS 7 where not backported properly to G6:

http://trac.osgeo.org/grass/log/grass/trunk/imagery/i.landsat.toar (r54898,r54904,r54907,r54910,r55068,r55114,r55499)

which prevented the following bugfixes provided by the original author to be applied to the version in GRASS 7: http://trac.osgeo.org/grass/log/grass/branches/releasebranch_6_4/imagery/i.landsat.toar (r53589,r54844,r55376)

Essentially this fork needs to be consolidated.

comment:2 in reply to:  1 Changed 7 years ago by mmetz

Replying to neteler:

The updates (fixes) in GRASS 7 where not backported properly to G6:

http://trac.osgeo.org/grass/log/grass/trunk/imagery/i.landsat.toar (r54898,r54904,r54907,r54910,r55068,r55114,r55499)

which prevented the following bugfixes provided by the original author to be applied to the version in GRASS 7: http://trac.osgeo.org/grass/log/grass/branches/releasebranch_6_4/imagery/i.landsat.toar (r53589,r54844,r55376)

Essentially this fork needs to be consolidated.

i.landsat.toar is now consolidated across all branches. The only difference is an option in trunk to print out selected metadata, absent in GRASS 6.x.

comment:3 Changed 7 years ago by neteler

Platform: LinuxAll
Version: unspecifiedsvn-trunk

For the record: r56905, r56906, r56907, r56908

vesnikos, please close the ticket if it works for you

comment:4 in reply to:  3 ; Changed 7 years ago by Nikos Alexandris

Replying to neteler:

For the record: r56905, r56906, r56907, r56908

It works for me (tried with 56906). Tested using the Landsat 8 scene (and respective MTL file) LC81260592013169LGN00(_MTL.txt).

comment:5 in reply to:  4 Changed 7 years ago by Nikos Alexandris

Replying to nikosa:

Replying to neteler:

For the record: r56905, r56906, r56907, r56908

It works for me (tried with 56906).

Retried with revision=56932M. All fine.

comment:6 Changed 7 years ago by vesnikos

some minor bugs during my tests:

1) Cosmetic typo at the description of sensor parameter:

It says "Required only if 'metfile' not given (recommended by sanity)" should be ""Required only if 'metfile' not given (recommended for sanity)

2) Band8 (panchomatic) has my nature 15m res. The algorithm uses the regions resolution , and you cannot do anything to override it. 3) timestamp in r.info reads none, the date of acquisition is in the metadata, so it should be properly implemented

eg: r.timestamp map=LC81840322013143LGN03_B10.toarr.1 date="$(date -d'$DATE_ACQUIRED $SCENE_CENTER_TIME' -u +'%d %b %Y %H:%M:%S.%N %z')"

comment:7 in reply to:  6 ; Changed 7 years ago by Nikos Alexandris

Replying to vesnikos:

some minor bugs during my tests:

2) Band8 (panchomatic) has my nature 15m res. The algorithm uses the regions resolution , and you cannot do anything to override it.

You can set the region resolution to the desired one! In my scripts I do that. Maybe in this case an exception could be done and let the module handle this?

3) timestamp in r.info reads none, the date of acquisition is in the metadata, so it should be properly implemented

This would be also nice!

eg: r.timestamp map=LC81840322013143LGN03_B10.toarr.1 date="$(date -d'$DATE_ACQUIRED $SCENE_CENTER_TIME' -u +'%d %b %Y %H:%M:%S.%N %z')"

You can get the date using

i.landsat.toar -p metfile=MTLFile.txt lsatmet=date

and the decimal time

i.landsat.toar -p metfile=MTLFile.txt lsatmet=time

though, the "input_prefix=Dummy" and "output_prefix=Dummy" must be defined.

For the records, if you import Landsat bands using the script found in GRASS-Wiki http://grasswiki.osgeo.org/wiki/LANDSAT#Automated_data_import, the timestamp is set correctly. However, i.landsat.toar does not take care to copy this over. Even, the right way would be to grep the info from the MTL file directly.

comment:8 in reply to:  7 ; Changed 7 years ago by Nikos Alexandris

Replying to [vesnikos]:

Maybe you can close this ticket as i.landsat.toar knows about Landsat8 now! We can open a new ticket for the other issues.

comment:9 Changed 7 years ago by hamish

1) ... (recommended for sanity)

done in all branches

comment:10 in reply to:  7 ; Changed 7 years ago by Nikos Alexandris

Replying to nikosa:

Replying to vesnikos:

some minor bugs during my tests:

2) Band8 (panchomatic) has my nature 15m res. The algorithm uses the regions resolution , and you cannot do anything to override it.

You can set the region resolution to the desired one! In my scripts I do that. Maybe in this case an exception could be done and let the module handle this?

This look more important than I thought in the beginning. Indeed, one needs to work-around that issue since there is no way to preserve the 15m-s of Band 8 using (the current) i.landsat.toar in one go.

comment:11 in reply to:  10 Changed 7 years ago by neteler

Replying to nikosa:

This look more important than I thought in the beginning. Indeed, one needs to work-around that issue since there is no way to preserve the 15m-s of Band 8 using (the current) i.landsat.toar in one go.

New ticket about the resolution issue: #2089

comment:12 in reply to:  8 Changed 6 years ago by neteler

Resolution: fixed
Status: newclosed

Replying to nikosa:

Replying to [vesnikos]:

Maybe you can close this ticket as i.landsat.toar knows about Landsat8 now! We can open a new ticket for the other issues.

Yes, closing (and also the other issue has been fixed).

Note: See TracTickets for help on using tickets.