[OSRS-PROJ] Weirdnesses in the source code

Paul Kelly paul-grass at stjohnspoint.co.uk
Sat Jul 19 13:00:20 EDT 2003

On Tue, 8 Jul 2003, Gerald I. Evenden wrote:

> Thank-you for all the bug reports.  Imbedded are some comments prior
> to looking in to them in detail:
> On Tue, 2003-07-08 at 11:23, proj at ton.iguana.be wrote:
> > Hi,
> >
> > I'm busy transforming some of the proj code to perl, and ran into a
> > number of strange things.
> On the HEAD stuff, the second quote set is informational and does
> not affect execution, but they will be fixed.
> > PJ_aeqd.c
> >   in PROJ_HEAD, lat_0 should be lat_0=
> >
> > PJ_aitoff.c
> >   in PROJ_HEAD, lat_1 should be lat_1=

This is interesting to me as a while ago I was wondering if it was possible
to use the information in the 'second quote set' for each projection (i.e.
the output of the 'proj -lP' command) to automatically generate a list of
which parameters were required for each projection.

The motivation for this was that I was doing some work on tidying up the
way proj is used in the GRASS GIS.

Previously GRASS had its own private copy of proj4.3.3 inside the
source tree but we are now swiching over to using an external shared
library version of Frank's/remotesensing.org PROJ.4 library and would like
to abandon the internal proj code in GRASS.

The only part I am finding it difficult to deal with is the part that has
been added to GRASS that associates a list of parameters with each
projection. This is needed to allow the user to easily interactively
define all the projection parameters for the location they are working in.
The GRASS module g.setproj asks for the projection name and then
interactively prompts for each parameter, suggesting default values where
appropriate (though we could always get rid of that part; most of them are
zero anyway).

As far as I can see (though I haven't done a totally exhaustive search)
there does not seem to be anything like this internal
to libproj, except the information meant for human interpretation that Ton
is trying to parse.

I would be very interested to see this parsing code, and perhaps a C
version could be added to PROJ as a function in the future?

Paul Kelly

PROJ.4 Discussion List
See http://www.remotesensing.org/proj for subscription, unsubscription
and other information.

More information about the Proj mailing list