[GRASS-dev] Need to update g.setproj

Michael Barton michael.barton at asu.edu
Fri Sep 29 14:10:57 EDT 2006


This seems like it would be a big help in designing a GUI wrapper for these
functions.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics and 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: Fri, 29 Sep 2006 18:36:58 +0100
> To: Paul Kelly <paul-grass at stjohnspoint.co.uk>
> Cc: Michael Barton <michael.barton at asu.edu>, GRASS-DEV
> <grass-dev at grass.itc.it>
> Subject: Re: [GRASS-dev] Need to update g.setproj
> 
> 
> 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".
> 




More information about the grass-dev mailing list