[GRASS-dev] Need to update g.setproj

[Glynn Clements]

Glynn Clements wrote:

> > > Is there any real reason why GRASS needs to comprehend the projection
> > > parameters, i.e. to have lib/gis/geo_init.c or all of that boilerplate
> > > in g.setproj?
> > > 
> > > IOW, can projection parameters not be treated as opaque key/value
> > > pairs which are simply passed straight through to PROJ, with any UI
> > > consisting of generic code using an external database[1] of projection
> > > parameters?
> > > 
> > > [1] By which, I mean a text file in an easy-to-parse format.
> > > 
> > > It seems to me that all of that boilerplate could be replaced by a
> > > list of projections (+proj= name, description), a database of
> > > parameters (+<opt>= name, description, bool/int/float), and a matrix
> > > of "projection X accepts/requires parameter Y with default value Z".
> > 
> > This seems like it would be a big help in designing a GUI wrapper for these
> > functions.
> 
> Converting lib/gis/geo_init.c and g.setproj/main.c to text files was
> simple enough; those are attached.
> 
> AFAICT, it should be straightforward to replace the boilerplate in
> g.setproj with code which uses the tables.

I've modified g.setproj to use text files rather than hardcoded
settings. lib/gis/geo_init.c and include/geo.h have been removed, as
g.setproj no longer uses them (and nothing else used them).

This shouldn't noticably change the behaviour of g.setproj; it is
still interactive. However, any future modifications should be more
straightforward.

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