Greetings to the dev-list.
I successfully tested <i.histo.match>, by feeding it with 12 Landsat scenes
(working on identical bands, different Path/Row tiles) in one go. It works and
I really enjoy it.
However, there is some "problem":
<i.histo.match> wont accept the "." character as part of the image/raster map
names. This is an SQL restriction (thanks Luca D for the quick help) as the
module utilises sqlite internally for the calculations.
Although I am familiar with this restriction, due to pressing deadlines, I
overlooked that "point" while designing my workflow and decided to go for a
specific naming pattern for all Landsat scenes at each (pre-)processing step
(working currently on 25+ tiles, for summer and winter that cover the entire
Greek territory).
In addition, the respective manuals for modules like <i.landsat.toar>,
<i.landsat.acca>, <i.topo.corr> hold in their examples/descriptions (thus,
someone can easily interpret that these modules "encourage" the use of) names
like "B.", "B.toar", "toar.5", et.c.
I certainly like to keep, while on intermediate processing steps, long names
whose parts are separated by either the underscore character ( _ ) or the dot
character ( . ).
This is, from my point of view, an inconsistency which adds-up some confusion
-- especially to new users who will try/need to use <i.histo.match> at some
point.
As changing the module or adding internally a solution will add complexity, I
guess it is better to adhere to some kind of "strict" naming rules/patterns in
the manuals' examples, in the wiki and elsewhere?
In time I will try to propose new wording and examples for all Landsat related
modules/manuals I have used/read.
GRASS has (almost) everything required for a "perfect" Landsat processing
work-flow. This small inconsistency breaks the harmony :-).
Best, N