NAME

s.medp - Median polish for a GRASS sites list.
(GRASS Sites Program)

SYNOPSIS

s.medp
s.medp help
s.medp [-aeqs] sites=name vect=name output=name [report=name] [thresh=n]

DESCRIPTION

s.medp performs median polish on an existing sites list. The sites are overlayed onto a grid (vect=name) and each site is associated with the closest node. Therefore, sites do not necessarily have to be oriented on a grid. Each node may be associated with zero, one, or more sites and the grid may be rotated. Also, the length of each box does not have to be equal to width of each box defining the grid.

Once sites are associated with nodes on a p by q grid, p+q+1 extra storage locations are created (initialized to zero) to store all, row, and column effects. The median of each row is removed from the data and added to the extra p cells. Then, medians are removed from the data as well as from the p cells containing row effects. The medians of data in this pass are stored in the extra q cells (column effects) and the median of the row effects is stored in the extra (p+1, q+1) cell (all effect). This is repeated until each successive iteration leaves each site unchanged (within a tolerance, described by [thresh=n]).

OPTIONS

Flags:

-a
Use all sites found in the named sites file, rather than limiting output to sites falling within the current geographic region.
-e
Store row, column, and all effects in output file.
-s
Write results to a sites list file (default is to write points in a binary vector file).
-q
Quiet. Cut out the chatter.

Parameters:

sites=name
Name of an existing sites file.
vect=name
Name of the grid file (binary vector file).
output=name
Name of the output file (binary vector file or sites list).
report=name
Name of an ASCII file which shows original and residual data in tabular form.
thresh=n
Threshold to determine when convergence of median polish is obtained. (default = 1).

s.medp can be run either non-interactively or interactively. The program will be run non-interactively if the user specifies the name of an existing sites list file, name for a vect file, and name of an output file using the form

s.medp [-aeqs] sites=name vect=name output=name [report=name] [thresh=n]
Alternately, the user can simply type s.medp on the command line, without program arguments. In this case, the user will be prompted for parameter values using the standard GRASS parser interface.

NOTES

When using the report option, the tabular report may be more than 128 columns wide. Therefore, it may be useful to add a TeX or PostScript wrapper before printing (e.g., enscript -h -r -fCourier-Bold5 -p report.ps report) so that the page is in landscape orientation and a very small font is used.

The input vector file defining the grid should be large enough so that the extreme east-west and north-south nodes (for non-rotated grids) can be used to store row and column effects. Otherwise, when residuals and effects are written to the output file, residuals may share the same spatial location as effects when written to a vector output file.

Currently, nothing is done with the residuals, but I would like implement some sort of analysis of these in the future (suggestions?). Kriging using these residuals as new data set is being planned.

SEE ALSO

v.mkgrid
v.transform
parser

Cressie, Noel A. C. (1991). Statistics for Spatial Data, New York, NY: John Wiley & Sons. pp. 186-187.

BUGS

This should still be consider beta-release software. Although I have repeated results shown in Cressie (1991), I would greatly appreciate someone testing this further.

The -s flag is yet to be implemented.

This should probably be re-written to use points in a vector file as input (thus creating v.medp).

Ideally, I would also like to output three data files for plotting by a graphing program (e.g., g.gnuplot), but I never got around to doing this. The classic plot is to show three surfaces: data = trend + residuals. The trend can be obtained by extrapolation and/or interpolation.

Extrapolating and interpolating using the row, column, and all effects to create a raster file would be a nice feature to include in the future. Instead, I am considering retrieving the effects from the output file and creating the surface with separate program.

Please send all bug fixes and comments to the author.

AUTHOR

James Darrell McCauley, Agricultural Engineering Purdue University