The LiDAR source location has x- and y-resolution of 3 feet
(international) and several thousand cells east-west and north-south.
g.region -p for this location displays:
The LiDAR source location has x- and y-resolution of 3 feet
(international) and several thousand cells east-west and north-south.
g.region -p for this location displays:
The r.proj module has a flag to get the new resolution settings when reprojection data from one LOCATION to another. Before reprojecting the map from ** unknown (default: WGS84) ** to nad83harn, try r.proj -g. Then use those parameters to set the region in the new CRS/LOCATION. That will leave you with the same number of row and columns in the new projection. Then you’ll need to do r.proj again to get the raster reprojected with these new region settings.
···
On 21/09/2016 02:30, Rich Shepard wrote:
The LiDAR source location has x- and y-resolution of 3 feet
(international) and several thousand cells east-west and north-south.
g.region -p for this location displays:
The LiDAR source location has x- and y-resolution of 3 feet
(international) and several thousand cells east-west and north-south.
g.region -p for this location displays:
If it is about raster reprojection, there are hints in the r.proj manual
about region settings before applying r.proj.
E.g.
A simple way to do this is to check the projected bounds of the input map in
the current location's projection using the -p flag. The -g flag reports the
same thing, but in a form which can be directly cut and pasted into a
g.region command. After setting the region in that way you might check the
cell resolution with "g.region -p" then snap it to a regular grid with
g.region's -a flag. E.g. g.region -a res=5 -p. Note that this is just a
rough guide.
A more involved, but more accurate, way to do this is to generate a vector
"box" map of the region in the source location using v.in.region -d. This
"box" map is then reprojected into the target location with v.proj. Next the
region in the target location is set to the extent of the new vector map
with g.region along with the desired raster resolution (g.region -m can be
used in Latitude/Longitude locations to measure the geodetic length of a
pixel). r.proj is then run for the raster map the user wants to reproject.
In this case a little preparation goes a long way.
The LiDAR source location has x- and y-resolution of 3 feet
(international) and several thousand cells east-west and north-south.
g.region -p for this location displays:
I want to understand why the nsres is now 2561+ feet, the ewres now
1851+
feet, and the numbers of rows and columns has decreased so drastically.
Looking forward to learning,
Helmut Kudrnovsky:
If it is about raster reprojection, there are hints in the r.proj manual
about region settings before applying r.proj.
E.g.
A simple way to do this is to check the projected bounds of the input map in
the current location's projection using the -p flag. The -g flag reports the
same thing, but in a form which can be directly cut and pasted into a
g.region command.
A ready to copy-n-paste form is obtained via `-f` (this is a recent
addition by Moritz during the code sprint in Bonn).
Maybe the `-f` flag would be a useful addition to `r.proj` as well.
Nikos
After setting the region in that way you might check the
cell resolution with "g.region -p" then snap it to a regular grid with
g.region's -a flag. E.g. g.region -a res=5 -p. Note that this is just a
rough guide.
A more involved, but more accurate, way to do this is to generate a vector
"box" map of the region in the source location using v.in.region -d. This
"box" map is then reprojected into the target location with v.proj. Next the
region in the target location is set to the extent of the new vector map
with g.region along with the desired raster resolution (g.region -m can be
used in Latitude/Longitude locations to measure the geodetic length of a
pixel). r.proj is then run for the raster map the user wants to reproject.
In this case a little preparation goes a long way.
The LiDAR source location has x- and y-resolution of 3 feet
(international) and several thousand cells east-west and north-south.
g.region -p for this location displays:
I want to understand why the nsres is now 2561+ feet, the ewres now
1851+
feet, and the numbers of rows and columns has decreased so drastically.
Looking forward to learning,
Helmut Kudrnovsky:
If it is about raster reprojection, there are hints in the r.proj manual
about region settings before applying r.proj.
E.g.
A simple way to do this is to check the projected bounds of the input map in
the current location's projection using the -p flag. The -g flag reports the
same thing, but in a form which can be directly cut and pasted into a
g.region command.
The r.proj module has a flag to get the new resolution settings when
reprojection data from one LOCATION to another. Before reprojecting the
map from ** unknown (default: WGS84) ** to nad83harn, try r.proj -g. Then
use those parameters to set the region in the new CRS/LOCATION. That will
leave you with the same number of row and columns in the new projection.
Then you'll need to do r.proj again to get the raster reprojected with
these new region settings.
Micha,
Thank you. I did not recognize the value of coordinating resolutions when
re-projecting data. I'll back up and re-do all the data today.
If it is about raster reprojection, there are hints in the r.proj manual
about region settings before applying r.proj.
A simple way to do this is to check the projected bounds of the input map
in the current location's projection using the -p flag. The -g flag
reports the same thing, but in a form which can be directly cut and pasted
into a g.region command. After setting the region in that way you might
check the cell resolution with "g.region -p" then snap it to a regular
grid with g.region's -a flag. E.g. g.region -a res=5 -p. Note that this is
just a rough guide.
A more involved, but more accurate, way to do this is to generate a vector
"box" map of the region in the source location using v.in.region -d. This
"box" map is then reprojected into the target location with v.proj. Next
the region in the target location is set to the extent of the new vector
map with g.region along with the desired raster resolution (g.region -m
can be used in Latitude/Longitude locations to measure the geodetic length
of a pixel). r.proj is then run for the raster map the user wants to
reproject. In this case a little preparation goes a long way.
Helmut,
Thank you very much. This expansion of Micha's explanation is really
valuable and I greatly appreciate it. I wasn't aware of this need and
process the last time (years ago) I had a need to reproject data. Source
data in recent projects were all in the same projection and appropriate to
the area studied.
If it is about raster reprojection, there are hints in the r.proj manual
about region settings before applying r.proj.
A simple way to do this is to check the projected bounds of the input map
in the current location's projection using the -p flag. The -g flag
reports the same thing, but in a form which can be directly cut and
pasted
into a g.region command. After setting the region in that way you might
check the cell resolution with "g.region -p" then snap it to a regular
grid with g.region's -a flag. E.g. g.region -a res=5 -p. Note that this
is
just a rough guide.
A more involved, but more accurate, way to do this is to generate a
vector
"box" map of the region in the source location using v.in.region -d. This
"box" map is then reprojected into the target location with v.proj. Next
the region in the target location is set to the extent of the new vector
map with g.region along with the desired raster resolution (g.region -m
can be used in Latitude/Longitude locations to measure the geodetic
length
of a pixel). r.proj is then run for the raster map the user wants to
reproject. In this case a little preparation goes a long way.
Helmut,
Thank you very much. This expansion of Micha's explanation is really
valuable and I greatly appreciate it. I wasn't aware of this need and
process the last time (years ago) I had a need to reproject data. Source
data in recent projects were all in the same projection and appropriate to
the area studied.
Regards,
Rich
_______________________________________________
grass-user mailing list
