[GRASS5] problems with [rsv].proj

[Glynn Clements]

Morten Hulden wrote:

> > When computing the region of interest, cells which fail to project
> > should just be ignored. When performing the actual projection, cells
> > which fail to project should be NULL.
> 
> Should be fairly easy to fix: Find the places in the code where 
> [src].proj exits with 'Error in do_proj' and change action according to 
> above.
> 
> (I don't have a GRASS installation to work with right now, but maybe 
> someone else is willing to take on this task)

OK.

> > Also, I've remembered another issue with r.proj:
> > 
> > When projecting lat/lon to pseudo-cylindrical projections where the
> > entire globe fits within the region, the resulting map tends to
> > "wrap"; i.e. the area outside of the "ellipse" contains non-null
> > cells.
> 
> Can you confirm this happens with recent versions of proj 
> (post-December-2001).

This is with the current GRASS CVS head.

> The way r.proj works (omitting here the initial testing/trimming 
> done in bordwalk.c) is:
> 
> For each cell in the destination region
> 	-project the cell center into source map 
> 	-find the category value of the nearest cell 
> 		(alternatively using cubic etc interpolation)
> 	-assign that value to the cell in the destination region
> 
> For a pseudo-cylindrical destination there will a number of cells outside 
> the ellipse that should become NULL. (The real 'borders' in this case is 
> actually the ellipse, not the window borders given in DEFAULT_WIND). 
> Projecting a co-ordinate outside the ellipse should result in proj 
> returning * (inf?) for either lon or lat or both.

That clearly isn't the case. If it were, the cells outside of the
ellipse would be garbage, but they are actually "repeats" of the data
inside the ellipse (albeit more distorted), which seems to suggest
periodicity.

In this test case (Wagner I), the repeat happens in both latitude and
longitude, but the latitudinal repeat is a mirror image in both
directions (i.e. 180° rotation).

Anyway, I'll look into it further.

-- 
Glynn Clements <glynn.clements at virgin.net>