[GRASS-dev] Need to update g.setproj

[Glynn Clements]

Paul Kelly wrote:

> >> Specifically, the GPJ_osr_to_grass() function called in g.proj needs
> >> some way of interacting with the user if (and only if) the datum isn't
> >> fully specified in the input co-ordinate system description (EPSG code,
> >> input georeferenced file or anywhere else. r.in.gdal and v.in.ogr have
> >> the same problem.) It achieves this by calling GPJ_ask_datum_params(),
> >> which prompts the user in the traditional GRASS way (Enter to cancel,
> >> "list" to list options etc.) There is no way to determine in advance
> >> (before running the module) what options might be needed here. What we
> >> really need is a library for interactive input from the user. E.g. a
> >> function to set the question, functions to prompt for a yes/no answer,
> >> or functions to list the possible answers and prompt to use one. A
> >> little bit similar to vasklib as it is currently, but nowhere near such
> >> a rigid structure.
> >
> > I disagree. All functionality should be available in a non-interactive
> > manner for cases where there isn't a user available.
> 
> Well GPJ_osr_to_grass() has an "interactive" flag, which if set to 0 will 
> use the "default" parameters for the datum conversion instead of 
> prompting. This mode is used when the output is non-vital, e.g. r.in.gdal 
> compares the projection of an input map with the current location to check 
> they match. But there really is no such thing as default datum 
> transformation parameters and in the case of setting up a new location, 
> it's likely to lead to bad data IMHO if the user knows no better and 
> assumes GRASS has set up everything for them perfectly. So for the case of 
> g.proj, it calls GPJ_osr_to_grass() with the interactive flag set, to 
> force interactive prompting and force the user to make a decision on which 
> are the best datum parameters to use for their area.
> 
> Are you suggesting this prompting be the responsibility of the GUI before 
> it runs the module? Would it not then need to be cloned for every 
> different GUI? And make prior knowledge of all the parameters for the 
> datum etc. a pre-requisite for using the module from the command-line?

I'm proposing that GRASS should be scriptable using something other
than "expect", for the case where a user simply isn't available, e.g. 
CGI scripts or cron jobs.

IOW, I'm arguing about the fundamental concept of "interacting" with a
user, not with the mechanism.

In that situation, we need something that accepts all necessary
parameters from the command line (and/or files, environment variables
etc), and either succeeds or fails.

> A flag could be added to g.proj/g.setproj to call GPJ_osr_to_grass() in 
> non-interactive mode, but that really would just be ignoring the problem I 
> feel.

The non-interactive case needs to fail if a required parameter wasn't
specified, not use a default which is unlikely to be correct.

> > For the time being, the ability to provide a
> > list of key/value pairs for projection-specific options will have to
> > suffice.
> 
> Well you can more or less do that already, if you pass the parameters to 
> g.proj as a PROJ.4-style string. If the datum parameters are fully 
> specified it will not prompt for them.

I'm talking about g.setproj rather than g.proj. But as for g.proj, it
should fail rather than attempt to interact with the user if relevant
parameters are omitted.

In general, assuming that a user is present is a bug which needs to be
fixed.

> > In the longer term, the lack of metadata within PROJ itself is a
> > long-standing problem which doesn't look like it's going to get fixed
> > any time soon. In that situation, the only option is to maintain our
> > own database of projections which includes the required and accepted
> > options for each projection.
> 
> Well personally, if I had any time to spend on such an effort (currently 
> unlikely) I would be more likely to offer it as a contribution to the PROJ 
> distribution than to try and improve the GRASS implementation (in the 
> hope of course that the GRASS implementation could be replaced by the PROJ 
> one): both because I feel the current GRASS implementation is a mess not 
> worth improving, and because I know from previous discussions on the PROJ 
> list that there is a demand for such a thing.

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".

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