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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
