[GRASS-dev] Need to update g.setproj

GRASS GIS GRASS GIS developer
1

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.

So we REALLY need a non-interactive version of g.setproj. You should be able to put in the same parameters that you do in the interactive version: datum, datum transform option (if any), extents, and resolution. This should be pretty easy to do (I say as a someone who doesn’t know C). Because the datum and datum transform come from text files in $GISBASE/etc, it should be pretty easy to make a GUI scrollable list from these files. The extents and resolution are typed in by the user.

Is there anyone who can make g.setproj accessible as a command-line module without needing an interactive xterm? I can make up a quick TclTk GUI to go with it.

Thanks
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

2

Hello Michael
Michael Barton 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.

The actual interaction with the user should be abstracted behind the library functions and not of concern to the developer of the module. My thinking is if the user is running a text-based session (i.e. GRASS_UI_TERM variable set) they would be prompted in the traditional way (Enter list to list choices etc.) or if they're using a Tcl/Tk based GUI then a Tcl/Tk dialog window would pop up with a drop down list of choices, check boxes/ radio buttons or whatever is appropriate. If the GUI used had a C API this mightn't be a *huge* task actually. I have a tiny little bit of experience with Gtk and it looked fairly easy to construct a dialog window with those sorts of options. Although I don't have a clue how you'd do it with Tcl/Tk. Perhaps the window that pops up when you start a command from the GUI, showing all the parser options, is a clue though.

So we REALLY need a non-interactive version of g.setproj. You should be able to put in the same parameters that you do in the interactive version: datum, datum transform option (if any), extents, and resolution. This should be pretty easy to do (I say as a someone who doesn’t know C). Because the datum and datum transform come from text files in $GISBASE/etc, it should be pretty easy to make a GUI scrollable list from these files. The extents and resolution are typed in by the user.

Is there anyone who can make g.setproj accessible as a command-line module without needing an interactive xterm? I can make up a quick TclTk GUI to go with it.

What you describe above will require some interaction anyway, because later prompts tend to be based on earlier choices. I don't agree that a non-interactive g.setproj is the solution - as said above my preferred option is to make a way of having interactive modules be compatible with the GUI. I think this could benefit other modules too. E.g. I really miss interactive mode in g.region. It's nice to just fire up a module and enter the choices it prompts you for rather than having to work everything out in advance, run the module and hope for the best!

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.

Paul

3

Paul,

Thanks for the detailed reply. The larger problem is that Windows and Mac
'native' (i.e., aqua) platforms don't use an xterm. So I don't see how we
can require interactive xterm use. It can be an optional way to run the
module if you are using a terminal, but we also need to be able to achieve
the same function without this.

What I suggest is simply that the module fail with a meaningful error
message (e.g. "You must enter a datum transformation for this projection")
if the proper combination of parameters are not set in the end. It is fairly
straightforward to do the interactive part in a GUI platform like TclTk or
wxPython. Users would be prompted for different options depending on which
other options they chose. That is, different options would be presented for
wgs84 UTM than for NAD83.

To do this, however, it must be completely runable from the command line,
with no interaction required. This takes considerable burden of the
underlying C module. Don't worry about dropping the xterm interaction that
is already there. People can continue to use it if desired. We just need an
alternative mode that does not require it. The latter could be turned on and
off by a flag, for example.

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: Paul Kelly <paul-grass@stjohnspoint.co.uk>
Date: Thu, 28 Sep 2006 08:53:09 +0100
To: Michael Barton <michael.barton@asu.edu>
Cc: GRASS-DEV <grass-dev@grass.itc.it>
Subject: Re: [GRASS-dev] Need to update g.setproj

Hello Michael
Michael Barton 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.

The actual interaction with the user should be abstracted behind the
library functions and not of concern to the developer of the module. My
thinking is if the user is running a text-based session (i.e.
GRASS_UI_TERM variable set) they would be prompted in the traditional
way (Enter list to list choices etc.) or if they're using a Tcl/Tk based
GUI then a Tcl/Tk dialog window would pop up with a drop down list of
choices, check boxes/ radio buttons or whatever is appropriate. If the
GUI used had a C API this mightn't be a *huge* task actually. I have a
tiny little bit of experience with Gtk and it looked fairly easy to
construct a dialog window with those sorts of options. Although I don't
have a clue how you'd do it with Tcl/Tk. Perhaps the window that pops up
when you start a command from the GUI, showing all the parser options,
is a clue though.

So we REALLY need a non-interactive version of g.setproj. You should be
able to put in the same parameters that you do in the interactive
version: datum, datum transform option (if any), extents, and
resolution. This should be pretty easy to do (I say as a someone who
doesn¹t know C). Because the datum and datum transform come from text
files in $GISBASE/etc, it should be pretty easy to make a GUI scrollable
list from these files. The extents and resolution are typed in by the user.

Is there anyone who can make g.setproj accessible as a command-line
module without needing an interactive xterm? I can make up a quick TclTk
GUI to go with it.

What you describe above will require some interaction anyway, because
later prompts tend to be based on earlier choices. I don't agree that a
non-interactive g.setproj is the solution - as said above my preferred
option is to make a way of having interactive modules be compatible with
the GUI. I think this could benefit other modules too. E.g. I really
miss interactive mode in g.region. It's nice to just fire up a module
and enter the choices it prompts you for rather than having to work
everything out in advance, run the module and hope for the best!

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.

Paul

4

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@gclements.plus.com>

5

Hello Michael and Glynn
Glad to see this has finally become a show-stopping bug to force some discussion of it :wink:

Michael Barton wrote:

Paul,

Thanks for the detailed reply. The larger problem is that Windows and Mac
'native' (i.e., aqua) platforms don't use an xterm. So I don't see how we
can require interactive xterm use. It can be an optional way to run the
module if you are using a terminal, but we also need to be able to achieve
the same function without this.

Well yes what I was proposing was that interactive use need not require an interactive terminal window, if we create some functions that abstract the interactive prompting from the module so it doesn't care whether it is being run from the command-line user interface or a graphical user interface; all it does is let the user know what options are available and receive the user's response.

What I suggest is simply that the module fail with a meaningful error
message (e.g. "You must enter a datum transformation for this projection")
if the proper combination of parameters are not set in the end. It is fairly
straightforward to do the interactive part in a GUI platform like TclTk or
wxPython. Users would be prompted for different options depending on which
other options they chose. That is, different options would be presented for
wgs84 UTM than for NAD83.

That just doesn't seem elegant to me. E.g. suppose somebody wanted to write a different GUI to call g.proj (there are several GRASS GUIs about) then all this interactive prompting functionality would have to be re-implemented in that GUI too. E.g. in GRASS already g.proj is called both from the start-up screen and gis.m I guess.

To do this, however, it must be completely runable from the command line,
with no interaction required. This takes considerable burden of the
underlying C module. Don't worry about dropping the xterm interaction that
is already there. People can continue to use it if desired. We just need an
alternative mode that does not require it. The latter could be turned on and
off by a flag, for example.

But the interactive prompting and converting of user input forms the vast bulk of what g.setproj does. Really what you are proposing is duplicating this functionality in a new Tcl/Tk module. I just thought it would be nice (to avoid code repetition, easy to fix bugs etc.) if the command-line interactive and GUI interactive versions of a module could be combined in one place using (as yet non-existent) interactive input functions abstracted from the user interface.

On Thu, 28 Sep 2006, Glynn Clements wrote:

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?

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.

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.

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.

Paul

6

Paul,

Thanks for the informative comments. I have a couple of contributions below.

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

Well yes what I was proposing was that interactive use need not require an
interactive terminal window, if we create some functions that abstract the
interactive prompting from the module so it doesn't care whether it is
being run from the command-line user interface or a graphical user
interface; all it does is let the user know what options are available and
receive the user's response.

From my admittedly limited experience with GUI development (TclTk and

wxPython), a module that insists on sending a message and expecting a user
response--by whatever means--is very problematic to use in a GUI. The GUI is
designed to handle all user interaction. Having the module "intrude" in this
way is either hard to program around or makes it unusable.

What I suggest is simply that the module fail with a meaningful error
message (e.g. "You must enter a datum transformation for this projection")
if the proper combination of parameters are not set in the end. It is fairly
straightforward to do the interactive part in a GUI platform like TclTk or
wxPython. Users would be prompted for different options depending on which
other options they chose. That is, different options would be presented for
wgs84 UTM than for NAD83.

That just doesn't seem elegant to me. E.g. suppose somebody wanted to
write a different GUI to call g.proj (there are several GRASS GUIs about)
then all this interactive prompting functionality would have to be
re-implemented in that GUI too. E.g. in GRASS already g.proj is called
both from the start-up screen and gis.m I guess.

Yes, each GUI needs to use its own widgets and functions. But requiring user
interaction at the module level does not make this any easier. On the
contrary, if it is a straightforward command with option=value pairs, it
will be easier to drop into a different GUI platform than if you have to
also come up with a way to receive and parse input from the module. Also,
current GUI's tend not to follow the prompt and respond model.

To do this, however, it must be completely runable from the command line,
with no interaction required. This takes considerable burden of the
underlying C module. Don't worry about dropping the xterm interaction that
is already there. People can continue to use it if desired. We just need an
alternative mode that does not require it. The latter could be turned on and
off by a flag, for example.

But the interactive prompting and converting of user input forms the vast
bulk of what g.setproj does.

This is why I'm hoping a non-interactive behavior is pretty easy to
implement.

Really what you are proposing is duplicating
this functionality in a new Tcl/Tk module.

Exactly

I just thought it would be nice
(to avoid code repetition, easy to fix bugs etc.) if the command-line
interactive and GUI interactive versions of a module could be combined in
one place using (as yet non-existent) interactive input functions
abstracted from the user interface.

It would be nice in theory, but doesn't work this way, at least with the
platforms that we're using for GRASS and that I'm familiar with.

Michael

7

Michael:

> Thanks for the detailed reply. The larger problem is that Windows
> and Mac 'native' (i.e., aqua) platforms don't use an xterm. So I
> don't see how we can require interactive xterm use. It can be an
> optional way to run the module if you are using a terminal, but we
> also need to be able to achieve the same function without this.

Paul:

Well yes what I was proposing was that interactive use need not
require an interactive terminal window, if we create some functions
that abstract the interactive prompting from the module so it doesn't
care whether it is being run from the command-line user interface or
a graphical user interface; all it does is let the user know what
options are available and receive the user's response.

the QGIS 0.8 GUI projection setup wizard may provide a model here...

Hamish

8

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@gclements.plus.com>

9

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@gclements.plus.com>
Date: Fri, 29 Sep 2006 18:36:58 +0100
To: Paul Kelly <paul-grass@stjohnspoint.co.uk>
Cc: Michael Barton <michael.barton@asu.edu>, GRASS-DEV
<grass-dev@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".

10

Michael Barton 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.

In the process, I noticed this in g.setproj/main.c:

  case LAT3:
    sprintf(tmp_buff, "%.10f", LLSTUFF[i]);
    G_set_key_value("lat_2", tmp_buff, out_proj_keys);
                     ^^^^^

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

(attachments)

desc.txt (1.13 KB)
proj3.txt (5.51 KB)

11

> 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?

Glynn:

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.

what if g.setproj could take a text file as input. This text file would
be identical in format to PROJ_INFO and all the module would do would be
to test that all values are legal and that nothing manditory (e.g.
proj:) was missing, then populate the dir structure. UNITS and
DEFAULT_WIND could default to meters/degrees and [0,1][0,1][1].
(sort of like new region from r.in.gdal WKT or EPSG code works now?)

Slighly more intelligent than just "mkdir PERMANENT && cp input.tmp
PERMANENT/PROJ_INFO", but nothing too fancy.

Then it's up to the GUI wizard to create pull-down menus for available
options... this of course would need proj.4 or GRASS to provide such
info for parsing (like "gdalinfo --formats"); but to me this is the
primary approach that could make Michael, Glynn, Paul, Frank, etc all
happy, so could be worth the trouble to add to proj4?

Hamish

12

Either this or Hamish's suggestion would work from my vantage--whichever is
easier to do with the g.setproj code.

There would need to be some tables with user-readable names from which to
parse correct values. But, as you show below, that should be quite doable.

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@gclements.plus.com>
Date: Sun, 1 Oct 2006 03:56:59 +0100
To: Michael Barton <michael.barton@asu.edu>
Cc: Paul Kelly <paul-grass@stjohnspoint.co.uk>, GRASS-DEV
<grass-dev@grass.itc.it>
Subject: Re: [GRASS-dev] Need to update g.setproj

Michael Barton 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.

In the process, I noticed this in g.setproj/main.c:

case LAT3:
sprintf(tmp_buff, "%.10f", LLSTUFF[i]);
G_set_key_value("lat_2", tmp_buff, out_proj_keys);
                ^^^^^

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

ALPHA:alpha:Azimuth angle at Cartesian Origin
AZIM:azi:Azimuth Angle of Tilt in Decimal degrees
HEIGH:h:Height of Viewing Point in Meters
KFACT:k_0:Scale Factor at the Central Meridian
LAT0:lat_0:Central Parallel
LAT1:lat_1:First Standard Parallel
LAT2:lat_2:Second Standard Parallel
LAT3:lat_3:Third Standard Parallel
LATB:lat_b:Angular Distance from Tangency Point
LATTS:lat_ts:Latitude of True Scale
LON0:lon_0:Central Meridian
LON1:lon_1:First Standard Meridian
LON2:lon_2:Second Standard Meridian
LON3:lon_3:Third Standard Meridian
LONC:lon_c:Longitude of Cartesian Origin
LOTSA:lotsa:LOTSA
MFACT:m:m factor
MSFACT:M:M factor
NFACT:n:n factor
NOCUT:no_cut:Both Hemispheres
NOROT:no_rot:Suppress Rotation
NOSKEW:ns:Suppress Skew
NOUOFF:no_uoff:Suppress Offset from Pre-Rotated Axis
OLATP:o_lat_p:Latitude of New Pole
OLONP:o_lon_p:Longitude of New Pole
QFACT:q:q factor
ROTCONV:rot_conv:Origin Convergence Angle
SNUM:lsat:Satellite Number
SOUTH:south:South Hemisphere
SPATH:path:Satellite Path Number
THETA:theta:Theta Angle
TILT:tilt:Tilt Angle in Decimal Degrees
WFACT:W:W factor
X0:x_0:False Easting
Y0:y_0:False Northing
ZONE:zone:Projection Zone
AEA:lat_0=ask,23.0;lat_1=ask,29.5;lat_2=ask,45.5;lon_0=ask,-96.0;x_0=ask,0.0;y
_0=ask,0.0
AEQD:lat_0=ask,0.0;lon_0=ask,20.0
AIRY:lat_0=ask,0.0;lat_b=ask,90.0;lon_0=ask,20.0;no_cut=ask,nodfl
AITOFF:lat_0=ask,0.0;lon_0=ask,20.0
ALSK:lat_0=noask,64.0;lon_0=noask,-152.0
APIAN:lat_0=ask,0.0;lon_0=ask,20.0
AUGUST:lat_0=ask,0.0;lon_0=ask,20.0
BACON:lat_0=ask,0.0;lon_0=ask,20.0
BIPC:lat_0=ask,0.0;lon_0=ask,-90.0;ns=ask,nodfl
BOGGS:lat_0=ask,0.0;lon_0=ask,20.0
BONNE:lat_1=ask,40.0;lon_0=ask,20.0
CASS:lat_0=ask,0.0;lon_0=ask,20.0
CC:lat_0=ask,0.0;lon_0=ask,20.0
CEA:lat_0=ask,0.0;lat_ts=ask,0.0;lon_0=ask,20.0
CHAMB:lat_0=ask,55.0;lat_1=ask,40.0;lat_2=ask,20.0;lat_3=ask,35.0;lon_0=ask,20
.0;lon_1=ask,5.0;lon_2=ask,55.0;lon_3=ask,65.0
COLLG:lat_0=ask,0.0;lon_0=ask,20.0
CRAST:lat_0=ask,0.0;lon_0=ask,20.0
DENOY:lat_0=ask,0.0;lon_0=ask,20.0
ECK1:lat_0=ask,0.0;lon_0=ask,20.0
ECK2:lat_0=ask,0.0;lon_0=ask,20.0
ECK3:lat_0=ask,0.0;lon_0=ask,20.0
ECK4:lat_0=ask,0.0;lon_0=ask,20.0
ECK5:lat_0=ask,0.0;lon_0=ask,20.0
ECK6:lat_0=ask,0.0;lon_0=ask,20.0
EQC:lat_0=ask,0.0;lat_ts=ask,0.0;lon_0=ask,0.0
EQDC:lat_0=ask,40.0;lat_1=ask,20.0;lat_2=ask,60.0;lon_0=ask,20.0
EULER:lat_0=ask,55.0;lat_1=ask,45.0;lat_2=ask,65.0;lon_0=ask,20.0
FAHEY:lat_0=ask,0.0;lon_0=ask,20.0
FOUC:lat_0=ask,0.0;lon_0=ask,20.0
FOUC_S:lat_0=ask,0.0;lon_0=ask,20.0
GALL:lat_0=ask,0.0;lon_0=ask,20.0
GINS8:lat_0=ask,0.0;lon_0=ask,20.0
GNOM:lat_0=ask,0.0;lon_0=ask,20.0
GN_SINU:lat_0=ask,0.0;lon_0=ask,20.0;m=ask,1.0;n=ask,1.0
GOODE:lat_0=ask,0.0;lon_0=ask,20.0
GS48:lat_0=noask,45.0;lon_0=noask,-120.0
GS50:lat_0=noask,45.0;lon_0=noask,-120.0
HAMMER:M=ask,1.0;W=ask,0.5;lat_0=ask,0.0;lon_0=ask,20.0
HATANO:lat_0=ask,0.0;lon_0=ask,20.0

IMW_P:lat_0=ask,0.0;lat_1=ask,20.0;lat_2=ask,60.0;lon_0=ask,20.0;lon_1=ask,20.>
0

KAV5:lat_0=ask,0.0;lon_0=ask,20.0
KAV7:lat_0=ask,0.0;lon_0=ask,20.0
LABRD:azi=noask,18.9;k_0=noask,0.9995;lat_0=noask,18.9;lon_0=noask,46.43720833
3;x_0=noask,400000.0;y_0=noask,800000.0
LAEA:lat_0=ask,55.0;lon_0=ask,20.0;x_0=ask,0.0;y_0=ask,0.0
LAGRNG:W=ask,2.0;lat_0=ask,0.0;lat_1=ask,0.0;lon_0=ask,20.0
LARR:lat_0=ask,0.0;lon_0=ask,20.0
LASK:lat_0=ask,0.0;lon_0=ask,20.0
LCC:lat_0=ask,23.0;lat_1=ask,33.0;lat_2=ask,45.0;lon_0=ask,-96.0;x_0=ask,0.0;y
_0=ask,0.0
LEAC:lat_0=ask,55.0;lat_1=ask,0.0;lon_0=ask,20.0;south=ask,nodfl
LEE_OS:lat_0=noask,-10.0;lon_0=noask,-165.0
LOXIM:lat_0=ask,0.0;lat_1=ask,45.0;lon_0=ask,20.0
LSAT:lat_0=ask,0.0;lon_0=ask,20.0;lsat=ask,1;path=ask,1
MBTFPP:lat_0=ask,0.0;lon_0=ask,20.0
MBTFPQ:lat_0=ask,0.0;lon_0=ask,20.0
MBTFPS:lat_0=ask,0.0;lon_0=ask,20.0
MBT_FPS:lat_0=ask,0.0;lon_0=ask,20.0
MBT_S:lat_0=ask,0.0;lon_0=ask,20.0
MERC:k_0=ask,1.0;lat_ts=ask,0.;lon_0=ask,-96.0
MILL:lat_0=ask,0.0;lon_0=ask,20.0
MIL_OS:lat_0=noask,18.0;lon_0=noask,20.0
MOLL:lat_0=ask,0.0;lon_0=ask,20.0
MPOLY:lat_0=ask,0.0;lat_1=ask,-20.0;lat_2=ask,20.0;lon_0=ask,20.0;lotsa=ask,no
dfl
MURD1:lat_0=ask,0.0;lat_1=ask,-20.0;lat_2=ask,20.0;lon_0=ask,20.0
MURD2:lat_0=ask,0.0;lat_1=ask,-20.0;lat_2=ask,20.0;lon_0=ask,20.0
MURD3:lat_0=ask,0.0;lat_1=ask,-20.0;lat_2=ask,20.0;lon_0=ask,20.0
NELL:lat_0=ask,0.0;lon_0=ask,20.0
NELL_H:lat_0=ask,0.0;lon_0=ask,20.0
NICOL:lat_0=ask,0.0;lon_0=ask,20.0
NSPER:h=ask,50000000.0;lat_0=ask,55.0;lon_0=ask,20.0
NZMG:lat_0=noask,-41.0;lon_0=noask,173.0;x_0=noask,2510000.0;y_0=noask,6023150
.0
OB_TRAN:lat_0=ask,0.0;lon_0=ask,0.0;o_lat_p=ask,90.0;o_lon_p=ask,0.0
OCEA:lat_0=ask,0.0;lat_1=ask,-45.0;lat_2=ask,45.0;lon_0=ask,20.0;lon_1=ask,-20
.0;lon_2=ask,60.0
OEA:lat_0=ask,0.0;lon_0=ask,20.0;m=ask,1.0;n=ask,1.0;theta=ask,0.0
OMERC:k_0=ask,1.0;lat_0=ask,0.0;lat_1=ask,-45.0;lat_2=ask,45.0;lon_0=ask,20.0;
lon_1=ask,-40.0;lon_2=ask,40.0;no_rot=ask,nodfl;no_uoff=ask,nodfl;rot_conv=ask
,nodfl
ORTEL:lat_0=ask,0.0;lon_0=ask,20.0
ORTHO:lat_0=ask,0.0;lon_0=ask,20.0
PCONIC:lat_0=ask,0.0;lat_1=ask,33.0;lat_2=ask,45.0;lon_0=ask,20.0
POLY:lat_0=ask,0.0;lon_0=ask,-90.0
PUTP1:lat_0=ask,0.0;lon_0=ask,20.0
PUTP2:lat_0=ask,0.0;lon_0=ask,20.0
PUTP3:lat_0=ask,0.0;lon_0=ask,20.0
PUTP3P:lat_0=ask,0.0;lon_0=ask,20.0
PUTP4P:lat_0=ask,0.0;lon_0=ask,20.0
PUTP5:lat_0=ask,0.0;lon_0=ask,20.0
PUTP5P:lat_0=ask,0.0;lon_0=ask,20.0
PUTP6:lat_0=ask,0.0;lon_0=ask,20.0
PUTP6P:lat_0=ask,0.0;lon_0=ask,20.0
QUA_AUT:lat_0=ask,0.0;lon_0=ask,20.0
ROBIN:lat_0=ask,0.0;lon_0=ask,20.0
RPOLY:lat_0=ask,0.0;lat_ts=ask,0.0;lon_0=ask,20.0
SINU:lat_0=ask,0.0;lon_0=ask,20.0
SOMERC:k_0=noask,1.0;lat_0=noask,46.952405556;lon_0=noask,7.4395833333;x_0=noa
sk,600000.0;y_0=noask,200000.0
STERE:k_0=ask,1.0;lat_0=ask,0.0;lat_ts=ask,0.0;lon_0=ask,20.0
TCC:lat_0=ask,0.0;lon_0=ask,20.0
TCEA:k_0=ask,1.0;lat_0=ask,0.0;lon_0=ask,20.0
TISSOT:lat_0=ask,0.0;lat_1=ask,-30.0;lat_2=ask,45.0;lon_0=ask,20.0
TMERC:k_0=ask,1.0;lat_0=ask,23.0;lon_0=ask,-96.0;x_0=ask,0.0;y_0=ask,0.0
TPEQD:lat_0=ask,0.0;lat_1=ask,-45.0;lat_2=ask,45.0;lon_0=ask,20.0;lon_1=ask,-2
0.0;lon_2=ask,60.0
TPERS:azi=ask,0.0;h=ask,10000.0;lat_0=ask,0.0;lon_0=ask,20.0;tilt=ask,0.0
UPS:south=ask,nodfl
URM5:alpha=ask,0.0;lat_0=ask,0.0;lon_0=ask,20.0;n=ask,1.0;q=ask,1.0
URMFPS:lat_0=ask,0.0;lon_0=ask,20.0;n=ask,1.0
UTM:south=ask,nodfl;zone=ask,nodfl
VANDG:lat_0=ask,0.0;lon_0=ask,20.0
VANDG2:lat_0=ask,0.0;lon_0=ask,20.0
VANDG3:lat_0=ask,0.0;lon_0=ask,20.0
VANDG4:lat_0=ask,0.0;lon_0=ask,20.0
WAG1:lat_0=ask,0.0;lon_0=ask,20.0
WAG2:lat_0=ask,0.0;lon_0=ask,20.0
WAG3:lat_0=ask,0.0;lon_0=ask,20.0
WAG4:lat_0=ask,0.0;lon_0=ask,20.0
WAG5:lat_0=ask,0.0;lon_0=ask,20.0
WAG6:lat_0=ask,0.0;lon_0=ask,20.0
WAG7:lat_0=ask,0.0;lon_0=ask,20.0
WEREN:lat_0=ask,0.0;lon_0=ask,20.0
WINK1:lat_0=ask,0.0;lat_ts=ask,0.0;lon_0=ask,20.0
WINK2:lat_0=ask,0.0;lat_1=ask,0.0;lon_0=ask,20.0
WINTRI:lat_0=ask,0.0;lat_1=ask,0.0;lon_0=ask,20.0

13

Glynn Clements wrote:

Converting lib/gis/geo_init.c and g.setproj/main.c to text files was
simple enough; those are attached.

geo_init.c and g.setproj/main lack support for these (later additions to proj):

geos : Geostationary Satellite View
krovak : Krovak
lcca : Lambert Conformal Conic Alternative
sterea : Oblique Stereographic Alternative
vitk1 : Vitkovsky I

Since newer proj has separate projections for alternative lcc and stere, adding these to grass would solve at least one problem mentioned in this thread.

Morten

14

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@gclements.plus.com>

15

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@gclements.plus.com>
Date: Sun, 1 Oct 2006 22:21:08 +0100
To: Michael Barton <michael.barton@asu.edu>, Paul Kelly
<paul-grass@stjohnspoint.co.uk>, GRASS-DEV <grass-dev@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@gclements.plus.com>