[GRASS5] Solaris, GRASS 5.1, and Proj

[Paul Kelly]

On Mon, 15 Sep 2003, Hamish wrote:

> > > But ./configure should stop with an error when
> > > --without_proj
> > > is used. Then the situation were clear.
> >
> > I have fixed this now---moved the PROJ test earlier in the sequence
> > and disabled --with-proj / --without-proj (the test is mandatory).
> > --with-proj-includes and --with-proj-libs still work if required.
>
>
> Should this be done for GRASS 5.3 as well?
> or not?
>

No, not until Frank has decided on the future direction of PROJ
development which seems to be a bit up in the air at the minute what with
Gerald's new competing version etc. GRASS needs to use 'Frank's' version
for datum support.

Main reason for not wanting to rely totally on it is a bug
http://bugzilla.remotesensing.org/show_bug.cgi?id=368
that causes the wrong results to be given in the modules that use PROJ to
convert to/from lat/long co-ordinates on the same ellipsoid (r.sun etc.)
*iff* the PROJ_INFO file contains a 'nadgrids' line (sorry, just thinking
I should probably have mentioned this earlier. Hope it hasn't caused you
any trouble). The above bugzilla report contains a patch I submitted but
hasn't been accepted yet. We could apply it to the internal GRASS copy of
PROJ but then if Frank decides to do something different later it would
get inconsistent. And also the internal GRASS proj is only 4.4.5 with a
few bugfixes so e.g. you couldn't do NTv2 gridshifts with it unless
somebody wants to work out which files should be updated and do the work?

The bug is only because of the way we specify the lat/long 'co-ordinate
system' inside those modules like r.sun, which simply gets the ellipsoid
parameters from the current location and passes them on. If we used the
internal PROJ function pj_latlong_from_proj() (which I wasn't aware of
until recently) that would work around the PROJ bug (it makes sure the
datum information is exactly the same, which IMHO should be unnecessary as
if the elllipsoids are the same the datum shift info should be ignored). I
have implemented a wrapper for this in 5.7, called
GPJ_get_equivalent_latlong() which we can use to work around the bug. The
new ps.map contains somewhere it can be implemented already (but I
haven't changed it yet)

I have put some Doxygen-style comments and descriptions for the new 5.7
proj library functions in the files, however I'm not sure how to make the
appear in the programmer's manual.

Sorry this is a bit long but there are a few issues to be addressed about
relying on an external PROJ (not just those discussed here---how to bundle
the PROJ library with binary releases is another one). Hope it makes it a
little clearer.

Paul