1r.proj(1) Grass User's Manual r.proj(1)
2
6 r.proj - Re-projects a raster map from given location to the current
7 location.
8
10 raster, projection, transformation, import
11
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] [--overwrite] [--help] [--verbose] [--quiet]
18 [--ui]
19 Flags:
21 -l
22 List raster maps in input mapset and exit
23 -n
25 Do not perform region cropping optimization
26 -p
28 Print input map’s bounds in the current projection and exit
29 -g
31 Print input map’s bounds in the current projection and exit (shell
32 style)
33 --overwrite
35 Allow output files to overwrite existing files
36 --help
38 Print usage summary
39 --verbose
41 Verbose module output
42 --quiet
44 Quiet module output
45 --ui
47 Force launching GUI dialog
48 Parameters:
50 location=name [required]
51 Location containing input raster map
52 Location name (not location path)
53 mapset=name
55 Mapset containing input raster map
56 Default: name of current mapset
57 input=name
59 Name of input raster map to re-project
60 dbase=path
62 Path to GRASS database of input location
63 Default: path to the current GRASS GIS database
64 output=name
66 Name for output raster map (default: same as ’input’)
67 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 memory=integer
82 Maximum memory to be used (in MB)
83 Cache size for raster rows
84 Default: 300
85 resolution=float
87 Resolution of output raster map
88
90 r.proj projects a raster map in a specified mapset of a specified loca‐
91 tion from the projection of the input location to a raster map in the
92 current location. The projection information is taken from the current
93 PROJ_INFO files, as set and viewed with g.proj.
94 Introduction
96 Map projections
97 Map projections are a method of representing information from a curved
98 surface (usually a spheroid) in two dimensions, typically to allow
99 indexing through cartesian coordinates. There are a wide variety of
100 projections, with common ones divided into a number of classes, includ‐
101 ing cylindrical and pseudo-cylindrical, conic and pseudo-conic, and
102 azimuthal methods, each of which may be conformal, equal-area, or nei‐
103 ther.
104 The particular projection chosen depends on the purpose of the project,
106 and the size, shape and location of the area of interest. For example,
107 normal cylindrical projections are good for maps which are of greater
108 extent east-west than north-south and in equatorial regions, while
109 conic projections are better in mid-latitudes; transverse cylindrical
110 projections are used for maps which are of greater extent north-south
111 than east-west; azimuthal projections are used for polar regions.
112 Oblique versions of any of these may also be used. Conformal projec‐
113 tions preserve angular relationships, and better preserve arc-length,
114 while equal-area projections are more appropriate for statistical stud‐
115 ies and work in which the amount of material is important.
116 Projections are defined by precise mathematical relations, so the
118 method of projecting coordinates from a geographic reference frame
119 (latitude-longitude) into a projected cartesian reference frame (eg
120 metres) is governed by these equations. Inverse projections can also
121 be achieved. The public-domain Unix software package PROJ.4 [1] has
122 been designed to perform these transformations, and the user’s manual
123 contains a detailed description of over 100 useful projections. This
124 also includes a programmers library of the projection methods to sup‐
125 port other software development.
126 Thus, converting a vector map - in which objects are located with arbi‐
128 trary spatial precision - from one projection into another is usually
129 accomplished by a simple two-step process: first the location of all
130 the points in the map are converted from the source through an inverse
131 projection into latitude-longitude, and then through a forward projec‐
132 tion into the target. (Of course the procedure will be one-step if
133 either the source or target is in geographic coordinates.)
134 Converting a raster map, or image, between different projections, how‐
136 ever, involves additional considerations. A raster may be considered
137 to represent a sampling of a process at a regular, ordered set of loca‐
138 tions. The set of locations that lie at the intersections of a carte‐
139 sian grid in one projection will not, in general, coincide with the
140 sample points in another projection. Thus, the conversion of raster
141 maps involves an interpolation step in which the values of points at
142 intermediate locations relative to the source grid are estimated.
143 Projecting vector maps within the GRASS GIS
145 GIS data capture, import and transfer often requires a projection step,
146 since the source or client will frequently be in a different projection
147 to the working projection.
148 In some cases it is convenient to do the conversion outside the pack‐
150 age, prior to import or after export, using software such as PROJ.4’s
151 cs2cs [1]. This is an easy method for converting an ASCII file contain‐
152 ing a list of coordinate points, since there is no topology to be pre‐
153 served and cs2cs can be used to process simple lists using a one-line
154 command. The m.proj module provides a handy front end to cs2cs.
155 Vector maps is generally more complex, as parts of the data stored in
157 the files will describe topology, and not just coordinates. In GRASS
158 GIS the v.proj module is provided to reproject vector maps, transfer‐
159 ring topology and attributes as well as node coordinates. This program
160 uses the projection definition and parameters which are stored in the
161 PROJ_INFO and PROJ_UNITS files in the PERMANENT mapset directory for
162 every GRASS location.
163 Design of r.proj
165 As discussed briefly above, the fundamental step in re-projecting a
166 raster is resampling the source grid at locations corresponding to the
167 intersections of a grid in the target projection. The basic procedure
168 for accomplishing this, therefore, is as follows:
169 r.proj converts a map to a new geographic projection. It reads a map
171 from a different location, projects it and write it out to the current
172 location. The projected data is resampled with one of four different
173 methods: nearest neighbor, bilinear, bicubic iterpolation or lanczos.
174 The method=nearest method, which performs a nearest neighbor assign‐
176 ment, is the fastest of the three resampling methods. It is primarily
177 used for categorical data such as a land use classification, since it
178 will not change the values of the data cells. The method=bilinear
179 method determines the new value of the cell based on a weighted dis‐
180 tance average of the 4 surrounding cells in the input map. The
181 method=bicubic method determines the new value of the cell based on a
182 weighted distance average of the 16 surrounding cells in the input map.
183 The method=lanzcos method determines the new value of the cell based on
184 a weighted distance average of the 25 surrounding cells in the input
185 map. Compared to bicubic, lanczos puts a higher weight on cells close
186 to the center and a lower weight on cells away from the center, result‐
187 ing in slightly better contrast.
188 The bilinear, bicubic and lanczos interpolation methods are most appro‐
190 priate for continuous data and cause some smoothing. The amount of
191 smoothing decreases from bilinear to bicubic to lanczos. These options
192 should not be used with categorical data, since the cell values will be
193 altered.
194 In the bilinear, bicubic and lanczos methods, if any of the surrounding
196 cells used to interpolate the new cell value are null, the resulting
197 cell will be null, even if the nearest cell is not null. This will
198 cause some thinning along null borders, such as the coasts of land
199 areas in a DEM. The bilinear_f, bicubic_f and lanczos_f interpolation
200 methods can be used if thinning along null edges is not desired. These
201 methods "fall back" to simpler interpolation methods along null bor‐
202 ders. That is, from lanczos to bicubic to bilinear to nearest.
203 If nearest neighbor assignment is used, the output map has the same
205 raster format as the input map. If any of the interpolations is used,
206 the output map is written as floating point.
207 Note that, following normal GRASS conventions, the coverage and resolu‐
209 tion of the resulting grid is set by the current region settings, which
210 may be adjusted using g.region. The target raster will be relatively
211 unbiased for all cases if its grid has a similar resolution to the
212 source, so that the resampling/interpolation step is only a local oper‐
213 ation. If the resolution is changed significantly, then the behaviour
214 of the generalisation or refinement will depend on the model of the
215 process being represented. This will be very different for categorical
216 versus numerical data. Note that three methods for the local interpo‐
217 lation step are provided.
218 r.proj supports general datum transformations, making use of the PROJ.4
220 co-ordinate system translation library.
221
223 If output is not specified it is set to be the same as input map name.
224 If mapset is not specified, its name is assumed to be the same as the
225 current mapset’s name.
226 If dbase is not specified it is assumed to be the current database. The
227 user only has to specify dbase if the source location is stored in
228 another separate GRASS database.
229 To avoid excessive time consumption when reprojecting a map the region
231 and resolution of the target location should be set appropriately
232 beforehand.
233 A simple way to do this is to check the projected bounds of the input
235 map in the current location’s projection using the -p flag. The -g flag
236 reports the same thing, but in a form which can be directly cut and
237 pasted into a g.region command. After setting the region in that way
238 you might check the cell resolution with "g.region -p" then snap it to
239 a regular grid with g.region’s -a flag. E.g. g.region -a res=5 -p.
240 Note that this is just a rough guide.
241 A more involved, but more accurate, way to do this is to generate a
243 vector "box" map of the region in the source location using v.in.region
244 -d. This "box" map is then reprojected into the target location with
245 v.proj. Next the region in the target location is set to the extent of
246 the new vector map with g.region along with the desired raster resolu‐
247 tion (g.region -m can be used in Latitude/Longitude locations to mea‐
248 sure the geodetic length of a pixel). r.proj is then run for the
249 raster map the user wants to reproject. In this case a little prepara‐
250 tion goes a long way.
251 When reprojecting whole-world maps the user should disable map-trimming
253 with the -n flag. Trimming is not useful here because the module has
254 the whole map in memory anyway. Besides that, world "edges" are hard
255 (or impossible) to find in projections other than latitude-longitude so
256 results may be odd with trimming.
257
259 Inline method
260 With GRASS running in the destination location use the -g flag to show
261 the input map’s bounds once projected into the current working projec‐
262 tion, then use that to set the region bounds before performing the
263 reprojection:
264 # calculate where output map will be
265 r.proj input=elevation location=ll_wgs84 mapset=user1 -p
266 Source cols: 8162
267 Source rows: 12277
268 Local north: -4265502.30382993
269 Local south: -4473453.15255565
270 Local west: 14271663.19157564
271 Local east: 14409956.2693866
272 # same calculation, but in a form which can be cut and pasted into a g.region call
273 r.proj input=elevation location=ll_wgs84 mapset=user1 -g
274 n=-4265502.30382993 s=-4473453.15255565 w=14271663.19157564 e=14409956.2693866 rows=12277 cols=8162
275 g.region n=-4265502.30382993 s=-4473453.15255565 \
276 w=14271663.19157564 e=14409956.2693866 rows=12277 cols=8162 -p
277 projection: 99 (Mercator)
278 zone: 0
279 datum: wgs84
280 ellipsoid: wgs84
281 north: -4265502.30382993
282 south: -4473453.15255565
283 west: 14271663.19157564
284 east: 14409956.2693866
285 nsres: 16.93824621
286 ewres: 16.94352828
287 rows: 12277
288 cols: 8162
289 cells: 100204874
290 # round resolution to something cleaner
291 g.region res=17 -a -p
292 projection: 99 (Mercator)
293 zone: 0
294 datum: wgs84
295 ellipsoid: wgs84
296 north: -4265487
297 south: -4473465
298 west: 14271653
299 east: 14409965
300 nsres: 17
301 ewres: 17
302 rows: 12234
303 cols: 8136
304 cells: 99535824
305 # finally, perform the reprojection
306 r.proj input=elevation location=ll_wgs84 mapset=user1 memory=800
307 v.in.region method
309 # In the source location, use v.in.region to generate a bounding box around the
310 # region of interest:
311 v.in.region -d output=bounds type=area
312 # Now switch to the target location and import the vector bounding box
313 # (you can run v.proj -l to get a list of vector maps in the source location):
314 v.proj input=bounds location=source_location_name output=bounds_reprojected
315 # Set the region in the target location with that of the newly-imported vector
316 # bounds map, and align the resolution to the desired cell resolution of the
317 # final, reprojected raster map:
318 g.region vector=bounds_reprojected res=5 -a
319 # Now reproject the raster into the target location
320 r.proj input=elevation.dem output=elevation.dem.reproj \
321 location=source_location_name mapset=PERMANENT res=5 method=bicubic
322
324 1 Evenden, G.I. (1990) Cartographic projection procedures for the
325 UNIX environment - a user’s manual. USGS Open-File Report
326 90-284 (OF90-284.pdf) See also there: Interim Report and 2nd
327 Interim Report on Release 4, Evenden 1994).
328 2 Richards, John A. (1993), Remote Sensing Digital Image Analysis,
330 Springer-Verlag, Berlin, 2nd edition.
331 PROJ 4: Projection/datum support library.
333 Further reading
335 · ASPRS Grids and Datum
337 · Projections Transform List (PROJ.4)
339 · MapRef - The Collection of Map Projections and Reference Sys‐
341 tems for Europe
342 · Information and Service System for European Coordinate Refer‐
344 ence Systems - CRS
345 · Cartographical Map Projections by Carlos A. Furuti
347
349 g.region, g.proj, i.rectify, m.proj, r.support, r.stats, v.proj,
350 v.in.region
351 The ’gdalwarp’ and ’gdal_translate’ utilities are available from the
353 GDAL project.
354
356 Martin Schroeder, University of Heidelberg, Germany
357 Man page text from S.J.D. Cox, AGCRC, CSIRO Exploration & Mining, Ned‐
358 lands, WA
359 Updated by Morten Hulden
360 Datum transformation support and cleanup by Paul Kelly
361 Last changed: $Date: 2016-01-29 10:29:57 +0100 (Fri, 29 Jan 2016) $
363
365 Available at: r.proj source code (history)
366 Main index | Raster index | Topics index | Keywords index | Graphical
368 index | Full index
369 © 2003-2019 GRASS Development Team, GRASS GIS 7.4.4 Reference Manual
371GRASS 7.4.4 r.proj(1)