[GRASS-dev] Need to update g.setproj

[Michael Barton]

Thanks very much for getting this important update started.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton



> From: Glynn Clements <glynn at gclements.plus.com>
> Date: Sun, 1 Oct 2006 22:21:08 +0100
> To: Michael Barton <michael.barton at asu.edu>, Paul Kelly
> <paul-grass at stjohnspoint.co.uk>, GRASS-DEV <grass-dev at grass.itc.it>
> Subject: Re: [GRASS-dev] Need to update g.setproj
> 
> 
> 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>