Re: [GRASS-dev] nc_spm_08_grass8?

[Vaclav Petras]

On Fri, Sep 10, 2021 at 3:02 AM Maris Nartiss  wrote:

> 2021-09-10 5:56 GMT+03:00, Vaclav Petras :

...
> = Not a big difference from existing implementation
>

Just to be clear, all these would be in addition to the proper handling of
band references and applied only when you don't want to deal with band
references directly.

...
>
> > 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.
>

The difference would be that the band references are never added to the
rasters in #4, only added to the signature file and re-created in the same
way for classification. In #2 they are actually added to rasters by
i.group. However, here is another option which I think is better than my
previous ones:

Option 5) Add a library function to read band reference which has a
fallback (band reference getter with a default). A reasonable fallback
seems to be the name of the raster map. This function can be then used on
all places in the signature/classification context instead of
Rast_read_bandref. i.gensigset et al. writes raster names as band
references to the signature file, i.smap et al. reads these names and
matches them with result from this new function unless the user didn't set
or renamed the raster map in the meantime. No additional step needed to the
v7 workflow if you don't need to use band references. The signatures are
associated with the raster map name rather than the order (as it is in v7).
Signatures from one mapset can then be used in another mapset as long as
the names of the rasters are the same (let's say each scene imported under
the same name into its own mapset for parallel processing). Something like
this function:

/** Return band reference or fallback to raster name if it is not set. */
char *Rast_read_bandref_with_fallback(const char *name, const char *mapset)
{
   char *ret = Rast_read_bandref(name, mapset);
   if (ret)
   return ret;
   else
   return G_store(name);
}
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] nc_spm_08_grass8?

[Maris Nartiss]

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 :
>
> 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 

Re: [GRASS-dev] nc_spm_08_grass8?

[Vaclav Petras]

On Thu, Sep 9, 2021 at 3:23 PM Maris Nartiss  wrote:

> 2021-09-09 19:19 GMT+03:00, Vaclav Petras :
> >
> > In the documentation, we moved from (5 calls):
> >
> > ```
> > g.region raster=lsat7_2002_10
> > i.group group=lsat7_2002 subgroup=res_30m input=...
> > v.to.rast input=training output=training use=cat label_column=label
> > i.gensigset trainingmap=training group=lsat7_2002 subgroup=...
> > i.smap group=lsat7_2002 subgroup=res_30m signaturefile=...
> > ```
> >
> > to (16 calls):
> >
> > ```
> > g.mapset mapset=PERMANENT
> > r.support map=lsat7_2002_10 bandref=TM7_1
> > r.support map=lsat7_2002_20 bandref=TM7_2
> > r.support map=lsat7_2002_30 bandref=TM7_3
> > r.support map=lsat7_2002_40 bandref=TM7_4
> > r.support map=lsat7_2002_50 bandref=TM7_5
> > r.support map=lsat7_2002_61 bandref=TM7_61
> > r.support map=lsat7_2002_62 bandref=TM7_62
> > r.support map=lsat7_2002_70 bandref=TM7_7
> > r.support map=lsat7_2002_80 bandref=TM7_8
> > g.mapset mapset=user1
> > g.region raster=lsat7_2002_10
> > i.group group=lsat7_2002 subgroup=res_30m input=...
> > v.to.rast input=training output=training use=cat label_column=label
> > i.gensigset trainingmap=training group=lsat7_2002 subgroup=...
> > i.smap group=lsat7_2002 subgroup=res_30m signaturefile=...
> > ```
> >
> > This seems to be making GRASS more difficult to use instead of making it
> > easier to use or at least keeping the status quo.
>
> And we gained ability to use signatures from one scene to classify
> different scenes.
>

Why not to have both? Classify thousands of scenes while providing a simple
way of doing things?

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.

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:

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.

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.

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

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.

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.

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).
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] nc_spm_08_grass8?

[Maris Nartiss]

2021-09-09 19:19 GMT+03:00, Vaclav Petras :
> On Thu, Sep 9, 2021 at 4:46 AM Maris Nartiss  wrote:
>
> In the documentation, we moved from (5 calls):
>
> ```
> g.region raster=lsat7_2002_10
> i.group group=lsat7_2002 subgroup=res_30m input=...
> v.to.rast input=training output=training use=cat label_column=label
> i.gensigset trainingmap=training group=lsat7_2002 subgroup=...
> i.smap group=lsat7_2002 subgroup=res_30m signaturefile=...
> ```
>
> to (16 calls):
>
> ```
> g.mapset mapset=PERMANENT
> r.support map=lsat7_2002_10 bandref=TM7_1
> r.support map=lsat7_2002_20 bandref=TM7_2
> r.support map=lsat7_2002_30 bandref=TM7_3
> r.support map=lsat7_2002_40 bandref=TM7_4
> r.support map=lsat7_2002_50 bandref=TM7_5
> r.support map=lsat7_2002_61 bandref=TM7_61
> r.support map=lsat7_2002_62 bandref=TM7_62
> r.support map=lsat7_2002_70 bandref=TM7_7
> r.support map=lsat7_2002_80 bandref=TM7_8
> g.mapset mapset=user1
> g.region raster=lsat7_2002_10
> i.group group=lsat7_2002 subgroup=res_30m input=...
> v.to.rast input=training output=training use=cat label_column=label
> i.gensigset trainingmap=training group=lsat7_2002 subgroup=...
> i.smap group=lsat7_2002 subgroup=res_30m signaturefile=...
> ```
>
> This seems to be making GRASS more difficult to use instead of making it
> easier to use or at least keeping the status quo.

And we gained ability to use signatures from one scene to classify
different scenes. Sucks if all you do is just tutorials and do not
attempt to use GRASS for any serious work. Have you been trying to use
GRASS to classify a large set of satellite imagery? In GRASS 7 you
must digitize training areas for each scene separately as you can not
use signatures from one scene (imagery group) to classify other scene
(signatures are located inside an imagery group). In GRASS 8 it is no
more – draw training areas once, generate signatures once and apply
signatures to as many scenes as you have (including in a different
mapset!). Heck, they would work out of box even in a different
location (import/export/management module is still a TODO).

> Changing the sample dataset sounds like hiding the issue rather than
> solving it. Having an ultra convenient sample dataset doesn't make the
> software easier to use.

Simplicity is not an end goal. GRASS is a tool for serious data
analysis and thus having to prepare data is nothing unusual. There are
other easier to use tools out there that will happily allow to do
shit-in, shit-out data analysis if one does not care about quality.
(Just take a look at the terrible hack i.signature.copy in addons – a
silent data corruption waiting to happen.)

> Additionally, given that the band references seem highly experimental, I
> don't think they should be required for any workflow at least from the user
> point of view.

Band references could be assigned automatically during import iff the
source has complete metadata (e.g. importing from Sentinel SAFE
format).
Portability of signature files depends on band references. I will not
see any reason why to land i.svm into main if I will not be able to
use portable signatures for automatic classification of large
datasets. Think big and not on a tutorial level. GRASS 7 imagery
classification tools are not HPC ready, GRASS 8 are (for data-parallel
approach).

Looking forward to my task of classifying 66100 imagery scenes with GRASS,
Māris.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] nc_spm_08_grass8?

[Vaclav Petras]

On Thu, Sep 9, 2021 at 4:46 AM Maris Nartiss  wrote:

> Hello Anna, Veronica.
>
> 2021-09-08 23:09 GMT+03:00, Veronica Andreo :
>
> > Indeed, we have a problem if all examples using Landsat will stop working
> > in grass 8, so if this is the case, then we might need a new version of
> the
> > sample data which by the way might also include the MODIS LST mapset (~10
> > Mb) to do some time series stuff.
>
> A new version of sample dataset would be good. Still existing version
> also works OK as long as you do an extra step of assigning band
> references at the first time. You'll find usage examples in manual
> pages of i.cluster with following in i.maxlik; and a full example in
> i.smap.
>

In the documentation, we moved from (5 calls):

```
g.region raster=lsat7_2002_10
i.group group=lsat7_2002 subgroup=res_30m input=...
v.to.rast input=training output=training use=cat label_column=label
i.gensigset trainingmap=training group=lsat7_2002 subgroup=...
i.smap group=lsat7_2002 subgroup=res_30m signaturefile=...
```

to (16 calls):

```
g.mapset mapset=PERMANENT
r.support map=lsat7_2002_10 bandref=TM7_1
r.support map=lsat7_2002_20 bandref=TM7_2
r.support map=lsat7_2002_30 bandref=TM7_3
r.support map=lsat7_2002_40 bandref=TM7_4
r.support map=lsat7_2002_50 bandref=TM7_5
r.support map=lsat7_2002_61 bandref=TM7_61
r.support map=lsat7_2002_62 bandref=TM7_62
r.support map=lsat7_2002_70 bandref=TM7_7
r.support map=lsat7_2002_80 bandref=TM7_8
g.mapset mapset=user1
g.region raster=lsat7_2002_10
i.group group=lsat7_2002 subgroup=res_30m input=...
v.to.rast input=training output=training use=cat label_column=label
i.gensigset trainingmap=training group=lsat7_2002 subgroup=...
i.smap group=lsat7_2002 subgroup=res_30m signaturefile=...
```

This seems to be making GRASS more difficult to use instead of making it
easier to use or at least keeping the status quo.

Changing the sample dataset sounds like hiding the issue rather than
solving it. Having an ultra convenient sample dataset doesn't make the
software easier to use.

Additionally, given that the band references seem highly experimental, I
don't think they should be required for any workflow at least from the user
point of view.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] nc_spm_08_grass8?

[Anna Petrášová]

Hi Vero, Maris,

thanks for responding! This is concerning, I personally don't work a lot
with remote sensing data and temporal stuff, but it seems to be delaying
GRASS 8 release.

On Thu, Sep 9, 2021 at 4:46 AM Maris Nartiss  wrote:

> Hello Anna, Veronica.
>
> 2021-09-08 23:09 GMT+03:00, Veronica Andreo :
> > Hi Anna, all
> >
> > Good point! Thanks for raising this!
> >
> > Seems we are all trying to better understand band references and how they
> > integrate with existing functionality :)
>
> Band reference usage in the context of classification of imagery is
> explained in a scheme in the most recent GRASS 8 feature presentation:
> https://veroandreo.github.io/grass-gis-talks/wageningen2021.htmlmuch#/4/6
> 
>
> > In
> > https://github.com/OSGeo/grass/pull/1844/ we discuss temporal framework
> and
> > band references.
>
> I can not comment on band references in t.* modules as I do not
> understand their role there. Some changes might be needed there.
>
> > Indeed, we have a problem if all examples using Landsat will stop working
> > in grass 8, so if this is the case, then we might need a new version of
> the
> > sample data which by the way might also include the MODIS LST mapset (~10
> > Mb) to do some time series stuff.
>
> A new version of sample dataset would be good. Still existing version
> also works OK as long as you do an extra step of assigning band
> references at the first time. You'll find usage examples in manual
> pages of i.cluster with following in i.maxlik; and a full example in
> i.smap.
>
>
> https://github.com/OSGeo/grass/blob/main/imagery/i.cluster/i.cluster.html#L265
> https://github.com/OSGeo/grass/blob/main/imagery/i.maxlik/i.maxlik.html
> https://github.com/OSGeo/grass/blob/main/imagery/i.smap/i.smap.html#L144
>


> > In my opinion, band reference should be something optional, no?
>
> They are optional as long as you are not using i.maxlik or i.smap or
> i.svm.predict (and respective signature generation modules for them).
> Can't comment on t.* modules.
>
>
So in that case it seems we need a new version, which would at least have
the
band references assigned. Since you only assign them from the actual mapset,
the current dataset is more difficult to use for any classification
examples.
E.g. this would be confusing in a workshop.
I think sample data should be ready to be used. It seems the assigned band
references are ignored in 7.8 and
everything works (is that right, Maris?), so we could just update the
current dataset as a quick fix.
Adding more data would be certainly valuable, but the whole dataset would
deserve update.
Then also the dataset has grass7 in the name...


> > On the
> > other hand, I think I understood from Maris that with r.support we could
> > add band references and that the restrictions were relaxed but these
> > changes are not yet documented. There's this thread:
> > https://lists.osgeo.org/pipermail/grass-dev/2021-September/095377.html
>
> Band reference rules are relaxed and now any word can be a band
> reference as long as its length does not exceed GNAME_MAX and its
> symbol set is limited to a-Z 0-9 and "-", "_".
> https://github.com/OSGeo/grass/blob/main/lib/raster/raster_metadata.c#L149
> Can not comment on t.* modules as they are bypassing C library and
> doing some magick in Python instead of fully integrating with the rest
> of GRASS.
>
> It is pity that the PR relaxing band reference requirements got merged
> although it didn't change the documentation to reflect changes in the
> code. It is my fault as I wasn't fast enough to stop Markus Metz from
> merging without required changes. I hope Markus M. will fix his
> blunder and provide changes also to the documentation to reflect
> changes in the code made by him.
> https://github.com/OSGeo/grass/pull/1796


I cc'ed Markus.

>
>
> > Band references need some further discussion IMHO
>

+1

>
> Harmonization of t.* Python based band reference handling with C
> library based one should be done by someone who completely understands
> the Python part in t.* (as an idea and not only code). As
> functionality is required in both C and Python code, C has precedence
> over Python (functionality in C + wrapper functions for Python or just
> plain ctypes as it is done in tests).
>
> From the i.* module point of view, modules g.bands and i.bands are not
> required and are not used at all. Besides i.bands is a bad module name
> as bands are assigned to rasters and not groups thus it should be
> r.bands but the management functionality is already covered with
> r.support leaving only printing for i.bands without an alternative. I
> would drop i.bands completely unless it is completely reworked.
> g.bands is a nice idea but, unless someone implements editing part, it
> is of limited use.


> > my 2 cents
> > Vero
>
> Māris.
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org

Re: [GRASS-dev] nc_spm_08_grass8?

[Maris Nartiss]

Hello Anna, Veronica.

2021-09-08 23:09 GMT+03:00, Veronica Andreo :
> Hi Anna, all
>
> Good point! Thanks for raising this!
>
> Seems we are all trying to better understand band references and how they
> integrate with existing functionality :)

Band reference usage in the context of classification of imagery is
explained in a scheme in the most recent GRASS 8 feature presentation:
https://veroandreo.github.io/grass-gis-talks/wageningen2021.html#/4/6

> In
> https://github.com/OSGeo/grass/pull/1844/ we discuss temporal framework and
> band references.

I can not comment on band references in t.* modules as I do not
understand their role there. Some changes might be needed there.

> Indeed, we have a problem if all examples using Landsat will stop working
> in grass 8, so if this is the case, then we might need a new version of the
> sample data which by the way might also include the MODIS LST mapset (~10
> Mb) to do some time series stuff.

A new version of sample dataset would be good. Still existing version
also works OK as long as you do an extra step of assigning band
references at the first time. You'll find usage examples in manual
pages of i.cluster with following in i.maxlik; and a full example in
i.smap.

https://github.com/OSGeo/grass/blob/main/imagery/i.cluster/i.cluster.html#L265
https://github.com/OSGeo/grass/blob/main/imagery/i.maxlik/i.maxlik.html
https://github.com/OSGeo/grass/blob/main/imagery/i.smap/i.smap.html#L144

> In my opinion, band reference should be something optional, no?

They are optional as long as you are not using i.maxlik or i.smap or
i.svm.predict (and respective signature generation modules for them).
Can't comment on t.* modules.

> On the
> other hand, I think I understood from Maris that with r.support we could
> add band references and that the restrictions were relaxed but these
> changes are not yet documented. There's this thread:
> https://lists.osgeo.org/pipermail/grass-dev/2021-September/095377.html

Band reference rules are relaxed and now any word can be a band
reference as long as its length does not exceed GNAME_MAX and its
symbol set is limited to a-Z 0-9 and "-", "_".
https://github.com/OSGeo/grass/blob/main/lib/raster/raster_metadata.c#L149
Can not comment on t.* modules as they are bypassing C library and
doing some magick in Python instead of fully integrating with the rest
of GRASS.

It is pity that the PR relaxing band reference requirements got merged
although it didn't change the documentation to reflect changes in the
code. It is my fault as I wasn't fast enough to stop Markus Metz from
merging without required changes. I hope Markus M. will fix his
blunder and provide changes also to the documentation to reflect
changes in the code made by him.
https://github.com/OSGeo/grass/pull/1796

> Band references need some further discussion IMHO

Harmonization of t.* Python based band reference handling with C
library based one should be done by someone who completely understands
the Python part in t.* (as an idea and not only code). As
functionality is required in both C and Python code, C has precedence
over Python (functionality in C + wrapper functions for Python or just
plain ctypes as it is done in tests).

From the i.* module point of view, modules g.bands and i.bands are not
required and are not used at all. Besides i.bands is a bad module name
as bands are assigned to rasters and not groups thus it should be
r.bands but the management functionality is already covered with
r.support leaving only printing for i.bands without an alternative. I
would drop i.bands completely unless it is completely reworked.
g.bands is a nice idea but, unless someone implements editing part, it
is of limited use.

> my 2 cents
> Vero

Māris.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] nc_spm_08_grass8?

[Veronica Andreo]

Hi Anna, all

Good point! Thanks for raising this!

Seems we are all trying to better understand band references and how they
integrate with existing functionality :)  In
https://github.com/OSGeo/grass/pull/1844/ we discuss temporal framework and
band references.

Indeed, we have a problem if all examples using Landsat will stop working
in grass 8, so if this is the case, then we might need a new version of the
sample data which by the way might also include the MODIS LST mapset (~10
Mb) to do some time series stuff.

In my opinion, band reference should be something optional, no? On the
other hand, I think I understood from Maris that with r.support we could
add band references and that the restrictions were relaxed but these
changes are not yet documented. There's this thread:
https://lists.osgeo.org/pipermail/grass-dev/2021-September/095377.html

Band references need some further discussion IMHO

my 2 cents
Vero

El mié, 8 sept 2021 a las 20:56, Anna Petrášová ()
escribió:

> Hi devs,
>
> given the changes with bands (which I still don't fully understand) do we
> need to have a new sample dataset, in which the landsat scenes have bands?
> Context: I was playing with basic classification examples (g.gui.iclass,
> i.gensigset) and apparently it doesn't work and it's giving me error:
>
> Raster map  lacks band reference
>
> So my questions are:
>
> 1. Is that expected behavior? Seems little strict to me.
> 2. If yes, then what do I do when working with other data than Landsat,
> Sentinel, etc - g.bands doesn't currently support user-defined references.
> 3. Also, if yes, do we need a sample dataset for GRASS8 then? Otherwise
> any examples with landsat fail.
>
> Sorry if I misunderstood anything.
>
> Thanks,
> Anna
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] nc_spm_08_grass8?

[Anna Petrášová]

Hi devs,

given the changes with bands (which I still don't fully understand) do we
need to have a new sample dataset, in which the landsat scenes have bands?
Context: I was playing with basic classification examples (g.gui.iclass,
i.gensigset) and apparently it doesn't work and it's giving me error:

Raster map  lacks band reference

So my questions are:

1. Is that expected behavior? Seems little strict to me.
2. If yes, then what do I do when working with other data than Landsat,
Sentinel, etc - g.bands doesn't currently support user-defined references.
3. Also, if yes, do we need a sample dataset for GRASS8 then? Otherwise any
examples with landsat fail.

Sorry if I misunderstood anything.

Thanks,
Anna
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev