projections and raster maps

[Gerald I. Evenden]

>From: "Michael Hill" <mhill at chiswick.anprod.csiro.au>
>Date: Sat, 28 Aug 93 16:32:32 EST
>Reply-To: grassu-list at max.cecer.army.mil
>Subject: Re: projections and raster maps
>
>On Fri, 27 Aug 93 15:59:06 EST, Simon Cox wrote:
>
>>
>>What is the best way to change the projection of a raster layer (eg ll to
>>utm).
>>I know that it can be done using the imagery functions, i.rectify, etc,
>>with judicious intervention of m.ll2u, etc, on the POINTS file,
>>but this seems like a crude instrument considering the equations are known!
>>>From my brief scan of the manuals there is an [a-z].proj for everything except
>>r ...
>>
>>Suggestions anyone?
>>
>>Thanks
>>
>>Simon Cox
>
>I second this point from Simon. Why is there no r.proj. v.proj works 
>nicely thankyou. But in a raster based GIS, surely r.proj is more 
>important - perhaps it is more difficult.
>
>Dragging cell data out to ascii files and running PROJ.4 over them to go 
>from geog. to say, lcc, is a hell of a business. At present, it is easier 
>to import grass rasters into ArcInfo (which we fortunately have), 
>reproject, and take them back to grass. But that is also something of a 
>convoluted business. Likewise using an imagery rectification is not 
>something you want to do with hundreds of large rasters, which we and many 
>others have.
>
>I don't normally whinge like this - must be a bad mood, or Simon hitting a 
>raw nerve!
>
>Michael J Hill

Since PROJ.4 is getting mentioned here I would like to make some comments
Because I am not familiar with details of the GRASS software I may make
an erroneous and perhaps dumb statement.

The basic problem seems to be a matter of conversion of pixel data
arranged on a regularl and evenly spaced grid in one cartesian system
to a similar grid in another.  Because the pixel grid of the original
cartesian system is not likely to linearly overlay the new system's
grid, a complex interpolation of new pixel values is required.

The term "complex" mainly refers to the mathematics of the projection
process associated with each pixel grid system, but it may also refer
to the method used to interpolate the new pixel value.  Barring a
complex interpolation, the process is trivial when performed within a
single binary process (as opposed to linking several executables
together with pipes, etc.---proj among them).  Thus I do not understand
why this process does not exist within the GRASS environ; but perhaps
it does and we have not heard from those who know.

One reason for the release of PROJ.4 was the improved interface of the
internals of the system to ease usage of projections within new
application software without having to pipe information through program
proj.  Among other elements included were bivariate approximation
procedures which could greatly speed up aforementioned
transformations.

If such a program does not exist, it certainly should.

Gerald (Jerry) I. Evenden   Internet: gie at charon.er.usgs.gov
voice: (508)563-6766          Postal: P.O. Box 1027
  fax: (508)457-2310                  N.Falmouth, MA 02556-1027