[GRASS-user] i.landsat.toar not working with band 6 of Landsat 7

GRASS GRASS user
1

hi grass users,

i found a problem when running i.landsat.toar with Landsat 7,
then i’ve eventually found in gis-stackexchange a “tricky” way to solve it:
http://gis.stackexchange.com/questions/133053/i-landsat-toar-doesnt-work-with-band-6-of-landsat-7-in-grass-7

i found it a bit clunky and thought to let you know in case someone wants to deal with this issue…

smiles,
Anna

NB: I’m running grass 7.0.2RC2 (64bit) on Ubuntu

2

On Sun, Feb 7, 2016 at 9:48 PM, anna zanchetta <ciupava@gmail.com> wrote:

hi grass users,

i found a problem when running i.landsat.toar with Landsat 7,
then i've eventually found in gis-stackexchange a "tricky" way to solve it:
http://gis.stackexchange.com/questions/133053/i-landsat-toar-doesnt-work-with-band-6-of-landsat-7-in-grass-7

i found it a bit clunky and thought to let you know in case someone wants to
deal with this issue...

So, you refer to "renaming LE70010752014040CUB00_B6_VCID_1 to
LE70010752014040CUB00_B61 do the trick." ?

Indeed suboptimal. But I guess that pattern matching would make the
interface more complicated.
Maybe other developers have an idea?

Best
Markus

3

yes, i was referring to that.
i think the problem is connected to the fact that i.landsat.toar works recursively on all bands
which is what makes this command comfortable but in the same time it doesn’t allow to calculate the TOAR for a specific band, in case one would like to do so

thanks,

Anna

···

On Mon, Feb 8, 2016 at 12:00 AM, Markus Neteler <neteler@osgeo.org> wrote:

On Sun, Feb 7, 2016 at 9:48 PM, anna zanchetta <ciupava@gmail.com> wrote:

hi grass users,

i found a problem when running i.landsat.toar with Landsat 7,
then i’ve eventually found in gis-stackexchange a “tricky” way to solve it:
http://gis.stackexchange.com/questions/133053/i-landsat-toar-doesnt-work-with-band-6-of-landsat-7-in-grass-7

i found it a bit clunky and thought to let you know in case someone wants to
deal with this issue…

So, you refer to “renaming LE70010752014040CUB00_B6_VCID_1 to
LE70010752014040CUB00_B61 do the trick.” ?

Indeed suboptimal. But I guess that pattern matching would make the
interface more complicated.
Maybe other developers have an idea?

Best
Markus

4

Dear Anna,
We solved such problems by writing python script for automated rename of files corresponded to ETM+ thermal bands before processing in Grass as we often have to work with many images.
in the case of single images it is not a problem to rename it to format LE........B61 and B62. Then after ETM+ data import to GRASS, i.landsat.toar work properly.

--
Best regards,

Maria V. Kozlova

š /------------------------------------\
š Information System Lab. (ISysLab)
š State Oceanographic Institute,
š Kropotkinsky per., 6,
š MOSCOW, 119034,
š RUSSIA
š ------------------------------------
š tel. š š+7 499 246 6448
š fax. š š+7 499 246 7288
š mailto: škclo@yandex.ruš
š \------------------------------------/

08.02.2016, 01:17, "anna zanchetta" <ciupava@gmail.com>:

yes, i was referring to that.
i think the problem is connected to the fact that i.landsat.toar works recursively on all bands
which is what makes this command comfortable but in the same time it doesn't allow to calculate the TOAR for a specific band, in case one would like to do so

thanks,

Anna

On Mon, Feb 8, 2016 at 12:00 AM, Markus Neteler <neteler@osgeo.org> wrote:

On Sun, Feb 7, 2016 at 9:48 PM, anna zanchetta <ciupava@gmail.com> wrote:

hi grass users,

i found a problem when running i.landsat.toar with Landsat 7,
then i've eventually found in gis-stackexchange a "tricky" way to solve it:
http://gis.stackexchange.com/questions/133053/i-landsat-toar-doesnt-work-with-band-6-of-landsat-7-in-grass-7

i found it a bit clunky and thought to let you know in case someone wants to
deal with this issue...

So, you refer to "renaming LE70010752014040CUB00_B6_VCID_1 to
LE70010752014040CUB00_B61 do the trick." ?

Indeed suboptimal. But I guess that pattern matching would make the
interface more complicated.
Maybe other developers have an idea?

Best
Markus

,

_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

5

Thanks Maria for your reply.
The system you used it’s exactly the “tricky” one I was referring to: it solves the situation locally but the problem still remains.

Maybe some developer already started to put his hands on the code, otherwise I’d be really happy to try to do it myself, but I’m really a newbie so any tip/direction is welcome…

Anna

···

On Mon, Feb 8, 2016 at 9:25 AM, Kozlova Maria <kclo@yandex.ru> wrote:

Dear Anna,
We solved such problems by writing python script for automated rename of files corresponded to ETM+ thermal bands before processing in Grass as we often have to work with many images.
in the case of single images it is not a problem to rename it to format LE…B61 and B62. Then after ETM+ data import to GRASS, i.landsat.toar work properly.

–
Best regards,

Maria V. Kozlova

/------------------------------------
Information System Lab. (ISysLab)
State Oceanographic Institute,
Kropotkinsky per., 6,
MOSCOW, 119034,
RUSSIA

tel. +7 499 246 6448
fax. +7 499 246 7288
mailto: kclo@yandex.ru
------------------------------------/

08.02.2016, 01:17, “anna zanchetta” <ciupava@gmail.com>:

yes, i was referring to that.
i think the problem is connected to the fact that i.landsat.toar works recursively on all bands
which is what makes this command comfortable but in the same time it doesn’t allow to calculate the TOAR for a specific band, in case one would like to do so

thanks,

Anna

On Mon, Feb 8, 2016 at 12:00 AM, Markus Neteler <neteler@osgeo.org> wrote:

On Sun, Feb 7, 2016 at 9:48 PM, anna zanchetta <ciupava@gmail.com> wrote:

hi grass users,

i found a problem when running i.landsat.toar with Landsat 7,
then i’ve eventually found in gis-stackexchange a “tricky” way to solve it:
http://gis.stackexchange.com/questions/133053/i-landsat-toar-doesnt-work-with-band-6-of-landsat-7-in-grass-7

i found it a bit clunky and thought to let you know in case someone wants to
deal with this issue…

So, you refer to “renaming LE70010752014040CUB00_B6_VCID_1 to
LE70010752014040CUB00_B61 do the trick.” ?

Indeed suboptimal. But I guess that pattern matching would make the
interface more complicated.
Maybe other developers have an idea?

Best
Markus

,

grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

6

I agree, Anna!

Nonetheless, this could be helpful (see the attached)

–
Best regards,

Maria V. Kozlova

/------------------------------------
Information System Lab. (ISysLab)
State Oceanographic Institute,
Kropotkinsky per., 6,
MOSCOW, 119034,
RUSSIA

tel. +7 499 246 6448
fax. +7 499 246 7288
mailto: kclo@yandex.ru
------------------------------------/

16.02.2016, 13:27, “anna zanchetta” ciupava@gmail.com:

Thanks Maria for your reply.
The system you used it’s exactly the “tricky” one I was referring to: it solves the situation locally but the problem still remains.

Maybe some developer already started to put his hands on the code, otherwise I’d be really happy to try to do it myself, but I’m really a newbie so any tip/direction is welcome…

Anna

On Mon, Feb 8, 2016 at 9:25 AM, Kozlova Maria <kclo@yandex.ru> wrote:

Dear Anna,
We solved such problems by writing python script for automated rename of files corresponded to ETM+ thermal bands before processing in Grass as we often have to work with many images.
in the case of single images it is not a problem to rename it to format LE…B61 and B62. Then after ETM+ data import to GRASS, i.landsat.toar work properly.

–
Best regards,

Maria V. Kozlova

/------------------------------------
Information System Lab. (ISysLab)
State Oceanographic Institute,
Kropotkinsky per., 6,
MOSCOW, 119034,
RUSSIA

tel. +7 499 246 6448
fax. +7 499 246 7288
mailto: kclo@yandex.ru
------------------------------------/

08.02.2016, 01:17, “anna zanchetta” <ciupava@gmail.com>:

yes, i was referring to that.
i think the problem is connected to the fact that i.landsat.toar works recursively on all bands
which is what makes this command comfortable but in the same time it doesn’t allow to calculate the TOAR for a specific band, in case one would like to do so

thanks,

Anna

On Mon, Feb 8, 2016 at 12:00 AM, Markus Neteler <neteler@osgeo.org> wrote:

On Sun, Feb 7, 2016 at 9:48 PM, anna zanchetta <ciupava@gmail.com> wrote:

hi grass users,

i found a problem when running i.landsat.toar with Landsat 7,
then i’ve eventually found in gis-stackexchange a “tricky” way to solve it:
http://gis.stackexchange.com/questions/133053/i-landsat-toar-doesnt-work-with-band-6-of-landsat-7-in-grass-7

i found it a bit clunky and thought to let you know in case someone wants to
deal with this issue…

So, you refer to “renaming LE70010752014040CUB00_B6_VCID_1 to
LE70010752014040CUB00_B61 do the trick.” ?

Indeed suboptimal. But I guess that pattern matching would make the
interface more complicated.
Maybe other developers have an idea?

Best
Markus

,

grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

(attachments)

VCID_REMOVE.py (1.85 KB)