[GRASS-dev] problems with datum parameters tables

[Hamish]

Glynn:
> > there are many places where PROJECTION_UTM causes
> > cellhd.zone to become relevant.

ah, right (eg r.info). so UTM must be a special case.
 (at least for gr6)

Michael:
> I don't know how this works in the underlying C code,

include/gis.h defines five fundamental projection types:

#define PROJECTION_XY  0
#define PROJECTION_UTM 1
#define PROJECTION_SP  2
#define PROJECTION_LL  3
#define PROJECTION_OTHER  99

(these can be seen in the top line of `g.region -p`)

C programs are written to behave in different ways depending on
which class of projection it is.


> this all can be handled in a single method that parses
> proj-parms.table except for State Plane. I can see why you
> call latlon a pseudo projection, but not UTM. AFAICT, it is
> a legitimate projection like the others.

Like state plane, UTM is a collection of (for want of a better
term) epsg codes. The State Plane or UTM code/zone says which
epsg-like set of parameters to use/expand.

A pure projection is a mathematical formula specifying how
geographic space bends. SP and UTM are a table of contents for
which EPSG code to use.



hope that's clearer,
Hamish