[GRASS-dev] Re: winGRASS

[Glynn Clements]

Michael Barton wrote:

> Good luck on this part. Glynn made a very rational suggestion awhile back.
> Why not combine the various projection/ellipse file needed to create a new
> location into a single, easily parsable file, with PROJ4-type projection
> definitions. Then (with the planned update to g.proj) we could simply have a
> GUI that lists projection parameters to be selected and sends the PROJ
> string to g.proj.

Are you referring to the proj-*.table files I created for g.setproj?

Those should be relatively straightforward to use from within a GUI.
The relevant files (all installed into $GISBASE/etc) are:

1. proj-parms.table

One line for each known projection. A sample entry:

	AEA:LAT0=ask,23.0;LAT1=ask,29.5;LAT2=ask,45.5;LON0=ask,-96.0;X0=ask,0.0;Y0=ask,0.0

The first field is the projection name, as used by the old geo.h file. 
AFAICT, the corresponding +proj= parameter is identical except in
lower case.

The remainder of the line (after the colon) is a semicolon-separated
list of parameter definitions of the form parm=spec. The LHS is the
parameter name as used by geo.h; these don't necessarily match the
corresponding the proj parameter, but you can translate them using the
proj-desc.table file (see below).

The RHS has two parts, separated by a comma. The first part is either
"ask" or "noask", corresponding to whether or not g.setproj should
prompt the user for a value. The second part is either "nodfl" or a
default value. Note that the combination "noask,nodfl" never occurs;
if an option is marked as "noask", there will always be a default
value.

Ideally, this file should be extended to include a more verbose form
of the projection's name. This can probably be done fairly easily
using the output from "proj -lp". I'll look into this part.

2. proj-desc.table

One line for each known parameter (other than +proj=). A sample entry:

	LON0:lon:lon_0:Central Meridian

The first field is the parameter name as used by the old geo.h file,
and as used in proj-parms.table.

The second field is the type, and can be one of:

	bool int float lat lon zone

This determines the set of valid options for the parameter (the "zone"
type corresponds to the UTM zone).

The third field is the name of the corresponding proj parameter
(without the leading "+"), and is the key stored in the PROJ_INFO
file.

The fourth field is a textual description of the parameter.

3. proj-units.table

One line for each known distance unit. A sample entry:

	feet:foot:0.3048

The three fields are (in case it isn't obvious) the plural form of the
name, the singular form, and the size of the unit in metres.

I'm not sure how this is used by g.setproj, but it can't be that
critical because the code actually tries to load proj-unit.table
(missing "s"). I'll fix this.

proj-parms.table can be used to allow selecting a projection from a
list, while a combination of proj-parms.table and proj-desc.table
would support the creation of a customised dialogue for a given
projection.

However, note that g.setproj still has a fair number of special-case
hacks. Some of those are useful-but-not-essential (e.g. automatically
selecting the correct ellipsoid for certain projections), while others
are necessary (e.g. the zone= and south parameters for UTM need to go
into the WIND/DEFAULT_WIND files as well as the PROJ_INFO file).

> Now that I've done a search engine for EPSG, the same thing could be done
> for the other GRASS projection files. I'm not sure which of the many ascii
> projection/ellipse files are actually needed or how they should be combined,
> however.

ellipse.table and datum.table are obvious candidates.

-- 
Glynn Clements <glynn at gclements.plus.com>