r3.mapcalc(1)	       Grass User's Manual	    r3.mapcalc(1)



NNAAMMEE
       _r_3_._m_a_p_c_a_l_c - G3D grid volume data calculator.

       _(_G_R_A_S_S _3_D _P_r_o_g_r_a_m_)

SSYYNNOOPPSSIISS
       rr33..mmaappccaallcc [rreessuulltt==_e_x_p_r_e_s_s_i_o_n]

DDEESSCCRRIIPPTTIIOONN
       _r_3_._m_a_p_c_a_l_c performs arithmetic on 3D grid volume data. New
       3D grids can be created which are  arithmetic  expressions
       involving existing 3D grids, floating point constants, and
       functions.

PPRROOGGRRAAMM UUSSEE
       If used without command line  arguments,  _r_3_._m_a_p_c_a_l_c  will
       read  its  input,  one line at a time, from standard input
       (which is the keyboard, unless  directed from  a  file  or
       across  a pipe).  Otherwise, the expression on the command
       line is evaluated. _r_3_._m_a_p_c_a_l_c expects its  input  to  have
       the form:

       rreessuulltt==_e_x_p_r_e_s_s_i_o_n

       where  _r_e_s_u_l_t  is  the  name  of  a 3D grid to contain the
       result of the calculation  and  _e_x_p_r_e_s_s_i_o_n  is  any  legal
       arithmetic expression involving existing 3D grid, floating
       point constants, and functions known  to  the  calculator.
       Parentheses  are  allowed  in  the  expression  and may be
       nested to any depth. _r_e_s_u_l_t will be created in the  user's
       current mapset.

       The  formula entered to _r_3_._m_a_p_c_a_l_c by the user is recorded
       both in the _r_e_s_u_l_t grid title (which appears in the  cate-
       gory  file for _r_e_s_u_l_t) and in the history file for _r_e_s_u_l_t.

       Some characters have special meaning to the command shell.
       If  the user is entering input to _r_._m_a_p_c_a_l_c on the command
       line, expressions should be enclosed within single quotes.
       See NOTES, below.

OOPPEERRAATTOORRSS AANNDD OORRDDEERR OOFF PPRREECCEEDDEENNCCEE
       The following operators are supported:

	    -----------------------------------------------------------------------
	    %	       modulus (remainder upon division)   Arith-
       metic  4
	    /	       division 			   Arith-
       metic  4
	    *	       multiplication			   Arith-
       metic  4
	    +	       addition 			   Arith-
       metic  3
	    -	       subtraction			   Arith-
       metic  3
	    ==		equal				    Logi-
       cal     2
	    !=	       not equal			    Logi-
       cal     2
	    >		greater than			    Logi-
       cal     2
	    >=		    greater	 than	   or	    equal
       Logical	   2
	    <		less than			    Logi-
       cal     2
	    <=	       less than or equal		    Logi-
       cal     2
	    &&		and				    Logi-
       cal     1
	    ||	       or				    Logi-
       cal     1


       applied	before those with lower precedence. Division by 0
       and modulus by
       0 are acceptable and give a 0 result. The  logical  opera-
       tors give a 1 result
       if the comparison is true, 0 otherwise.


33DD GGRRIIDD NNAAMMEESS
       Anything  in  the expression which is not a number, opera-
       tor, or function
       name is taken to be a 3D grid name. Examples:

       volume

       x3

       3d.his

       Most GRASS raster map layers and 3D grids meet this naming
       convention.
       However,  if a 3D grid has a name which conflicts with the
       above rule, it
       should be quoted. For example, the expression

       x = a-b

       would be interpreted as: x equals a minus b, whereas

       x = "a-b"

       would be interpreted as: x equals 3D grid named _a_-_b

       Also

       x = 3107

       would create _x filled with the number 3107, while

       x = "3107"

       would copy the 3D grid _3_1_0_7 to the 3D grid _x.

       Quotes are not required unless the 3D grid names look like
       numbers or
       contain operators, OR unless the program is run non-inter-
       actively. Examples
       given here assume the program is  run  interactively.  See
       NOTES, below.

       _r_3_._m_a_p_c_a_l_c  will  look  for  the 3D grids according to the
       user's
       current mapset search path. It is possible to override the
       search path
       and  specify  the mapset from which to select the 3D grid.
       This is done by
       specifying the 3D grid name in the form:

       name@mapset

       For example, the following is a legal expression:

       result = x@PERMANENT / y@SOILS

       The mapset specified does not have to  be  in  the  mapset
       search path. (This
       method  of  overriding the mapset search path is common to
       all GRASS commands,
       not just _r_3_._m_a_p_c_a_l_c.)

TTHHEE NNEEIIGGHHBBOORRHHOOOODD MMOODDIIFFIIEERR
       3D grids are data base files stored in voxel format, i.e.,
       three-dimensional
       matrices  of  float/double values. In _r_3_._m_a_p_c_a_l_c, 3D grids
       may be
       followed by a _n_e_i_g_h_b_o_r_h_o_o_d modifier that specifies a rela-
       tive offset
       from the current cell being evaluated. The format is
       _m_a_p_[_r_,_c_,_d_],
       where _r is the row offset, _c is the column offset and _d
       is the depth offset. For example, _m_a_p_[_1_,_2_,_3_] refers to the
       cell
       one row below, two columns to the right and 3 levels below
       of the current
       cell,  _m_a_p_[_-_3_,_-_2_,_-_1_]  refers to the cell three rows above,
       two columns
       to the left and one level below of the current  cell,  and
       _m_a_p_[_0_,_1_,_0_]
       refers  to the cell one column to the right of the current
       cell. This syntax
       permits	the  development  of  neighborhood-type   filters
       within a single 3D
       grid or across multiple 3D grids.




FFUUNNCCTTIIOONNSS
       The  functions currently supported are listed in the table
       below.

       ---------------------------------------------------------------------------
       abs(x)		       return absolute value of x
       atan(x)		       inverse tangent of x (result is in
       degrees)
       cos(x)		       cosine of x (x is in degrees)
       col()		       return current column
       depth()		       return current depth
       eval([x,y,...,]z)       evaluate values	of  listed  expr,
       pass results to z
       exp(x)		       exponential function of x
       exp(x,y) 	       x to the power y
       ewres()		       east-west resolution from WIND3D
       if		       decision options:
       if(x)		       1 if x not zero, 0 otherwise
       if(x,a)		       a if x not zero, 0 otherwise
       if(x,a,b)	       a if x not zero, b otherwise
       if(x,a,b,c)	       a if x > 0, b if x is zero, c if x
       < 0
       isnull(x)	       1 if x not zero, 0 otherwise
       log(x)		       natural log of x
       log(x,b) 	       log of x base b
       max(x,y[,z...])	       largest value of those listed
       median(x,y[,z...])      median value of those listed
       min(x,y[,z...])	       smallest value of those listed
       mode(x,y[,z...])        most  frequently  value	of  those
       listed
       null()		       return 0
       nsres()		       north-south resolution from WIND3D
       rand(x,y)	       random value between x and y
       round(x) 	       round x
       row()		       return current row
       sin(x)		       sine of x (x is in degrees)
       sqrt(x)		       square root of x
       tan(x)		       tangent of x (x is in degrees)
       tbres()		       top-bottom resolution from WIND3D
       x()		       return current x value
       y()		       return current y value
       z()		       return current z value

       Note, that the row(), col() and	depth()  indexing  starts
       with 1.

EEXXAAMMPPLLEESS
       To compute the average of two 3D grids _a and _b:

       To form a weighted average:

       To produce a binary representation of 3D grid
       _a so that category
       0 remains 0 and all other categories become 1:

       This could also be accomplished by:

       To mask 3D grid _b by 3D grid _a:



RREEGGIIOONN//MMAASSKK
       The  user  must	be aware of the current geographic region
       and current mask
       settings when using _r_3_._m_a_p_c_a_l_c. All 3D grids are read into
       the current
       geographic  region  masked  by  the current mask. If it is
       desired to modify
       an existing 3D grid without involving other 3D grids,  the
       geographic region
       should
       be  set to agree with the cell header for the 3D grid. For
       example, suppose
       it is determined that the
       _v_o_l_u_m_e 3D grid must have each category
       value increased by 10 meters. The following expression  is
       legal and will
       do the job:

       Since a category value of 0 is used in GRASS for locations
       which do not
       exist in 3D grid, the new 3D grid will contain  the  cate-
       gory value 10 in
       the  locations  that did not exist in the original volume.
       Therefore, in
       this example, it is essential that the boundaries  of  the
       geographic region
       be set to agree with the cell header.

       However, if there is a current mask, then the resultant 3D
       grid is masked
       when it is written; i.e., 0 category values  in	the  mask
       force zero values
       in the output.

NNOOTTEESS
       Extra care must be taken if the expression is given on the
       command line.
       Some characters have special meaning to	the  UNIX  shell.
       These include,
       among others:

       * ( ) > & |

       It  is  advisable  to put single quotes around the expres-
       sion; e.g.:

       Without the quotes, the *, which has  special  meaning  to
       the UNIX shell,
       would  be altered and _r_3_._m_a_p_c_a_l_c would see something other
       than the
       *.

       If the input comes directly  from  the  keyboard  and  the
       _r_e_s_u_l_t
       3D  grid exists, the user will be asked if it can be over-
       written. Otherwise,
       the _r_e_s_u_l_t 3D grid will automatically be overwritten if it
       exists.

       Quoting _r_e_s_u_l_t is not allowed. However, it is never neces-
       sary
       to quote _r_e_s_u_l_t since it is always taken to be a  3D  grid
       name.

       For  formulas  that  the  user  enters from standard input
       (rather than from
       the command line), a line continuation feature now exists.
       If the user
       adds  \	to  the  end of an input line, _r_3_._m_a_p_c_a_l_c assumes
       that the
       formula being entered by the user continues on to the next
       input line.
       There is no limit to the possible number of input lines or
       to the length
       of a formula.

       If the _r_3_._m_a_p_c_a_l_c formula entered  by  the  user  is  very
       long, the
       map  title  will contain only some of it, but most (if not
       all) of the formula
       will be placed into the history file for the _r_e_s_u_l_t map.

       When the user enters input to _r_3_._m_a_p_c_a_l_c non-interactively
       on
       the  command  line, the program will not warn the user not
       to overwrite existing
       3D grids. Users should therefore take care to assign  pro-
       gram outputs 3D
       grid  file  names  that	do not yet exist in their current
       mapsets.

BBUUGGSS
       Continuation lines must end with a  and have  NO  trailing
       white space (blanks
       or tabs). If the user does leave white space at the end of
       continuation
       lines, the error messages produced by _r_3_._m_a_p_c_a_l_c  will  be
       meaningless
       and the equation will not work as the user intended.

       Error  messages produced by _r_3_._m_a_p_c_a_l_c are almost useless.
       In
       future,
       _r_3_._m_a_p_c_a_l_c should make some attempt to point the user to
       the offending section of the equation, e.g.:


	       ERROR: somewhere in line 1: ...	b ++ c ...
       Currently, there is no comment  mechanism  in  _r_3_._m_a_p_c_a_l_c.
       Perhaps
       adding a capability that would cause the entire line to be
       ignored when
       the user inserted a # at the start of a line as if it were
       not present,
       would do the trick.

       The  function  should  require  the  user to type "end" or
       "exit" instead
       of simply a blank line. This would make separation of mul-
       tiple scripts
       separable by white space.



SSEEEE AALLSSOO
       _r_._m_a_p_c_a_l_c

AAUUTTHHOORR
       Tomas  Paudits & Jaro Hofierka, funded by GeoModel s.r.o.,
       Slovakia

       tpaudits@mailbox.sk,
       hofierka@geomodel.sk

       _L_a_s_t _c_h_a_n_g_e_d_: _$_D_a_t_e_: _2_0_0_2_/_0_1_/_2_5 _0_5_:_4_5_:_3_5 _$



GRASS 5.0					    r3.mapcalc(1)
