t.rast.mapcalc: transfer semantic label

[metzm]

More often than not, transferring the semantic label in t.rast.mapcalc from the first input (also used as sampling reference for the time stamp) makes sense. If the semantic label gets lost, an unusable STRDS might be created.

An example is application of a multiplication factor to a STRDS with Landsat or Sentinel bands where semantic labels must be preserved.

[metzm]

User documentation has been updated accordingly.

[ninsbl]

Did jou consider to add a semantic_label option to the module? When you e.g. compute NDVI with t.rast.mapcalc it would be probably more appropriate to assign a new semantic label instead of using an existing one. For t.rast.neighbors or t.rast.aggregate transfering the semantic label (maybe with the method) seems mor natural though...

[veroandreo]

Did you consider to add a semantic_label option to the module? When you e.g. compute NDVI with t.rast.mapcalc it would be probably more appropriate to assign a new semantic label instead of using an existing one. For t.rast.neighbors or t.rast.aggregate transfering the semantic label (maybe with the method) seems more natural though...

I tend to agree, dunno how complex it might be to implement though. But this remark would also be true for t.rast.algebra when creating a new strds representing a different variable from that of the inputs

[metzm]

For NDVI, we at mundialis already have t.rast.ndvi where you can set the output semantic label such as "red_nir" or "blue_green", whichever bands you choose as input.

Adding a semantic_label option to t.rast.mapcalc does not make sense in the context of this PR, because the purpose of this PR is to transfer different semantic labels from input to output.

[veroandreo]

For NDVI, we at mundialis already have t.rast.ndvi where you can set the output semantic label such as "red_nir" or "blue_green", whichever bands you choose as input.

Adding a semantic_label option to t.rast.mapcalc does not make sense in the context of this PR, because the purpose of this PR is to transfer different semantic labels from input to output.

IMHO, transferring one of the semantic labels to an output that can potentially combine several input strds into something different is not a good default option. I rather let it as it was (no semantic label) instead of getting output semantic labels that won't reflect what the output is, or at least give the user the chance to choose. The option in mundialis module sounds in line with this, if I'm getting it right.

[huhabla]

Just a stupid idea:
Since the semantic label was introduced to add (machine readable) meaning to a strds, it can be used to keep track of what was performed with the input data. This "label" can keep plenty of characters, so why not keeping the input semantic labels and put them in context? Hence, adding more information using semantic labels with each grass module that is used to compute the output of another grass module. In case of filter methods, the semantic labels of the input can be kept.

In case of ndvi, the module knows exactly what it does, it performs ndvi computation on specific bands. Hence the automagically generated semantic labels can reflect this.

Lets imagine a syntax that can be used to create the semantic label like this:

process_description__from(input_1_label, input_2_label, ...)

In case of ndvi computed from nir and red bands (semantic labels are 'red' and 'nir') this may be:

ndvi__from(nir, red)

For a mapcalc operation, this may be complicated, since the meaning is in the algebraic expression. However,
in case of t.rast.mapcal, maybe the algebraic expression as semantic labels may be useful?

expression(nir_strds = L5_4/100)
expression(red_strds = L5_3/100)

Using the ndvi module this may add up to:

ndvi__from(expression(nir_strds = L5_4/100), expression(red_strds = L5_3/100))

Just an idea of an ex-developer.
Best regards
Sören

[metzm]

@huhabla Interesting idea to sort of put the history into a semantic label, but IMHO much to complicated and most probably causing some SQL headache. The history is available with r.info -h.

IMHO, these semantic labels should be kept fairly simple, with the main purpose to select particular raster maps in a STRDS by their label. In this sense it would be sufficient to have labels such as group1, group2, group3, ... and propagate these labels from input to output. This way you know directly that output raster maps with the label group2 are based on input raster maps with the same label group2.

For good reason, t.rast.mapcalc uses a list of input sample maps from which metadata are copied to output maps. The semantic label can be copied as well from these sample maps. The main thing is to have different labels in the output that reflect grouping in the input. If it does not make sense, users can ignore these labels.

[metzm]

This PR transfers semantic information from input to output.

Without this semantic information, it might not be possible to interpret the results and relate output to input.