Provided by: grass-doc_6.4.3-3_all 
NAME
r.proj - Re-projects a raster map from one location to the current location.
KEYWORDS
raster, projection, transformation
SYNOPSIS
r.proj
r.proj help
r.proj [-lnpg] [input=name] location=name [mapset=name] [dbase=path] [output=name]
[method=string] [memory=integer] [resolution=float] [--overwrite] [--verbose]
[--quiet]
Flags:
-l
List raster maps in input location and exit
-n
Do not perform region cropping optimization
-p
Print input map's bounds in the current projection and exit
-g
Print input map's bounds in the current projection and exit (shell style)
--overwrite
Allow output files to overwrite existing files
--verbose
Verbose module output
--quiet
Quiet module output
Parameters:
input=name
Name of input raster map to re-project
location=name
Location containing input raster map
mapset=name
Mapset containing input raster map
dbase=path
Path to GRASS database of input location
output=name
Name for output raster map (default: input)
method=string
Interpolation method to use
Options: nearest,bilinear,cubic
Default: nearest
memory=integer
Cache size (MiB)
resolution=float
Resolution of output map
DESCRIPTION
r.proj projects a raster map in a specified mapset of a specified location from the
projection of the input location to a raster map in the current location. The projection
information is taken from the current PROJ_INFO files, as set with g.setproj
and viewed with g.proj.
Introduction
Map projections Map projections are a method of representing information from a curved
surface (usually a spheroid) in two dimensions, typically to allow indexing through
cartesian coordinates. There are a wide variety of projections, with common ones divided
into a number of classes, including cylindrical and pseudo-cylindrical, conic and pseudo-
conic, and azimuthal methods, each of which may be conformal, equal-area, or neither.
The particular projection chosen depends on the purpose of the project, and the size,
shape and location of the area of interest. For example, normal cylindrical projections
are good for maps which are of greater extent east-west than north-south and in equatorial
regions, while conic projections are better in mid-latitudes; transverse cylindrical
projections are used for maps which are of greater extent north-south than east-west;
azimuthal projections are used for polar regions. Oblique versions of any of these may
also be used. Conformal projections preserve angular relationships, and better preserve
arc-length, while equal-area projections are more appropriate for statistical studies and
work in which the amount of material is important.
Projections are defined by precise mathematical relations, so the method of projecting
coordinates from a geographic reference frame (latitude-longitude) into a projected
cartesian reference frame (eg metres) is governed by these equations. Inverse projections
can also be achieved. The public-domain Unix software package PROJ.4 [1] has been
designed to perform these transformations, and the user's manual contains a detailed
description of over 100 useful projections. This also includes a programmers library of
the projection methods to support other software development.
Thus, converting a vector map - in which objects are located with arbitrary spatial
precision - from one projection into another is usually accomplished by a simple two-step
process: first the location of all the points in the map are converted from the source
through an inverse projection into latitude-longitude, and then through a forward
projection into the target. (Of course the procedure will be one-step if either the
source or target is in geographic coordinates.)
Converting a raster map, or image, between different projections, however, involves
additional considerations. A raster may be considered to represent a sampling of a
process at a regular, ordered set of locations. The set of locations that lie at the
intersections of a cartesian grid in one projection will not, in general, coincide with
the sample points in another projection. Thus, the conversion of raster maps involves an
interpolation step in which the values of points at intermediate locations relative to the
source grid are estimated. Projecting vector maps within the GRASS GIS GIS data capture,
import and transfer often requires a projection step, since the source or client will
frequently be in a different projection to the working projection.
In some cases it is convenient to do the conversion outside the package, prior to import
or after export, using software such as PROJ.4's cs2cs [1]. This is an easy method for
converting an ASCII file containing a list of coordinate points, since there is no
topology to be preserved and cs2cs can be used to process simple lists using a one-line
command. The m.proj module provides a handy front end to cs2cs.
The format of files containing vector maps with lines and arcs is generally more complex,
as parts of the data stored in the files will describe topology, and not just coordinates.
In GRASS GIS the v.proj module is provided to reproject vector maps, transferring topology
and attributes as well as node coordinates. This program uses the projection definition
and parameters which are stored in the PROJ_INFO and PROJ_UNITS files in the PERMANENT
mapset directory for every GRASS location.
Design of r.proj
As discussed briefly above, the fundamental step in re-projecting a raster is resampling
the source grid at locations corresponding to the intersections of a grid in the target
projection. The basic procedure for accomplishing this, therefore, is as follows:
r.proj converts a map to a new geographic projection. It reads a map from a different
location, projects it and write it out to the current location.
The projected data is resampled with one of three different methods: nearest neighbor,
bilinear and cubic convolution.
The method=nearest method, which performs a nearest neighbor assignment, is the fastest of
the three resampling methods. It is primarily used for categorical data such as a land use
classification, since it will not change the values of the data cells. The method=bilinear
method determines the new value of the cell based on a weighted distance average of the 4
surrounding cells in the input map. The method=cubic method determines the new value of
the cell based on a weighted distance average of the 16 surrounding cells in the input
map.
The bilinear and cubic interpolation methods are most appropriate for continuous data and
cause some smoothing. Both options should not be used with categorical data, since the
cell values will be altered.
If nearest neighbor assignment is used, the output map has the same raster format as the
input map. If any of the interpolations is used, the output map is written as floating
point.
Note that, following normal GRASS conventions, the coverage and resolution of the
resulting grid is set by the current region settings, which may be adjusted using
g.region. The target raster will be relatively unbiased for all cases if its grid has a
similar resolution to the source, so that the resampling/interpolation step is only a
local operation. If the resolution is changed significantly, then the behaviour of the
generalisation or refinement will depend on the model of the process being represented.
This will be very different for categorical versus numerical data. Note that three
methods for the local interpolation step are provided.
r.proj supports general datum transformations, making use of the PROJ.4 co-ordinate system
translation library.
NOTES
To avoid excessive time consumption when reprojecting a map the region and resolution of
the target location should be set appropriately beforehand.
A simple way to do this is to check the projected bounds of the input map in the current
location's projection using the -p flag. The -g flag reports the same thing, but in a form
which can be directly cut and pasted into a g.region command. After setting the region in
that way you might check the cell resolution with "g.region -p" then snap it to a regular
grid with g.region's -a flag. E.g. g.region -a res=5 -p. Note that this is just a rough
guide.
A more involved, but more accurate, way to do this is to generate a vector "box" map of
the region in the source location using v.in.region. This "box" map is then reprojected
into the target location with v.proj. Next the region in the target location is set to
the extent of the new vector map with g.region along with the desired raster resolution
(g.region -m can be used in Latitude/Longitude locations to measure the geodetic length of
a pixel). r.proj is then run for the raster map the user wants to reproject. In this
case a little preparation goes a long way.
When reprojecting whole-world maps the user should disable map-trimming with the -n flag.
Trimming is not useful here because the module has the whole map in memory anyway. Besides
that, world "edges" are hard (or impossible) to find in projections other than latitude-
longitude so results may be odd with trimming.
EXAMPLES
Inline method
With GRASS running in the destination location use the -g flag to show the input map's
bounds once reprojected into the current map projection, then use that to set the region
bounds before performing the reprojection:
# calculate where output map will be
GRASS> r.proj input=elevation location=ll_wgs84 mapset=user1 -p
Source cols: 8162
Source rows: 12277
Local north: -4265502.30382993
Local south: -4473453.15255565
Local west: 14271663.19157564
Local east: 14409956.2693866
# same calculation, but in a form which can be cut and pasted into a g.region call
GRASS> r.proj input=elevation location=ll_wgs84 mapset=user1 -g
n=-4265502.30382993 s=-4473453.15255565 w=14271663.19157564 e=14409956.2693866 rows=12277
col
s=8162
GRASS> g.region n=-4265502.30382993 s=-4473453.15255565 \
w=14271663.19157564 e=14409956.2693866 rows=12277 cols=8162 -p
projection: 99 (Mercator)
zone: 0
datum: wgs84
ellipsoid: wgs84
north: -4265502.30382993
south: -4473453.15255565
west: 14271663.19157564
east: 14409956.2693866
nsres: 16.93824621
ewres: 16.94352828
rows: 12277
cols: 8162
cells: 100204874
# round resolution to something cleaner
GRASS> g.region res=17 -a -p
projection: 99 (Mercator)
zone: 0
datum: wgs84
ellipsoid: wgs84
north: -4265487
south: -4473465
west: 14271653
east: 14409965
nsres: 17
ewres: 17
rows: 12234
cols: 8136
cells: 99535824
# finally, perform the reprojection
GRASS> r.proj input=elevation location=ll_wgs84 mapset=user1 memory=800
v.in.region method
# In the source location, use v.in.region to generate a bounding box around the
# region of interest:
v.in.region output=bounds type=area
# Now switch to the target location and import the vector bounding box
# (you can run v.proj -l to get a list of vector maps in the source location):
v.proj input=bounds location=source_location_name output=bounds_reprojected
# Set the region in the target location with that of the newly-imported vector
# bounds map, and align the resolution to the desired cell resolution of the
# final, reprojected raster map:
g.region vect=bounds_reprojected res=5 -a
# Now reproject the raster into the target location
r.proj input=elevation.dem output=elevation.dem.reproj \
location=source_location_name mapset=PERMANENT res=5 method=cubic
REFERENCES
[1] Evenden, G.I. (1990) Cartographic projection procedures for the UNIX environment - a
user's manual. USGS Open-File Report 90-284 (OF90-284.pdf) See also there: Interim Report
and 2nd Interim Report on Release 4, Evenden 1994).
Richards, John A. (1993), Remote Sensing Digital Image Analysis, Springer-Verlag, Berlin,
2nd edition.
PROJ.4: Projection/datum support library.
Further reading
ASPRS Grids and Datum
Projections Transform List (PROJ.4)
MapRef - The Collection of Map Projections and Reference Systems for Europe
Information and Service System for European Coordinate Reference Systems -
CRS
SEE ALSO
g.region, g.proj, g.setproj, i.rectify, m.proj, r.support, r.stats, v.proj, v.in.region
The 'gdalwarp' and 'gdal_translate' utilities are available from the GDAL project.
AUTHORS
Martin Schroeder, University of Heidelberg, Germany
Man page text from S.J.D. Cox, AGCRC, CSIRO Exploration & Mining, Nedlands, WA
Updated by Morten Hulden
Datum tranformation support and cleanup by Paul Kelly
Last changed: $Date: 2012-03-30 04:47:33 -0700 (Fri, 30 Mar 2012) $
Full index
© 2003-2013 GRASS Development Team