[GRASS-dev] Need to update g.setproj

[Glynn Clements]

Paul Kelly wrote:

> > G.setproj is a critical GRASS module because it is the primary way to 
> > create new locations that GRASS must have to run.
> > 
> > However, because it requires an interactive x-terminal, g.setproj will 
> > not work with the native winGRASS. It will not work with a non-x11 aqua 
> > Mac GRASS. Nor will it work with the wxPython interface under development.
> > 
> > This was brought home in a recent GRASS workshop for graduate students 
> > here when no one using Windows could create a new location in the normal 
> > way. Using EPSG codes also currently bombs under winGRASS, presumably 
> > because somewhere it needs an xterm.
> 
> 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.

> A wider issue is the whole big ugly way g.setproj determines which 
> parameters each projection needs with the G_geo_* functions in libgis. 
> Very ugly, inflexible and actually doesn't handle things totally 
> correctly with projections that can have their parameters expressed in 
> more than one way (e.g. lcc). It's a long-term project to sort this one 
> out and there'd be no point in re-writing g.setproj without sorting that 
> out first. Hopefully a re-write of the PROJ.4 library in the long-term 
> might produce a function that could be called to list the parameters 
> required by each projection. That would be a major step forward.

That's a separate issue. For the time being, the ability to provide a
list of key/value pairs for projection-specific options will have to
suffice.

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.

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