1r.proj(1) GRASS GIS User's Manual r.proj(1)
2
3
4
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=memory in MB]
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=memory in MB
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
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 in‐
102 dexing through cartesian coordinates. There are a wide variety of pro‐
103 jections, with common ones divided into a number of classes, including
104 cylindrical and pseudo-cylindrical, conic and pseudo-conic, and az‐
105 imuthal 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 me‐
123 tres) is governed by these equations. Inverse projections can also be
124 achieved. The public-domain Unix software package PROJ [1] has been
125 designed to perform these transformations, and the user’s manual con‐
126 tains a detailed description of over 100 useful projections. This also
127 includes a programmers library of the projection methods to support
128 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 ei‐
136 ther 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’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 interpolation 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=lanczos 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 ar‐
202 eas 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
223 co-ordinate system translation library.
224
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 an‐
231 other 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 be‐
235 forehand.
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
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 re‐
266 projection:
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
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 In‐
330 terim 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: Projection/datum support library
336
337 Further reading
338
339 • ASPRS Grids and Datum
340
341 • Projections Transform List (PROJ)
342
343 • Coordinate operations by PROJ (projections, conversions, trans‐
344 formations, pipeline operator)
345
346 • MapRef - The Collection of Map Projections and Reference Sys‐
347 tems for Europe
348
349 • Information and Service System for European Coordinate Refer‐
350 ence Systems - CRS
351
353 g.region, g.proj, i.rectify, m.proj, r.support, r.stats, v.proj,
354 v.in.region
355
356 The ’gdalwarp’ and ’gdal_translate’ utilities are available from the
357 GDAL project.
358
360 Martin Schroeder, University of Heidelberg, Germany
361 Man page text from S.J.D. Cox, AGCRC, CSIRO Exploration & Mining, Ned‐
362 lands, WA
363 Updated by Morten Hulden
364 Datum transformation support and cleanup by Paul Kelly
365 Support of PROJ5+ by Markus Metz, mundialis
366
368 Available at: r.proj source code (history)
369
370 Accessed: Saturday Jan 21 20:38:55 2023
371
372 Main index | Raster index | Topics index | Keywords index | Graphical
373 index | Full index
374
375 © 2003-2023 GRASS Development Team, GRASS GIS 8.2.1 Reference Manual
376
377
378
379GRASS 8.2.1 r.proj(1)