[GRASS-dev] [GRASS GIS] #2735: t.rast.mapcalc input problem
GRASS GIS
trac at osgeo.org
Thu Oct 15 12:08:09 PDT 2015
#2735: t.rast.mapcalc input problem
--------------------------+----------------------------
Reporter: leohardtke | Owner: grass-dev@…
Type: defect | Status: reopened
Priority: normal | Milestone: 7.0.1
Component: Temporal | Version: svn-trunk
Resolution: | Keywords: t.rast.mapcalc
CPU: Unspecified | Platform: Linux
--------------------------+----------------------------
Comment (by dylan):
Replying to [comment:3 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 [http://osgeo-org.1560.x6.nabble.com/Error-reading-raster-
data-for-row-xxx-only-when-using-r-series-and-t-rast-series-td5229569.html
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.
--
Ticket URL: <https://trac.osgeo.org/grass/ticket/2735#comment:4>
GRASS GIS <https://grass.osgeo.org>
More information about the grass-dev
mailing list