[GRASS-dev] problem with r.mapcalc in GRASS 7

[Glynn Clements]

Barton Michael wrote:

> I'm not sure if this is a general issues or something specific to my OS X 10.6.4 build.
> 
> I just updated and compiled trunk.
> 
> When I try to use r.mapcalc, I get the following error: ERROR: Unable to load GDAL library

This is related to the r.external support. GDAL should only be loaded
on demand, i.e. if you try to open or create a "linked" map.

You can eliminate the problem by unsetting GDAL_DYNAMIC, e.g.

	make GDAL_DYNAMIC= ...

This causes libraster to be linked against GDAL directly, rather than
loading it dynamically with dlopen(). However, this might cause other
problems. GDAL is written in C++, which means that simply loading it
will cause constructors to be executed.

FWIW, the list of candidate filenames is:

	libgdal.1.1.so
	gdal.1.0.so
	gdal.so.1.0
	libgdal.so.1
	libgdal.so

If GDAL is called something else, or isn't found by the loader (for
whatever reason), you'll get the error you describe. On Linux, the
library needs to either be in $LD_LIBRARY_PATH, or in the cache
created by ldconfig. I'm not familiar with the mechanisms used on OSX.

> I'm also not sure how to use the new syntax, as the manual is
> lacking in examples of the use of the "expression" argument.
> 
> Old mapcalc: 
> r.mapcalc 'newmap=oldmap*2'
> 
> New mapcalc: 
> r.mapcalc "newmap = oldmap*2"  [CORRECT? This gives the gdal error]
> r.mapcalc file=newmap expression="oldmap*2"  [This gives a parse error]

The expression= option is the first option, so you don't need to
specify expression= explicitly *provided* that the value won't itself
be mistaken for an option.

"newmap=oldmap*2" will be mistaken for an attempt to specify the
(non-existent) newmap= option, resulting in an error. Placing a space
before or after the "=" sign will prevent this, so the "CORRECT?" 
example above works (at least so far as the parser is concerned).

For maximum compatibility when invoking r.mapcalc, use e.g.:

	r.mapcalc "outmap = inmap"	# works with both 6.x and 7.0

rather than:

	r.mapcalc expr="outmap = inmap"	# won't work with 6.x
	r.mapcalc "outmap=inmap"	# won't work with 7.0
	r.mapcalc outmap = inmap	# won't work with 7.0

The file= option is used to specify a file containing r.mapcalc
expressions (file=- reads from stdin), so:

	r.mapcalc file=foo

is equivalent to:

	r.mapcalc < foo
or:
	cat foo | r.mapcalc

except that file= is more GUI-friendly.

If you specify both file= and expression=, file= takes precedence[1]. 
As "newmap" presumably doesn't contain valid r.mapcalc expressions,
your last example results in a parse error.

If you specify neither file= nor expression=, "file=-" (i.e. read
expressions from stdin) is used, for compatibility with previous
versions.

[1] Fixed in r42659; using both expression= and file= now generates an
error.

-- 
Glynn Clements <glynn at gclements.plus.com>