Micha wrote:
So r.region actually does a kind of affine transformation? I don't
remember seeing this documented anywhere (the manual says
"...manage the boundaries...") , and I must say it's confusing and
unexpected that a module called r.region (similar to g.region)
shifts/changes the data, rather than just defining the region
and resolution.
it does not touch the data array. It only modifies where that array is
thought to be in space. i.e. it just edits the $MAPSET/cellhd/$MAPNAME
file.
if you put new bounds which don't exactly match the array size it will
adjust your resolution so that it does.
Hamish
Hamish wrote:
Micha wrote:
So r.region actually does a kind of affine transformation? I don't
remember seeing this documented anywhere (the manual says
"...manage the boundaries...") , and I must say it's confusing and
unexpected that a module called r.region (similar to g.region)
shifts/changes the data, rather than just defining the region
and resolution.
it does not touch the data array. It only modifies where that array is
thought to be in space. i.e. it just edits the $MAPSET/cellhd/$MAPNAME
file.
if you put new bounds which don't exactly match the array size it will
adjust your resolution so that it does.
Hamish
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. 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.
Micha
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 <glynn@gclements.plus.com>
Thanks for this good explanation.
Here we clearly see the difference between a geodata library (gdalwarp)
and a GIS.
>> So r.region actually does a kind of affine transformation? I don't
>> remember seeing this documented anywhere (the manual says
>> "...manage the boundaries...") , and I must say it's confusing and
>> unexpected that a module called r.region (similar to g.region)
>> shifts/changes the data, rather than just defining the region
>> and resolution.
I guess my misunderstanding is just semantic. If the module were named
r.shift or r.translate I'd have no problem.
I must say that the ArcToolbox tool raster -> shift does not the same thing. It
seems to be a frontend to gdalwarp.
By comparison, there's no v.region which shifts where the vector
features are in space. 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.
Although being aware of the answer Hasmish posted:
What would be the appropriate way to adjust vectors for wrong bounding box?
I have also some vetcors that were digitized ontop of the wrongly adjusted
raster layers.
As there is no v.region, what tool would you recommend?
Thanks in advance,
Timmie
P.S.: Thanks to all for their responses. I am now under way to try them out.
On 01/05/09 20:54, Micha Silver wrote:
By comparison, there's no v.region which shifts where the vector features are in space.
What about v.transform ?
Moritz