[GRASS-dev] nc_spm_08_grass8?

Maris Nartiss maris.gis at gmail.com
Fri Sep 10 00:21:13 PDT 2021


Had to resent the mail due to size limitations. You can take a look at
the attachments here:
https://karlsons.gisnet.lv/~marisn/imagery_classification_G7.png
https://karlsons.gisnet.lv/~marisn/imagery_classification_G8.png


2021-09-10 5:56 GMT+03:00, Vaclav Petras <wenzeslaus at gmail.com>:
>
> Why not to have both? Classify thousands of scenes while providing a simple
> way of doing things?

Because GRASS metadata handling implementation is inferior. See
Sentinel SAFE usage in SNAP for a correct one (XML/Java discussion
aside).

> If all import tools assigned band references, having them ready in the
> dataset for landsat could be perhaps justified. That's the answer I was
> hoping for, but that's not the case. Still, the question would be what if
> you can't use such a tool.

Depends on the format. If imported format has band references (e.g.
SAFE), they should be written in GRASS as band references too. Still
this is a TODO for another day.

> As for getting closer to the original behavior where 5 commands were enough
> to classify, i.group could add the band references since one needs to deal
> with both groups and bands anyway or the signature handling could assign
> them on the fly. I'm probably missing some important details you know
> about, but here are some options I can think of:

To better understand my answer, take a look at two attached graphs –
how imagery groups and signature files work in G7 and how they have
been changed for G8. In G7 imagery group is only consistent
internally. In G8 signature files from one group are consistent in any
group.

> Option 1) i.group has a new option bandref. It assigns band references to
> the rasters. User needs to provide as many band references as inputs. Still
> quite long, but i.group call is long already and it is at least technically
> one step.

+ One long call instead of multiple calls to r.support
- Raster band must be set for each group separately (think NDVI or
slope map in multiple groups)
- User must set the same labels in a correct order also for any other
group where signature file is used
= Not a big difference from existing implementation

> Option 2) i.group has a new flag to auto-assign band references 1,2,3,...
> (2a). Or perhaps an option taking a prefix/basename (2b). Simple to set.
> Minimal change from the current workflows. Almost feels like band
> references are optional.

+ Works well if one classifies the same group only
- Signature file can not be used to classify any other group as there
is no guarantee of band order in groups
= This is a GRASS 7 approach with a hack of copying SIG file from one
group to other group

> Option 3) i.group auto-assigns automatically when band references are not
> present. No dealing with band references unless one needs to.

+ Works well if one classifies the same group only
- Signature files must be modified to contain group name
- User will be able to select a signature file for classification of a
different group but action will be refused if band references are
missing
= Confusing as one can not know in advance if signature file can or
can not be used to classify a group (should we call it a pythonic way
– try...except?)

> Option 4) i.gensigset et al. labels the bands 1,2,3,... on the fly only in
> the signature file and i.smap et al. uses the same numbering scheme when
> the rasters don't have band references. Band references are handled only
> when needed even on the module level in addition to the user level.

Didn't understood how this differs from option #2.

> With all options users still may take advantage of the flexible signature
> file system if being careful about order. (Keeping the order right is
> likely not an issue while scripting, so having a list of auto-assigned
> numbers is just fine.) All options hide details of the actual reference
> handling at least a little bit providing more space for changes later on.
> The options 3 and 4 make dealing with band references completely optional.
> Option 4 avoids mixing groups and band references and while option 3 hides
> that part.

There is no guarantee of order of bands in a REF file. If band order
stays the same, you are lucky, if it isn't, you just got an incorrect
result without a warning (a.k.a. flipping a coin to determine if
output is correct or total bollocks as band order was messed up).
Assigning band reference via scripting is not a problem if e.g. it is
present in the raster name.

> Other options would be modules such as r.number.bands/i.auto.bands (kind of
> like options 2 and 3 but standalone) and i.band.identify (some heuristic to
> determine band names from raster names perhaps taking an example or a
> sensor).

This is the correct way to go. I would say:
1) enhance import tools to generate band references (if possible). I
assume specialized Sentinel, Landsat, Modis etc. import modules could
be enhanced easily to do so.
2) provide an easy GUI tool to assign band references. Here bands from
g.bands would come handy. Probably i.bands could be repurposed to mass
assignment for rasters from a group.
3) provide a signature management tool (list, rename, delete, import,
export, print info, ..?; most of the library part is already done).

Unfortunately as I shelved for too long my work on i.svm to solve
signature file inefficiency of GRASS, I have no time to work on either
of solutions as I have deadlines to meet. GRASS 8.2 seems to be a
reasonable time frame for easing up band reference handling.

Of course, rolling back PRs #1501 and #1850 is also an option. Still,
then we'll be stuck with GRASS 3..7 approach till GRASS 9.0, as these
are serious changes to library and mapset structure thus 8.0 or 9.0.
Māris.


More information about the grass-dev mailing list