[GRASS-dev] [GRASS GIS] #2770: r.mapcalc reports syntax error for valid script but no error for separate expressions
GRASS GIS
trac at osgeo.org
Wed Oct 21 18:56:22 PDT 2015
#2770: r.mapcalc reports syntax error for valid script but no error for separate
expressions
--------------------------+-------------------------
Reporter: marisn | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone:
Component: Raster | Version: svn-trunk
Resolution: | Keywords: r.mapcalc
CPU: Unspecified | Platform: Unspecified
--------------------------+-------------------------
Comment (by glynn):
Replying to [ticket:2770 marisn]:
> Seems that r.mapcalc doesn't like some sequences of valid expressions.
> Following examples show the same expressions copy/pasted into
interactive r.mapcalc session all together and one by one. Notice - same
syntax once causes "syntax error" but no "syntax error" is generated if
execution happens to be performed on a separate r.mapcalc process.
This is not a bug. It could really do with better documentation, though.
A "name" (*) refers to a variable if it has previously occurred on the
left-hand side of an assignment expression, and to an input map otherwise.
The neighbourhood modifier "map[row,col]" can only be applied to input
maps, not to variables. Likewise for the @ and # modifiers.
Each assignment expression which occurs at the top level (i.e. not nested
within a sub-expression) creates a variable, and also results in the
creation of an output map. An assignment other than at the top level only
creates a variable, not an output map. At the end of processing each row,
any variables defined at the top level have their value written as the
current row of the corresponding output map.
Any maps generated by an r.mapcalc command only exist after the entire
command has completed. All maps are generated concurrently, row-by-row
(i.e. there is an implicit "for row in rows {...}" around the entire
expression).
At present, it's impossible to read from a map which is in the process of
being created. And even if it was possible, reading from such a map with a
positive row offset would be awkward; in the worst case, two maps could
each depend upon not-yet-calculated rows of each other.
(*) A name is either
a) any sequence of (letters, digits, any of the symbols dollar, period,
backslash, underscore, backtick, left brace, right brace, or any character
>= 127), excluding anything with a prefix which can be parsed as a number,
or
b) any sequence of characters delimited by single or double quotes.
(!**) The set of characters which are allowed without quoting is probably
too liberal; AFAICT, it's essentially anything that doesn't result in the
grammar being ambiguous.
--
Ticket URL: <https://trac.osgeo.org/grass/ticket/2770#comment:1>
GRASS GIS <https://grass.osgeo.org>
More information about the grass-dev
mailing list