[GRASS-dev] On (Landsat) imagery naming patterns

[Yann Chemin]

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" <nik at nikosalexandris.net>
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20130220/e6219b79/attachment.html>