[GRASS-dev] problems with datum parameters tables
Hamish
hamish_b at yahoo.com
Sat Oct 17 01:55:36 EDT 2009
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
More information about the grass-dev
mailing list