<p>Hmmm g.rename originalnname with newname (sed substitute "." with "_" in originalname)</p>
<p>I agree this additional step is less elegant in the work flow<br>
Y</p>
<div class="gmail_quote">On Feb 20, 2013 12:31 PM, "Nikos Alexandris" <<a href="mailto:nik@nikosalexandris.net">nik@nikosalexandris.net</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Greetings to the dev-list.<br>
<br>
I successfully tested <i.histo.match>, by feeding it with 12 Landsat scenes<br>
(working on identical bands, different Path/Row tiles) in one go.  It works and<br>
I really enjoy it.<br>
<br>
However, there is some "problem":<br>
<br>
<i.histo.match> wont accept the "." character as part of the image/raster map<br>
names.  This is an SQL restriction (thanks Luca D for the quick help) as the<br>
module utilises sqlite internally for the calculations.<br>
<br>
Although I am familiar with this restriction,  due to pressing deadlines, I<br>
overlooked that "point" while designing my workflow and decided to go for a<br>
specific naming pattern for all Landsat scenes at each (pre-)processing step<br>
(working currently on 25+ tiles, for summer and winter that cover the entire<br>
Greek territory).<br>
<br>
In addition,  the respective manuals for modules like <i.landsat.toar>,<br>
<i.landsat.acca>, <i.topo.corr> hold in their examples/descriptions (thus,<br>
someone can easily interpret that these modules "encourage" the use of) names<br>
like "B.", "B.toar", "toar.5", et.c.<br>
<br>
<br>
I certainly like to keep, while on intermediate processing steps, long names<br>
whose parts are separated by either the underscore character ( _ ) or the dot<br>
character ( . ).<br>
<br>
This is, from my point of view, an inconsistency which adds-up some confusion<br>
-- especially to new users who will try/need to use <i.histo.match> at some<br>
point.<br>
<br>
<br>
As changing the module or adding internally a solution will add complexity, I<br>
guess it is better to adhere to some kind of "strict" naming rules/patterns in<br>
the manuals' examples, in the wiki and elsewhere?<br>
<br>
In time I will try to propose new wording and examples for all Landsat related<br>
modules/manuals I have used/read.<br>
<br>
GRASS has (almost) everything required for a "perfect" Landsat processing<br>
work-flow.  This small inconsistency breaks the harmony :-).<br>
<br>
Best, N</blockquote></div>