The functions defined in lib/gis/band_reference.c [0] are used for raster imagery and should thus be removed from lib/gis. There is also lib/raster/band_reference.c [1] which should be moved to lib/imagery and the functions need to be renamed.
Martin, can you explain the reason for the existence of lib/gis/band_reference.c and lib/raster/band_reference.c and the non-existence of lib/imagery/band_reference.c ?
st 10. 3. 2021 v 21:56 odesílatel Markus Metz
<markus.metz.giswork@gmail.com> napsal:
The functions defined in lib/gis/band_reference.c [0] are used for raster imagery and should thus be removed from lib/gis. There is also lib/raster/band_reference.c [1] which should be moved to lib/imagery and the functions need to be renamed.
Martin, can you explain the reason for the existence of lib/gis/band_reference.c and lib/raster/band_reference.c and the non-existence of lib/imagery/band_reference.c ?
You are right that both files should be probably merged and moved to
raster imagery since the band reference concept is used currently only
for imagery data.
The reason why the functionality has been split into libgis and
libraster was the assumption that the (band) reference concept could
be used also for non-imagery data (raster or vector). But it will
probably not happen.
I will take a look on this issue in the next few days. Martin
I do have some climate data that comes as netCDF with a time series for several variables (max, min, avg temperature).
Currently (before band references), I would create a separate STRDS for each variable. If it would be possible to use custom band references (I did not find how to do that in the documentation, any hints where to look?), they could come in handy to have e.g. just one climate STRDS with different aggregations as "bands".
The same concept could apply to results from t.rast.aggregate if multiple aggregations are returned...
That is not exactly an "imagery band", but NDVI is also just an artificial band, isn`t it...
Cheers
Stefan
-----Original Message-----
From: grass-dev <grass-dev-bounces@lists.osgeo.org> On Behalf Of Martin Landa
Sent: torsdag 18. mars 2021 22:22
To: Markus Metz <markus.metz.giswork@gmail.com>
Cc: GRASS developers list <grass-dev@lists.osgeo.org>
Subject: Re: [GRASS-dev] lib/gis/band_reference.c ?
Hi Markus,
st 10. 3. 2021 v 21:56 odesílatel Markus Metz <markus.metz.giswork@gmail.com> napsal:
The functions defined in lib/gis/band_reference.c [0] are used for raster imagery and should thus be removed from lib/gis. There is also lib/raster/band_reference.c [1] which should be moved to lib/imagery and the functions need to be renamed.
Martin, can you explain the reason for the existence of lib/gis/band_reference.c and lib/raster/band_reference.c and the non-existence of lib/imagery/band_reference.c ?
You are right that both files should be probably merged and moved to raster imagery since the band reference concept is used currently only for imagery data.
The reason why the functionality has been split into libgis and libraster was the assumption that the (band) reference concept could be used also for non-imagery data (raster or vector). But it will probably not happen.
I will take a look on this issue in the next few days. Martin
GRASS supports arbitrary band reference names. Just make them unique
enough to not mix together apples with oranges by accident (e.g. "min"
is a bad idea, "min_t_c" is better; "NDVI" would work; "elevation" –
bad, "elevation_m" – better).
You can set band references after import with r.support module.
i.band allows to add e.g. S2_12 as band reference, but nothing custom. And the g.bands manual says that user-defined band references are not yet supported.
Has that been added recently? Or would I have to edit the bands json file of the system first?
My system is:
g.version -ger
version=8.0.dev
date=2021
revision=dd9d36830
build_date=2021-07-08
build_platform=x86_64-pc-linux-gnu
build_off_t_size=8
libgis_revision=d2a5e8e8f
libgis_date=2021-06-16T04:05:21+00:00
proj=7.0.0
gdal=3.0.4
geos=3.8.0
sqlite=3.22.0
Cheers
Stefan
-----Original Message-----
From: Maris Nartiss <maris.gis@gmail.com>
Sent: tirsdag 24. august 2021 09:03
To: Stefan Blumentrath <Stefan.Blumentrath@nina.no>
Cc: Martin Landa <landa.martin@gmail.com>; Markus Metz <markus.metz.giswork@gmail.com>; GRASS developers list <grass-dev@lists.osgeo.org>
Subject: Re: [GRASS-dev] lib/gis/band_reference.c ?
GRASS supports arbitrary band reference names. Just make them unique enough to not mix together apples with oranges by accident (e.g. "min"
is a bad idea, "min_t_c" is better; "NDVI" would work; "elevation" – bad, "elevation_m" – better).
You can set band references after import with r.support module.
Still – keep in mind – there are no changes in band metadata as
managed by g.bands. Changes only deal with ability to have a band
reference without extended metadata in json files. Thus limitation of
not being able to define your own band reference is still in place,
now only you can assign a band reference without having a definition
(and thus any extended metadata apart from its name).
Māris.
2021-08-24 11:18 GMT+03:00, Stefan Blumentrath <Stefan.Blumentrath@nina.no>:
Thanks Maris for the reply.
I could not find that option in r.support.
i.band allows to add e.g. S2_12 as band reference, but nothing custom. And
the g.bands manual says that user-defined band references are not yet
supported.
Has that been added recently? Or would I have to edit the bands json file of
the system first?
My system is:
g.version -ger
version=8.0.dev
date=2021
revision=dd9d36830
build_date=2021-07-08
build_platform=x86_64-pc-linux-gnu
build_off_t_size=8
libgis_revision=d2a5e8e8f
libgis_date=2021-06-16T04:05:21+00:00
proj=7.0.0
gdal=3.0.4
geos=3.8.0
sqlite=3.22.0
Cheers
Stefan
-----Original Message-----
From: Maris Nartiss <maris.gis@gmail.com>
Sent: tirsdag 24. august 2021 09:03
To: Stefan Blumentrath <Stefan.Blumentrath@nina.no>
Cc: Martin Landa <landa.martin@gmail.com>; Markus Metz
<markus.metz.giswork@gmail.com>; GRASS developers list
<grass-dev@lists.osgeo.org>
Subject: Re: [GRASS-dev] lib/gis/band_reference.c ?
GRASS supports arbitrary band reference names. Just make them unique enough
to not mix together apples with oranges by accident (e.g. "min"
is a bad idea, "min_t_c" is better; "NDVI" would work; "elevation" – bad,
"elevation_m" – better).
You can set band references after import with r.support module.
The easiest way to assign custom band names to raster maps in a strds is to create a corresponding file for t.register.
Note that band names in a strds do not need to match band names assigned with i.bands. The whole concept of band references in GRASS is IMHO still experimental and unfortunately far away from the STAC eo bands extension.
Still – keep in mind – there are no changes in band metadata as
managed by g.bands. Changes only deal with ability to have a band
reference without extended metadata in json files. Thus limitation of
not being able to define your own band reference is still in place,
now only you can assign a band reference without having a definition
(and thus any extended metadata apart from its name).
i.band allows to add e.g. S2_12 as band reference, but nothing custom. And
the g.bands manual says that user-defined band references are not yet
supported.
Has that been added recently? Or would I have to edit the bands json file of
the system first?
My system is:
g.version -ger
version=8.0.dev
date=2021
revision=dd9d36830
build_date=2021-07-08
build_platform=x86_64-pc-linux-gnu
build_off_t_size=8
libgis_revision=d2a5e8e8f
libgis_date=2021-06-16T04:05:21+00:00
proj=7.0.0
gdal=3.0.4
geos=3.8.0
sqlite=3.22.0
GRASS supports arbitrary band reference names. Just make them unique enough
to not mix together apples with oranges by accident (e.g. “min”
is a bad idea, “min_t_c” is better; “NDVI” would work; “elevation” – bad,
“elevation_m” – better).
You can set band references after import with r.support module.
The easiest way to assign custom band names to raster maps in a strds is to create a corresponding file for t.register.
Note that band names in a strds do not need to match band names assigned with i.bands. The whole concept of band references in GRASS is IMHO still experimental and unfortunately far away from the STAC eo bands extension.
Still – keep in mind – there are no changes in band metadata as
managed by g.bands. Changes only deal with ability to have a band
reference without extended metadata in json files. Thus limitation of
not being able to define your own band reference is still in place,
now only you can assign a band reference without having a definition
(and thus any extended metadata apart from its name).
i.band allows to add e.g. S2_12 as band reference, but nothing custom. And
the g.bands manual says that user-defined band references are not yet
supported.
Has that been added recently? Or would I have to edit the bands json file of
the system first?
My system is:
g.version -ger
version=8.0.dev
date=2021
revision=dd9d36830
build_date=2021-07-08
build_platform=x86_64-pc-linux-gnu
build_off_t_size=8
libgis_revision=d2a5e8e8f
libgis_date=2021-06-16T04:05:21+00:00
proj=7.0.0
gdal=3.0.4
geos=3.8.0
sqlite=3.22.0
GRASS supports arbitrary band reference names. Just make them unique enough
to not mix together apples with oranges by accident (e.g. “min”
is a bad idea, “min_t_c” is better; “NDVI” would work; “elevation” – bad,
“elevation_m” – better).
You can set band references after import with r.support module.