Hi David,
Thanks for the response. I realize that -n lets you not crop the map,
however it still only projects in information if it is in your current
region. What I was hoping for was to be able to set your region based
on the incoming raster. For example, if the bounding box for my
incoming map is 34N 32S 118W 117W in a lat-long location, how would I
know what the corresponding UTM coordinates are? I can project it from
some random place in the UTM location with -n, but it will only bring
in data if I happened to overlap with the incoming raster. Do you see
the dilemma? What I am looking for is a flag that sets the region to
the incoming raster.
In addition, I don't think that m.ll2u is included in the 5.7 release.
I am not sure how one could even project from a lat-long to a utm in
5.7 if you didn't have the UTM coordinates already (at least with
minimal effort).
Thanks,
-Ian
PS I hope I am not complaining too much, I love grass, and am amazed at
all the developers do. Just wanted to point out an awkward feature,
and see if I am missing something.
On Sep 3, 2004, at 10:27 AM, mahoneyd@unbc.ca wrote:
The -n option causes r.proj not to crop the resulting map to the
current
region
Cheers,
David
On Thu, 2 Sep 2004, Ian Macmillan wrote:
Hi all, I have a request for a feature to be added to r.proj, or if I
am missing
something, could somebody tell me? When you use r.proj, it is
necessary to
know the region before hand. Most times this isn't a problem, but
going from
lat-long to utm or vice-versa, this requires the awkward steps of
using m.ll2u
or m.u2ll on points you get from r.info, copying this information
down, then
setting your region by hand in the new location based on the output
of m.ll2u.
This is kind of a non-intuitive method that is difficult for new
people to
figure out. What would be nice is a flag in r.proj to set the region
in the
new location based on the bounding coordinates of the raster being
projected
in. Is this solution too difficult to implement? Unfortunately I
don't know
how to code, so I don't think I can do it myself. Anybody else
have this
problem?
Thanks,
Ian
Hello Ian
On Fri, 3 Sep 2004, Ian MacMillan wrote:
know what the corresponding UTM coordinates are? I can project it from
some random place in the UTM location with -n, but it will only bring
in data if I happened to overlap with the incoming raster. Do you see
the dilemma? What I am looking for is a flag that sets the region to
the incoming raster.
r.proj works in reverse, because it has to do cell re-sampling. For each cell in the target location it back-projects it into the source and then does interpolation between the neighbouring cells to determine the new value.
As far as I understand it anyway, this means it is not really possible to do what you are suggesting. Also there is no guaranteed way of knowing the extents of the raster in the target location before every cell in the source location is forward-projected (assuming you were doing a forward projection, which r.proj doesn't). It depends on the projection. What I'm saying is that a region which is rectangular in one direction will not be rectangular in another. It can be very complicated to work out the new extents in advance and probably can only be done with heuristic / appoximation methods.
In addition, I don't think that m.ll2u is included in the 5.7 release.
I am not sure how one could even project from a lat-long to a utm in
5.7 if you didn't have the UTM coordinates already (at least with
minimal effort).
The functionality of m.ll2u is duplicated by cs2cs from the PROJ.4 distribution so m.ll2u is not really needed any more. Probably a more typical application of r.proj is that you already know your region of interest in your target database (and have several maps there that you are working on) and you want to add another map you have obtained in a different
projection to your database. In this case the way r.proj works poses no
problem.
For converting a whole map to another projection gdalwarp from the GDAL distribution is probably a better option.
Paul K
On Fri, Sep 03, 2004 at 08:49:51PM +0100, Paul Kelly wrote:
On Fri, 3 Sep 2004, Ian MacMillan wrote:
>know what the corresponding UTM coordinates are? I can project it from
>some random place in the UTM location with -n, but it will only bring
>in data if I happened to overlap with the incoming raster. Do you see
>the dilemma? What I am looking for is a flag that sets the region to
>the incoming raster.
What about g.region -l which tells you the current boundaries
in LatLong (maybe we need to enhance that to use custom ellipsoid).
Maybe also helpful:
- Zoom the region of interest
- run v.in.region which creates a box of the current region
- reproject this box as indicator of the region of interest
Best
Markus
Markus, thanks for the v.in.region idea. Haven't had a chance to try it yet
(hadn't even heard of it before), but it seems like it would work.
Thanks to all who replied,
-Ian
Quoting Markus Neteler <neteler@itc.it>:
On Fri, Sep 03, 2004 at 08:49:51PM +0100, Paul Kelly wrote:
> On Fri, 3 Sep 2004, Ian MacMillan wrote:
>
> >know what the corresponding UTM coordinates are? I can project it from
> >some random place in the UTM location with -n, but it will only bring
> >in data if I happened to overlap with the incoming raster. Do you see
> >the dilemma? What I am looking for is a flag that sets the region to
> >the incoming raster.
What about g.region -l which tells you the current boundaries
in LatLong (maybe we need to enhance that to use custom ellipsoid).
Maybe also helpful:
- Zoom the region of interest
- run v.in.region which creates a box of the current region
- reproject this box as indicator of the region of interest
Best
Markus
-----------------------------------------------------
Ian MacMillan
Geological Sciences-UCSB
"insert witticism here"