Micha Silver wrote: > I guess my misunderstanding is just semantic. If the module were named > r.shift or r.translate I'd have no problem. > If I do something silly like: starting with a raster with an extent of > N=560000 and S=360000 and I run: > r.region map n=480000 s= 440000 > then the raster gets "squashed" into the smaller region. > > By comparison, there's no v.region which shifts where the vector > features are in space.
That's because the coordinates are an intrinsic part of the vector data. Transforming a vector involves modifying the data. A raster map is a rectangular grid of numbers; the georeferencing information is completely separate. The reason for r.region's existence is that if you import raster data which lacks georeferencing information, its bounds are arbitrarily set with one corner at <0,0> and the other corner at <w,h>, where w and h are the width and height of the grid in cells. In this situation, you need some mechanism to set the correct bounds; r.region is that mechanism. > But if I choose to shift a vector map, I use the > "move" tool in v.edit. That makes perfect sense, but r.region doing such > a shift caught me by surprise. So r.region seems closer to gdalwarp > that to any region settings. No; gdalwarp actually resamples the raster data to a new grid, while r.region only modifies the metadata. -- Glynn Clements <gl...@gclements.plus.com> _______________________________________________ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user