Set the output location's region to the extent of your to-be-reprojected
data, before running r.proj in the input location.
tip:
v.proj'ing over a v.in.region box can help there. Then I usually try
to set the resolution to be a tiny bit better than the source rows x cols.
If there will bit a lot of rotation I try to set it even finer.
Set the output location's region to the extent of your to-be-reprojected
data, before running r.proj in the input location.
This message never arrived here.
Can I assume that "output location" is the destination and "input
location" is the source?
Then I will look in the WIND files for the boundaries of the two locations
and ensure that the larger is used in both.
tip: v.proj'ing over a v.in.region box can help there. Then I usually try
to set the resolution to be a tiny bit better than the source rows x cols.
If there will bit a lot of rotation I try to set it even finer.
I'll read the v.in.region man page and figure out how to use it to help
resolve my problem.
I saw the resolution option but have no idea how to determine what it is
or what it should be. This is the type of information I want to collect and
document so there's more extensive instructions than most man pages provide.
Germane to that last point: the r.proj man page includes conceptual detail
toward the end but no examples. The v.proj man page is the opposite. IMNSHO,
the r.proj detail should be in the wiki or other instructional documentation
and examples of usage should be on the man page.
Germane to that last point: the r.proj man page includes conceptual detail
toward the end but no examples. The v.proj man page is the opposite. IMNSHO,
the r.proj detail should be in the wiki or other instructional documentation
and examples of usage should be on the man page.
Rich
I've added an example to the r.proj man page in grass64_release, devbr6,
and trunk.
Set the output location's region to the extent of your to-be-reprojected
data, before running r.proj in the input location.
tip:
v.proj'ing over a v.in.region box can help there. Then I usually try
to set the resolution to be a tiny bit better than the source rows x cols.
If there will bit a lot of rotation I try to set it even finer.
Advice from either or both of you will help me quickly understand what
needs to be done so I can avoid future problems.
Here is the source (output?) location's WIND for the raster DEM:
tip: v.proj'ing over a v.in.region box can help there. Then I usually try
to set the resolution to be a tiny bit better than the source rows x cols.
If there will bit a lot of rotation I try to set it even finer.
Hamish,
I'm missing something important which is probably obvious to you and
others. The project location contains vector maps. My reading of the
v.in.region man page tells me its function is to "Create a new vector from
the current region." That suggests that the resulting output map is the same
as the displayed vector map but with a new name.
If I then run v.proj on the display of the new map what have I changed?
More importantly, how does that help resolve my inability to run r.proj on a
DEM map and reproject it to the project's location?
I'm no expert in projection or Grass for that matter but this is what
I understand about the way Grass projects rasters and vectors. Hope
not to be making things worse
In order to project a raster you have to "bring it in" your current
location from another location that has a different projection. That
is done using r.proj. The trick is that, when you bring your new
raster into the current location, it will respect you current region
settings, that is, limits and resolution. So, let's say you want to
project an Oregon map but you current region is set to Florida. This
will not work and your raster will not be projected.
So, in order to know where you projected raster will fall, you can use
the v.in.region trick. The command will create a bounding box in your
map and you can project the vector (using v.proj), and not wory about
the current region. Then you set your region to the recently projected
vector (g.region vect=box) and fix your resolution. Now you are ready
to project your raster and you know the current region matches the
region where your raster is coming from.
On Tue, Dec 22, 2009 at 2:54 PM, Rich Shepard <rshepard@appl-ecosys.com> wrote:
On Tue, 22 Dec 2009, Hamish wrote:
tip: v.proj'ing over a v.in.region box can help there. Then I usually try
to set the resolution to be a tiny bit better than the source rows x cols.
If there will bit a lot of rotation I try to set it even finer.
Hamish,
I'm missing something important which is probably obvious to you and
others. The project location contains vector maps. My reading of the
v.in.region man page tells me its function is to "Create a new vector from
the current region." That suggests that the resulting output map is the same
as the displayed vector map but with a new name.
If I then run v.proj on the display of the new map what have I changed?
More importantly, how does that help resolve my inability to run r.proj on a
DEM map and reproject it to the project's location?
So, in order to know where you projected raster will fall, you can use
the v.in.region trick. The command will create a bounding box in your
map and you can project the vector (using v.proj), and not wory about
the current region. Then you set your region to the recently projected
vector (g.region vect=box) and fix your resolution. Now you are ready
to project your raster and you know the current region matches the
region where your raster is coming from.
Daniel,
Despite my reading the r.proj man page I missed the critical point that
you and Hamish tried pointing out: that v.in.region is run on the raster
location, not the target location.
Working my way through the r.proj man page note (as you summarize above),
I end with screwy region results.
v.in.region worked; I call the output area (it should be area and not
line, correct?) 'dembox.' Exiting grass and restarting to reset the location
to that of the project, I ran 'v.proj input=dembox
location=dem10m_northwest' without error. However, running 'g.region
vect=dembox' followed by 'g.region -p' shows:
Could it be that the vector created by v.in.region is messed up, or
it's covering a larger area that you are not interested in?
Last time I used r.proj here is how I did it:
1) Go to source location and set the region to match the area I want to project
2) Create a bounding box (v.in.region)
3) Write down the resolution and number of columns, rows of the region
4) Exit grass and start over in new location
5) Bring in bounding box (v.proj)
6) Set region to bounding box (g.region vect=) and set resolution
(g.region res=xx). Here I follow Hamish advice and try to set the
number of col and row a bit higher then the number in the original
region.
7) Bring in raster (r.proj)
Cheers
Daniel
On Tue, Dec 22, 2009 at 3:59 PM, Rich Shepard <rshepard@appl-ecosys.com> wrote:
On Tue, 22 Dec 2009, Daniel Victoria wrote:
So, in order to know where you projected raster will fall, you can use
the v.in.region trick. The command will create a bounding box in your
map and you can project the vector (using v.proj), and not wory about
the current region. Then you set your region to the recently projected
vector (g.region vect=box) and fix your resolution. Now you are ready
to project your raster and you know the current region matches the
region where your raster is coming from.
Daniel,
Despite my reading the r.proj man page I missed the critical point that
you and Hamish tried pointing out: that v.in.region is run on the raster
location, not the target location.
Working my way through the r.proj man page note (as you summarize above),
I end with screwy region results.
v.in.region worked; I call the output area (it should be area and not
line, correct?) 'dembox.' Exiting grass and restarting to reset the location
to that of the project, I ran 'v.proj input=dembox
location=dem10m_northwest' without error. However, running 'g.region
vect=dembox' followed by 'g.region -p' shows:
Could it be that the vector created by v.in.region is messed up, or
it's covering a larger area that you are not interested in?
Daniel,
Anything's possible at this point. I've apparently trashed the target
location's projection; trying to set it to an existing vector map results in
negative values and an inability to display any of the reprojected vector
maps. I suppose I need to start over. Sigh. Can't bill the client for this
time.
Last time I used r.proj here is how I did it:
1) Go to source location and set the region to match the area I want to project
There are differences between the raster DEM location's region and that of
all the vector maps. The former is the northwest portion of the latter. I
would have thought that the smaller region would easily be accommodated by
the larger one, with (perhaps) the northern and western bounds adjusted to
match.
Ensure that the "Avoid duplicate copies of messages?" option is set to
"no".
Otherwise, if someone replies to one of your posts with "reply to all"
(which was the case for Maciej's reply), mailman won't send you a copy.
If the copy which was sent directly to you then gets dropped by a spam
filter, you won't see the message at all.
[Anyone at gmx.de with this "feature" enabled will never get a reply
from me, as gmx.de doesn't seem to like my IP address.]
and the destination location's PROJ_INFO file contains:
x_0: 399999.9999999999
Note: 1312336 * 0.3048 = 400000.0128
Both have meters as PROJ_UNITS.
The original metadata for the 10m DEM shows the following:
Planar_Distance_Units: User_Defined_Unit
Have your investigated the possibility of a feet/metres mismatch?
I suggest using m.proj in both the source and target locations to
check that both projections are correct. If they aren't, the results
of v.proj and r.proj will be nonsense.
Ensure that the "Avoid duplicate copies of messages?" option is set to
"no".
Glynn,
That's interesting. I've never set that for any other mail list. Ergo, the
others must default to 'no.'
Otherwise, if someone replies to one of your posts with "reply to all"
(which was the case for Maciej's reply), mailman won't send you a copy. If
the copy which was sent directly to you then gets dropped by a spam
filter, you won't see the message at all.
Well, if the duplicate copy block is set to 'yes,' but my address was
either the primary or in the cc field, shouldn't I get either the one To: me
or the one To: grass-users@lists.osgeo.org?
> Otherwise, if someone replies to one of your posts with "reply to all"
> (which was the case for Maciej's reply), mailman won't send you a copy. If
> the copy which was sent directly to you then gets dropped by a spam
> filter, you won't see the message at all.
Well, if the duplicate copy block is set to 'yes,' but my address was
either the primary or in the cc field, shouldn't I get either the one To: me
Provided that it wasn't blocked by a spam filter.
or the one To: grass-users@lists.osgeo.org?
No; the anti-duplicates option prevents that from being sent when
you're listed in the To/CC headers.
Mailman only knows whether you were listed in the To/CC headers; it
doesn't know whether you actually received the email directly from the
sender.
