[GRASSLIST:5331] Re: Core dump on Winkle Triple projection

[Glynn Clements]

cheg01 at attbi.com wrote:

> > cheg01 at attbi.com wrote:
> >
> > > When projecting lat/lon elevation data to Winkle Triple I get an instant
> > > core dump. Is this projection routine known to work?
> >
> > The Winkel Tripel projection doesn't have a defined inverse
> > projection, so you can't use it with r.proj. Instead, you would have
> > to convert the data to a sites map, project that with s.proj, then
> > convert it back to a raster with s.surf.rst.
> 
> The process is failing on the froward projection, from Lat/Lon to Winkel
> Triple.

Note that r.proj works "in reverse". IOW, for each cell in the
destination location, it transforms the coordinates of the cell's
centre using the *inverse* projection, to get a coordinate in the
source location. It then reads the value of the cell at that
coordinate from the source raster, and stores the value in the
original cell in the destination location.

> It should be averaging the coordinates from the "eqc" Cylindrical
> Equal Area (Plate Carree) and the Aitoff projections. I tested the input
> files on the Robinson projection and they worked fine. The eqc projection
> by itself  works but the Aitoff projection is failing.

"eqc" has a defined inverse; "aitoff" doesn't.

> gdb seems to show
> garbage in the arguments to G_remove. I am running Grass 5.0.0pre3. Here is
> the gdb output:

My guess is that r.proj has already "crashed" before this point. With
5.0.0 on Linux, r.proj segfaults at address 0, which is what I expect
(although we should probably trap this and display an error message).

Ultimately, if you want to project into a location whose projection
doesn't have a defined inverse, you will have to convert to sites
project that (s.proj/v.proj use the forward projection), then convert
back to raster.

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