Opened 9 years ago
Last modified 5 years ago
#2735 reopened defect
t.rast.mapcalc input problem
Reported by: | leohardtke | Owned by: | |
---|---|---|---|
Priority: | normal | Milestone: | 7.0.7 |
Component: | Temporal | Version: | svn-trunk |
Keywords: | t.rast.mapcalc | Cc: | |
CPU: | Unspecified | Platform: | Linux |
Description (last modified by )
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 , 9 years ago
Milestone: | 7.1.0 |
---|
comment:2 by , 9 years ago
Component: | Default → Temporal |
---|---|
Keywords: | t.rast.mapcalc added |
Milestone: | → 7.0.1 |
Resolution: | → fixed |
Status: | new → closed |
follow-ups: 4 17 comment:3 by , 9 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
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.
follow-up: 9 comment:4 by , 9 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 , 9 years ago
Milestone: | 7.0.1 → 7.0.3 |
---|
comment:9 by , 9 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 , 8 years ago
Milestone: | 7.0.4 → 7.0.5 |
---|
comment:11 by , 8 years ago
Milestone: | 7.0.5 → 7.0.6 |
---|
comment:12 by , 7 years ago
Description: | modified (diff) |
---|
comment:13 by , 7 years ago
Milestone: | 7.0.6 → 7.0.7 |
---|
comment:14 by , 7 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:16 by , 5 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
comment:17 by , 5 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?
Fixed in r66308, tested and backported in r66313. Closing.