[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