[GRASSLIST:4300] Re: request?

Paul Kelly paul-grass at stjohnspoint.co.uk
Fri Sep 3 15:49:51 EDT 2004


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




More information about the grass-user mailing list