[GRASS5] datum transforms...

[Eric G. Miller]

On Mon, Jan 13, 2003 at 12:16:28PM +0000, Paul Kelly wrote:

> I suggest calling the first function pj_to_proj (i.e. a direct replacement
> for the current pj_do_proj) as it takes the same parameters, the only
> difference being that it internally uses pj_transform to take advantage of
> datum conversion. And the new function could be called pj_do_transform and
> put into do_proj.c as well for future use and as a starting point for
> people working on this in the future.

Sounds like a fine suggestion.

> ...
> >    if (strncmp(info_in->proj,"ll",2) == 0 ) {
> >       if (strncmp(info_out->proj,"ll",2) == 0 )
> > 	ok = pj_transform (info_in->pj, info_out->pj, count, 0, x, y, h);
> >       else  {
> > 	DIVIDE_LOOP(x,y,count,RAD_TO_DEG);
> > 	ok = pj_transform(info_in->pj,info_out->pj, count, 0, x, y, h);
> > 	DIVIDE_LOOP(x,y,count,METERS_out);
> >       }
> 
> Should these calls to pj_transform not have 1 for the parameter after
> count, so it will step through the array one double at a time? With 0 I

Hmm, I thought it was offsets into the arrays.  You could be right....

> There is a leading slash in GRIDDIR anyway so maybe it is not needed
> between the two %s , but I could be wrong as I don't know what format
> G_gisbase() returns.

A braino on my part...

> Yes, the change from setenv() to putenv() made this compile OK for me. But
> I still don't really like this way of setting the directory proj should
> look in for the conversion tables. Is setting environment variables not a
> big overhead? And should it be done inside the pj_do_proj() function every
> time it is called or just done once in the user programs [rsv].proj? I
> would prefer not to have to change them at all as all the datum
> transformation can be done seamlessly within the proj library without
> changing the function called from the user programs.

Well, I was calling it at the beginning of the s.proj.  I don't know
that modifying the environment is that much overhead.  Anyway, I think
we wanted to get away from modifying the library code so we could just
use libproj as distributed rather than maintaining a modified copy (more
work).

> Looking at the function pj_load_nadgrids in pj_apply_gridshift.c though,
> I'm still not too sure that we couldn't just include the full pathnames in
> the nadgrids line in pj_datums.c . Does anybody who knows about the NAD
> gridshifting care to test it a bit?

How you going to hardcode the name when you don't know the final install
directory?  I don't like hardcoded paths.

-- 
echo ">gra.fcw at 2ztr< eryyvZ .T pveR" | rot13 | reverse