Dear GRASS-GIS developers and users,
I just want to share my satisfaction using the following (all?) Landsat
related modules available in GRASS-GIS, both core and AddOns:
i.landsat.trim, i.landsat.toar, i.landsat.dehaze or i.atcorr, i.landsat.acca,
i.topo.corr , i.landsat.rgb
All in all, given a proper handling, the modules do their job and they do it
well with Landsat5TM imagery. Only a few comments out of a quick, mainly
visual, assessment.
i.landsat.trim -- it might be that it won't work as expected sometimes,
requires experimenting with the buffer? This is known.
i.atcorr -- requires some homework but it does it's job. It would be great *if
possible* to have done most of the metadata-retrieving work automatically for
all bands of a scene. In case it fails, force the user to do it manually.
Thank you to all people worked hard to get these modules in GRASS-GIS, Nikos
Hi Nikos and all.
As regards the <i.landsat.trim> module: it’s just an experiment to do something strange with Landsat 
But I will try to rewrite it in Python with a bit more logic. Thanks for testing it
On Wednesday 16 of January 2013 22:21:03 Alexander Muriy wrote:
Hi Nikos and all.
As regards the <i.landsat.trim> module: it's just an experiment to do
something strange with Landsat
But I will try to rewrite it in Python with a bit more logic. Thanks for
testing it
Yes, we already had some discussion about it. I find, however, that it works
well most of the times -- so far. It didn't play nice only once.
I consider such a module as very useful for Landsat pre-processing tasks.
Thank you for all of your efforts, Nikos
Alexander Muriy:
..
...will try to rewrite it in Python with a bit more logic.
..
Alex,
I do have some modifications to propose:
1. It would be nice to use the official WRS2 Path/Row tiles as MASKs with the "-
m" (or another, newer) switch, so the module works through all bands of a
scene and trims them based on the MASK. It would take for the users to get the
Path/Row tiles of his interest, import them and, perhaps rasterise them
(although this last step can be integrated in i.landsat.trim).
What do you think? How difficult would that be? Also, this means that both the
rast_buffer and the gener_thresh parameters will be no longer used in this
case. Right?
Currently I am doing this work for many Landsat scenes -- scripting or one-
liners in bash as this is the fastest way for me.
2. The way the "output_prefix" parameter works (e.g.: "Prefix for output raster
map, Example: 'trim' generates B.1.trim, B.2.trim, ... "), makes me think that
it should be actually named "output_suffix".
Best, Nikos