t.rast.mapcalc input problem

[leohardtke]

I'm facing a problem with an expression in the t.rast.mapcalc module which I think is a Bug...

t.rast.mapcalc inputs=QA_mask,ndvi,ndvi_smooth_spacetime expression="if(QA_mask==0,ndvi,ndvi_smooth_spacetime)" output=ndvi_fixed basename=ndvi_fixed
It throws the following error:
Starting temporal sampling...
Starting mapcalc computation...
Invalid map <MOD13Q1.A2009017.h12v12.005.2009035110230_01_4326_smooth_spacetime_0>
Parse error
ERROR: parse error
ERROR: Error while mapcalc computation

The QA_mask maps are:

QA_mask_01|PERMANENT|2009-01-01 00:00:00|2009-01-17 00:00:00
QA_mask_02|PERMANENT|2009-01-17 00:00:00|2009-02-02 00:00:00
......

The ndvi_smooth_spacetime maps are:

ndvi_smooth_spacetime_0|PERMANENT|2009-01-17 00:00:00|2009-02-02 00:00:00
ndvi_smooth_spacetime_1|PERMANENT|2009-02-02 00:00:00|2009-02-18 00:00:00
...........

The ndvi maps are

MOD13Q1.A2009001.h12v12.005.2009019145228_01_4326|PERMANENT|2009-01-01 00:00:00|2009-01-17 00:00:00
MOD13Q1.A2009017.h12v12.005.2009035110230_01_4326|PERMANENT|2009-01-17 00:00:00|2009-02-02 00:00:00

M

As you see, there is no such a map like..

MOD13Q1.A2009017.h12v12.005.2009035110230_01_4326_smooth_spacetime_0

I guess the module is mixing ndvi (a temporal dataset) with _smooth_spacetime... the second part of the name....

[neteler]

Fixed in r66308, tested and backported in r66313. Closing.

[huhabla]

This bug was not fixed in t.rast.mapcalc. A similar bug was fixed in t.rast.extract.

However, fixing the bug in t.rast.mapcalc is more difficult since it uses a simple search and replace approach to substitute the input STRDS with map names and is not aware of what a space time dataset is. If the names of input and output space time datasets are include each other, then the module does not work properly. Choosing a specific order of the input STRDS in the input parameter (i.e: input=ndvi_smooth,QA_mask,ndvi) may reduce the risk of wrong substitution.

However, please use t.rast.algebra instead. This module has other issues but is able to correctly identify space time datasets.

[dylan]

Replying to huhabla:

This bug was not fixed in t.rast.mapcalc. A similar bug was fixed in t.rast.extract.

However, fixing the bug in t.rast.mapcalc is more difficult since it uses a simple search and replace approach to substitute the input STRDS with map names and is not aware of what a space time dataset is. If the names of input and output space time datasets are include each other, then the module does not work properly. Choosing a specific order of the input STRDS in the input parameter (i.e: input=ndvi_smooth,QA_mask,ndvi) may reduce the risk of wrong substitution.

However, please use t.rast.algebra instead. This module has other issues but is able to correctly identify space time datasets.

Are there any other reasons to use t.rast.algebra over t.rast.mapcalc?

I don't know if ​this long-winded GRASS-dev post is related, but I am finding what appear to be randomly corrupted output maps from t.rast.mapcalc when the output is FCELL or DCELL. No problems observed when output is CELL.

I will give t.rast.algebra a try and report back.

[neteler]

Potential duplicate of #2659

[neteler]

Ticket retargeted after milestone closed

[neteler]

Ticket retargeted after 7.0.3 milestone closed

[neteler]

Replying to dylan:

I don't know if ​this long-winded GRASS-dev post is related, but I am finding what appear to be randomly corrupted output maps from t.rast.mapcalc when the output is FCELL or DCELL. No problems observed when output is CELL.

May that be gone with r66731 (lib/gis/worker.c) which set the default workers to zero (threads only used by explicit request)?

[veroandreo]

A similar (maybe the same) issue was reported in the mailing list in Feb 2018: ​https://lists.osgeo.org/pipermail/grass-user/2018-February/077903.html

[martinl]

Still relevant?

[veroandreo]

This is still an issue in 7.6 relbranch. Here's how to reproduce:

# create strds test
for i in `seq -w 1 10` ; do r.mapcalc expression="map_$i = 1" ; done
t.create output=test type=strds temporaltype=absolute title="test" description="test"
t.register input=test maps=`g.list rast pat=map_* sep=,` start='2000-01-01' increment="1 days" -i

# create strds test2
for i in `seq -w 1 10` ; do r.mapcalc expression="mapa_$i = 1" ; done
t.create output=test2 type=strds temporaltype=absolute title="test" description="test"
t.register input=test2 maps=`g.list rast pat=mapa_* sep=,` start='2000-01-01' increment="1 days" -i

# t.rast.mapcalc
t.rast.mapcalc inputs=test,test2 expression="test+test2" basename=test output=test3

Starting temporal sampling...
Starting mapcalc computation...
Invalid map <map_012>
Parse error
ERROR: parse error
ERROR: Error while mapcalc computation

maybe, this is a wontfix though... AFAIU, it is recommended to use G7:t.rast.algebra in these cases in which strds and maps within them are nested or so similar

[neteler]

Replying to huhabla:

However, please use t.rast.algebra instead. This module has other issues but is able to correctly identify space time datasets.

Would it be possible to reimplement t.rast.mapcalc as a Python wrapper around G7:t.rast.algebra?