[GRASS5] Solaris, GRASS 5.1, and Proj

Paul Kelly paul-grass at stjohnspoint.co.uk
Sun Sep 21 16:29:20 EDT 2003


On Mon, 15 Sep 2003, Paul Kelly wrote:

[...]
> 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.

I decided to go ahead and apply this patch to the 5.3 CVS. So now even if you
have a nadgrids line in your PROJ_INFO (i.e. most likely a NAD27 location,
e.g. spearfish), if you use the internal GRASS copy of PROJ you will be OK
and not affected by this bug (affects r.sun, new d.where etc. and other
programs that convert co-ordinates to lat/long).

This means you probably shouldn't use the --with-proj option with 5.3,
unless you really rely on some feature that is in the latest version of
remotesensing.org PROJ.4. The only such feature I can think of is the NTv2
gridshifting support so if you need it you can add the nadgrids: line to
the PROJ_INFO when you need to use [rsv].proj, and delete it when you need
to use the modules that do lat/long conversion.

I hope this is clear enough. It does seem to be a bit of a backward step
to go back to using the internal static library and it would be possible
to work around the PROJ bug by changing all the affected modules to use
the pj_latlong_from_proj() function; unfortunately I don't have time to do
that now.

Paul




More information about the grass-dev mailing list