Opened 7 years ago

Last modified 3 years ago

#2735 reopened defect

t.rast.mapcalc input problem

Reported by: leohardtke Owned by: grass-dev@…
Priority: normal Milestone: 7.0.7
Component: Temporal Version: svn-trunk
Keywords: t.rast.mapcalc Cc:
CPU: Unspecified Platform: Linux

Description (last modified by martinl)

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

Change History (17)

comment:1 by leohardtke, 7 years ago

Milestone: 7.1.0

comment:2 by neteler, 7 years ago

Component: DefaultTemporal
Keywords: t.rast.mapcalc added
Milestone: 7.0.1
Resolution: fixed
Status: newclosed

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

comment:3 by huhabla, 7 years ago

Resolution: fixed
Status: closedreopened

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.

in reply to:  3 ; comment:4 by dylan, 7 years ago

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.

comment:5 by neteler, 7 years ago

Milestone: 7.0.17.0.3

comment:6 by neteler, 7 years ago

Potential duplicate of #2659

comment:7 by neteler, 7 years ago

Milestone: 7.0.3

Ticket retargeted after milestone closed

comment:8 by neteler, 7 years ago

Milestone: 7.0.4

Ticket retargeted after 7.0.3 milestone closed

in reply to:  4 comment:9 by neteler, 7 years ago

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)?

comment:10 by martinl, 6 years ago

Milestone: 7.0.47.0.5

comment:11 by neteler, 6 years ago

Milestone: 7.0.57.0.6

comment:12 by martinl, 4 years ago

Description: modified (diff)

comment:13 by neteler, 4 years ago

Milestone: 7.0.67.0.7

comment:14 by veroandreo, 4 years ago

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

comment:15 by martinl, 3 years ago

Still relevant?

comment:16 by veroandreo, 3 years ago

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

in reply to:  3 comment:17 by neteler, 3 years ago

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?

Note: See TracTickets for help on using tickets.