1r.proj(1)                     Grass User's Manual                    r.proj(1)
2
3
4

NAME

6       r.proj   -  Re-projects a raster map from given location to the current
7       location.
8

KEYWORDS

10       raster, projection, transformation, import
11

SYNOPSIS

13       r.proj
14       r.proj --help
15       r.proj    [-lnpg]    location=name     [mapset=name]       [input=name]
16       [dbase=path]     [output=name]     [method=string]     [memory=integer]
17       [resolution=float]     [pipeline=string]     [--overwrite]     [--help]
18       [--verbose]  [--quiet]  [--ui]
19
20   Flags:
21       -l
22           List raster maps in input mapset and exit
23
24       -n
25           Do not perform region cropping optimization
26
27       -p
28           Print input map’s bounds in the current projection and exit
29
30       -g
31           Print  input map’s bounds in the current projection and exit (shell
32           style)
33
34       --overwrite
35           Allow output files to overwrite existing files
36
37       --help
38           Print usage summary
39
40       --verbose
41           Verbose module output
42
43       --quiet
44           Quiet module output
45
46       --ui
47           Force launching GUI dialog
48
49   Parameters:
50       location=name [required]
51           Location containing input raster map
52           Location name (not location path)
53
54       mapset=name
55           Mapset containing input raster map
56           Default: name of current mapset
57
58       input=name
59           Name of input raster map to re-project
60
61       dbase=path
62           Path to GRASS database of input location
63           Default: path to the current GRASS GIS database
64
65       output=name
66           Name for output raster map (default: same as ’input’)
67
68       method=string
69           Interpolation method to use
70           Options: nearest, bilinear,  bicubic,  lanczos,  bilinear_f,  bicu‐
71           bic_f, lanczos_f
72           Default: nearest
73           nearest: nearest neighbor
74           bilinear: bilinear interpolation
75           bicubic: bicubic interpolation
76           lanczos: lanczos filter
77           bilinear_f: bilinear interpolation with fallback
78           bicubic_f: bicubic interpolation with fallback
79           lanczos_f: lanczos filter with fallback
80
81       memory=integer
82           Maximum memory to be used (in MB)
83           Cache size for raster rows
84           Default: 300
85
86       resolution=float
87           Resolution of output raster map
88
89       pipeline=string
90           PROJ pipeline for coordinate transformation
91

DESCRIPTION

93       r.proj projects a raster map in a specified mapset of a specified loca‐
94       tion from the projection of the input location to a raster map  in  the
95       current  location. The projection information is taken from the current
96       PROJ_INFO files, as set and viewed with g.proj.
97
98   Introduction
99   Map projections
100       Map projections are a method of representing information from a  curved
101       surface  (usually  a  spheroid)  in  two dimensions, typically to allow
102       indexing through cartesian coordinates.  There are a  wide  variety  of
103       projections, with common ones divided into a number of classes, includ‐
104       ing cylindrical and pseudo-cylindrical,  conic  and  pseudo-conic,  and
105       azimuthal  methods, each of which may be conformal, equal-area, or nei‐
106       ther.
107
108       The particular projection chosen depends on the purpose of the project,
109       and the size, shape and location of the area of interest.  For example,
110       normal cylindrical projections are good for maps which are  of  greater
111       extent  east-west  than  north-south  and  in equatorial regions, while
112       conic projections are better in mid-latitudes;  transverse  cylindrical
113       projections  are  used for maps which are of greater extent north-south
114       than east-west; azimuthal  projections  are  used  for  polar  regions.
115       Oblique  versions  of any of these may also be used.  Conformal projec‐
116       tions preserve angular relationships, and better  preserve  arc-length,
117       while equal-area projections are more appropriate for statistical stud‐
118       ies and work in which the amount of material is important.
119
120       Projections are defined  by  precise  mathematical  relations,  so  the
121       method  of  projecting  coordinates  from  a geographic reference frame
122       (latitude-longitude) into a projected  cartesian  reference  frame  (eg
123       metres)  is  governed by these equations.  Inverse projections can also
124       be achieved.  The public-domain Unix software package  PROJ.4  [1]  has
125       been  designed  to perform these transformations, and the user’s manual
126       contains a detailed description of over 100 useful  projections.   This
127       also  includes  a programmers library of the projection methods to sup‐
128       port other software development.
129
130       Thus, converting a vector map - in which objects are located with arbi‐
131       trary  spatial  precision - from one projection into another is usually
132       accomplished by a simple two-step process: first the  location  of  all
133       the  points in the map are converted from the source through an inverse
134       projection into latitude-longitude, and then through a forward  projec‐
135       tion  into  the  target.   (Of course the procedure will be one-step if
136       either the source or target is in geographic coordinates.)
137
138       Converting a raster map, or image, between different projections,  how‐
139       ever,  involves  additional considerations.  A raster may be considered
140       to represent a sampling of a process at a regular, ordered set of loca‐
141       tions.   The set of locations that lie at the intersections of a carte‐
142       sian grid in one projection will not, in  general,  coincide  with  the
143       sample  points  in  another projection.  Thus, the conversion of raster
144       maps involves an interpolation step in which the values  of  points  at
145       intermediate locations relative to the source grid are estimated.
146
147   Projecting vector maps within the GRASS GIS
148       GIS data capture, import and transfer often requires a projection step,
149       since the source or client will frequently be in a different projection
150       to the working projection.
151
152       In  some  cases it is convenient to do the conversion outside the pack‐
153       age, prior to import or after export, using software such  as  PROJ.4’s
154       cs2cs [1]. This is an easy method for converting an ASCII file contain‐
155       ing a list of coordinate points, since there is no topology to be  pre‐
156       served  and  cs2cs can be used to process simple lists using a one-line
157       command. The m.proj module provides a handy front end to cs2cs.
158
159       Vector maps is generally more complex, as parts of the data  stored  in
160       the  files  will  describe topology, and not just coordinates. In GRASS
161       GIS the v.proj module is provided to reproject vector  maps,  transfer‐
162       ring topology and attributes as well as node coordinates.  This program
163       uses the projection definition and parameters which are stored  in  the
164       PROJ_INFO  and  PROJ_UNITS  files in the PERMANENT mapset directory for
165       every GRASS location.
166
167   Design of r.proj
168       As discussed briefly above, the fundamental  step  in  re-projecting  a
169       raster  is resampling the source grid at locations corresponding to the
170       intersections of a grid in the target projection. The  basic  procedure
171       for accomplishing this, therefore, is as follows:
172
173       r.proj  converts  a  map to a new geographic projection. It reads a map
174       from a different location, projects it and write it out to the  current
175       location.  The  projected  data is resampled with one of four different
176       methods: nearest neighbor, bilinear, bicubic iterpolation or lanczos.
177
178       The method=nearest method, which performs a  nearest  neighbor  assign‐
179       ment,  is  the fastest of the three resampling methods. It is primarily
180       used for categorical data such as a land use classification,  since  it
181       will  not  change  the  values  of  the data cells. The method=bilinear
182       method determines the new value of the cell based on  a  weighted  dis‐
183       tance  average  of  the  4  surrounding  cells  in  the  input map. The
184       method=bicubic method determines the new value of the cell based  on  a
185       weighted distance average of the 16 surrounding cells in the input map.
186       The method=lanzcos method determines the new value of the cell based on
187       a  weighted  distance  average of the 25 surrounding cells in the input
188       map. Compared to bicubic, lanczos puts a higher weight on  cells  close
189       to the center and a lower weight on cells away from the center, result‐
190       ing in slightly better contrast.
191
192       The bilinear, bicubic and lanczos interpolation methods are most appro‐
193       priate  for  continuous  data  and  cause some smoothing. The amount of
194       smoothing decreases from bilinear to bicubic to lanczos. These  options
195       should not be used with categorical data, since the cell values will be
196       altered.
197
198       In the bilinear, bicubic and lanczos methods, if any of the surrounding
199       cells  used  to  interpolate the new cell value are null, the resulting
200       cell will be null, even if the nearest cell  is  not  null.  This  will
201       cause  some  thinning  along  null  borders, such as the coasts of land
202       areas in a DEM. The bilinear_f, bicubic_f and  lanczos_f  interpolation
203       methods can be used if thinning along null edges is not desired.  These
204       methods "fall back" to simpler interpolation methods  along  null  bor‐
205       ders.  That is, from lanczos to bicubic to bilinear to nearest.
206
207       If  nearest  neighbor  assignment  is used, the output map has the same
208       raster format as the input map. If any of the interpolations  is  used,
209       the output map is written as floating point.
210
211       Note that, following normal GRASS conventions, the coverage and resolu‐
212       tion of the resulting grid is set by the current region settings, which
213       may  be  adjusted  using g.region. The target raster will be relatively
214       unbiased for all cases if its grid has  a  similar  resolution  to  the
215       source, so that the resampling/interpolation step is only a local oper‐
216       ation.  If the resolution is changed significantly, then the  behaviour
217       of  the  generalisation  or  refinement will depend on the model of the
218       process being represented.  This will be very different for categorical
219       versus  numerical data.  Note that three methods for the local interpo‐
220       lation step are provided.
221
222       r.proj supports general datum transformations, making use of the PROJ.4
223       co-ordinate system translation library.
224

NOTES

226       If output is not specified it is set to be the same as input map name.
227       If  mapset  is not specified, its name is assumed to be the same as the
228       current mapset’s name.
229       If dbase is not specified it is assumed to be the current database. The
230       user  only  has  to  specify  dbase if the source location is stored in
231       another separate GRASS database.
232
233       To avoid excessive time consumption when reprojecting a map the  region
234       and  resolution  of  the  target  location  should be set appropriately
235       beforehand.
236
237       A simple way to do this is to check the projected bounds of  the  input
238       map in the current location’s projection using the -p flag. The -g flag
239       reports the same thing, but in a form which can  be  directly  cut  and
240       pasted  into  a  g.region command. After setting the region in that way
241       you might check the cell resolution with "g.region -p" then snap it  to
242       a  regular  grid  with  g.region’s -a flag. E.g.  g.region -a res=5 -p.
243       Note that this is just a rough guide.
244
245       A more involved, but more accurate, way to do this  is  to  generate  a
246       vector "box" map of the region in the source location using v.in.region
247       -d.  This "box" map is then reprojected into the target  location  with
248       v.proj.  Next the region in the target location is set to the extent of
249       the new vector map with g.region along with the desired raster  resolu‐
250       tion  (g.region  -m can be used in Latitude/Longitude locations to mea‐
251       sure the geodetic length of a pixel).   r.proj  is  then  run  for  the
252       raster map the user wants to reproject.  In this case a little prepara‐
253       tion goes a long way.
254
255       When reprojecting whole-world maps the user should disable map-trimming
256       with  the  -n  flag. Trimming is not useful here because the module has
257       the whole map in memory anyway. Besides that, world  "edges"  are  hard
258       (or impossible) to find in projections other than latitude-longitude so
259       results may be odd with trimming.
260

EXAMPLES

262   Inline method
263       With GRASS running in the destination location use the -g flag to  show
264       the  input map’s bounds once projected into the current working projec‐
265       tion, then use that to set the  region  bounds  before  performing  the
266       reprojection:
267       # calculate where output map will be
268       r.proj input=elevation location=ll_wgs84 mapset=user1 -p
269       Source cols: 8162
270       Source rows: 12277
271       Local north: -4265502.30382993
272       Local south: -4473453.15255565
273       Local west: 14271663.19157564
274       Local east: 14409956.2693866
275       # same calculation, but in a form which can be cut and pasted into a g.region call
276       r.proj input=elevation location=ll_wgs84 mapset=user1 -g
277       n=-4265502.30382993 s=-4473453.15255565 w=14271663.19157564 e=14409956.2693866 rows=12277 cols=8162
278       g.region n=-4265502.30382993 s=-4473453.15255565 \
279         w=14271663.19157564 e=14409956.2693866 rows=12277 cols=8162 -p
280       projection: 99 (Mercator)
281       zone:       0
282       datum:      wgs84
283       ellipsoid:  wgs84
284       north:      -4265502.30382993
285       south:      -4473453.15255565
286       west:       14271663.19157564
287       east:       14409956.2693866
288       nsres:      16.93824621
289       ewres:      16.94352828
290       rows:       12277
291       cols:       8162
292       cells:      100204874
293       # round resolution to something cleaner
294       g.region res=17 -a -p
295       projection: 99 (Mercator)
296       zone:       0
297       datum:      wgs84
298       ellipsoid:  wgs84
299       north:      -4265487
300       south:      -4473465
301       west:       14271653
302       east:       14409965
303       nsres:      17
304       ewres:      17
305       rows:       12234
306       cols:       8136
307       cells:      99535824
308       # finally, perform the reprojection
309       r.proj input=elevation location=ll_wgs84 mapset=user1 memory=800
310
311   v.in.region method
312       # In the source location, use v.in.region to generate a bounding box around the
313       # region of interest:
314       v.in.region -d output=bounds type=area
315       # Now switch to the target location and import the vector bounding box
316       # (you can run v.proj -l to get a list of vector maps in the source location):
317       v.proj input=bounds location=source_location_name output=bounds_reprojected
318       # Set the region in the target location with that of the newly-imported vector
319       # bounds map, and align the resolution to the desired cell resolution of the
320       # final, reprojected raster map:
321       g.region vector=bounds_reprojected res=5 -a
322       # Now reproject the raster into the target location
323       r.proj input=elevation.dem output=elevation.dem.reproj \
324       location=source_location_name mapset=PERMANENT res=5 method=bicubic
325

REFERENCES

327       1      Evenden, G.I.  (1990) Cartographic projection procedures for the
328              UNIX environment -  a  user’s  manual.   USGS  Open-File  Report
329              90-284  (OF90-284.pdf)  See  also  there: Interim Report and 2nd
330              Interim Report on Release 4, Evenden 1994).
331
332       2      Richards, John A. (1993), Remote Sensing Digital Image Analysis,
333              Springer-Verlag, Berlin, 2nd edition.
334
335       PROJ 4: Projection/datum support library.
336
337       Further reading
338
339           ·   ASPRS Grids and Datum
340
341           ·   Projections Transform List (PROJ.4)
342
343           ·   MapRef  -  The Collection of Map Projections and Reference Sys‐
344               tems for Europe
345
346           ·   Information and Service System for European  Coordinate  Refer‐
347               ence Systems - CRS
348
349           ·   Cartographical Map Projections by Carlos A. Furuti
350

SEE ALSO

352         g.region,  g.proj,  i.rectify,  m.proj,  r.support,  r.stats, v.proj,
353       v.in.region
354
355       The ’gdalwarp’ and ’gdal_translate’ utilities are  available  from  the
356       GDAL project.
357

AUTHORS

359       Martin Schroeder, University of Heidelberg, Germany
360       Man  page text from S.J.D. Cox, AGCRC, CSIRO Exploration & Mining, Ned‐
361       lands, WA
362       Updated by Morten Hulden
363       Datum transformation support and cleanup by Paul Kelly
364
365       Last changed: $Date: 2016-01-29 10:29:57 +0100 (Fri, 29 Jan 2016) $
366

SOURCE CODE

368       Available at: r.proj source code (history)
369
370       Main index | Raster index | Topics index | Keywords index  |  Graphical
371       index | Full index
372
373       © 2003-2019 GRASS Development Team, GRASS GIS 7.6.0 Reference Manual
374
375
376
377GRASS 7.6.0                                                          r.proj(1)
Impressum