[GRASS5] geo.h and geo_init.c
Eric G. Miller
egm2 at jps.net
Tue Aug 27 04:13:59 EDT 2002
I'm trying to clean up geo.h and geo_init.c and disentangle them from
g.setproj. At the moment, I'm converting the tables UNITS and DESC
into const structs and I'm scratching my head over a couple of things.
Some of the projection parameters defines have the same value as
others. Why?
LONLOW == OLATP
LON0 == LATHIGH
FLOLOW == THETA
AZIM == LONHIGH
INTLOW == Y0
ZONE == FLOHIGH
BOOLOW == SPATH
GUAM == INTHIGH
Then, when I get to the DESC table, there are several holes (that is,
no description):
DESC[2] == DESC[OLAT1]
DESC[4] == DESC[OLAT2]
DESC[11] == DESC[OLON1]
DESC[13] == DESC[OLON2]
DESC[19] == DESC[OALPHA]
DESC[35] == DESC[INTHIGH]
DESC[38] == DESC[NODEFS]
Are the #defines beginning with "O" supposed to mean "old" and therefore
unused? That doesn't seem 100% the case since OLONP and OLATP have
descriptions "Latitude/Longitude of New Pole [o_lat/lon_p]".
It'd be useful to have descriptions for what all of the #define factors
are used for (some are obvious, but others aren't).
I've added USfoot (USfeet), USinch (USinches), USyard (USyards), and
USmile (USmiles) to the UNITS table. I've noticed there are a few
places where code defines a different idea of unit conversion tables.
Those should be changed so we just have one table of linear conversions
to meters...
I intend to move all the globals in geo.h either to geo_init.c for
the tables, or to g.setproj for the others. Can anybody think
why I shouldn't remove the following from geo.h?
int ier, proj_index, zone, snum, spath;
double radius, kfact, mfact, msfact, nfact, qfact, wfact, unit_fact,
x_false, y_false, heigh, azim, tilt;
struct used_opt USED_in[NOPTIONS];
struct used_opt USED_out[NOPTIONS];
double LLSTUFF[NLLSTUFF];
double prompt_num_double(); ???
The remaining globals in "geo.h" will be extern'ed, const qualified
and defined in "geo_init.c".
extern const struct conv_fact UNITS[NUNITS];
extern const struct opt_req TABLE[NPROJES][NOPTIONS];
extern const char DESC[NOPTIONS][63];
--
Eric G. Miller <egm2 at jps.net>
More information about the grass-dev
mailing list