Azimuthal, conical projections and d.rast, r.proj

[Morten Hulden]

Hello List

I recently added some code to GRASS' g.setproj to get support for Lambert
Azimuthal Equal Area projection. 
(http://earth.uni-muenster.de/~eicksch/GRASS-Help/msg02001.html)

After trying out imports to the new projection I have noticed following
problem with the r.proj and d.rast modules: The modules refuse to
convert/display data in areas where south is above north or east is to the
left of west. This is not a problem for the corresponding
conversion/display of vector data with v.proj/d.vect. 

As an example, take a LAEA projection of the Eurasian continent with the
standard parallel and longtude axis put over Europe. (lon_0=20, lat_0=55
in my case). The Eurasian continent then forms a kidney bean shaped block
with Europe standing straight up in the lower part, and Kamchatka and East
Siberia almost upside down in the upper part. This beautiful and very
useful projection is used in the land coverage maps from the usgs.gov
sites.

The r.proj and d.rast modules makes the (false?) assumption that north
must always be on top of south and east must always be to the right of
west, even in non-ll projections. In the example above, going eastward
over the continent a point is eventually reached (somewhere in middle
Asia), where north is pointing straight to the left and east is pointing
straight upwards. From that point onwards to the east r.proj will fail,
and d.rast will not accept maps in this region. Cellhd for such maps would
have values (in meter units) where N<S and E<W, which will trigger an
error message. 

The PROJ4 program, which r.proj also uses for the conversion, does the
calculation from degrees to Cartesian coordinates correctly when used
externally. Is it an oversight that the N>S, E>W assumption is activ in
these modules, when the projection is not ll and proj_unit is meters, not
degrees? It does not make sense for azimuthal projections. I have not
tried the Lambert Conformal Conic (lcc), one of the default projections in
GRASS, but I guess a similar situation may arise here when the location
covers an area which extends far enough in the east-west direction, and
the central longitude is put near either end.

The fact that the modules v.proj (which also relies on PROJ4 code) and
d.vect work suggests to me that relatively small changes in the source
code for the corresponding raster modules could solve the problem. I do
not have time, nor skill, to look closer at this. I can just hope someone
will take in on from here.

By the way, I'm using GRASS5.0beta compiled on Linux2.2.x Intel686, at
home and work. Great program!

Morten Hulden