Hmmm g.rename originalnname with newname (sed substitute "." with "_" in originalname)
I agree this additional step is less elegant in the work flow Y On Feb 20, 2013 12:31 PM, "Nikos Alexandris" <[email protected]> wrote: > 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
_______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
