[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