[GRASS-dev] Re: [GRASS-user] Re: grassuser Digest, Vol 9, Issue 1

Hi,

2007/1/2, Paul Kelly <paul-grass@stjohnspoint.co.uk>:

But the other issue is of course - should we be changing the meaning of
the g.region -g flag at all? Why not keep it as it is and add the new
functionality (key=value output in combination with any other flag) to a
totally new flag, to reduce confusion and enhance backwards compatibility?

not sure, there are *a lot of flags* in g.region module. Adding a new
one which generally have the same impact as the -g flag (i.e.
key=value output) -- I don't know.

Now `g.region -g` (still there is a warning message) is the same as
`g.region -pg`. I think that the -g or --g flag should have the same
meaning in all GRASS modules: to print parsable output. I changed the
-g flag behaviour mainly because I wanted to allow user to use this
flag in connection with other print flags, e.g. `g.region -eg`.

Regards, Martin

--
Martin Landa <landa.martin@gmail.com> * http://gama.fsv.cvut.cz/~landa *

Hello Martin

On Wed, 3 Jan 2007, Martin Landa wrote:

Hi,

2007/1/2, Paul Kelly <paul-grass@stjohnspoint.co.uk>:

But the other issue is of course - should we be changing the meaning of
the g.region -g flag at all? Why not keep it as it is and add the new
functionality (key=value output in combination with any other flag) to a
totally new flag, to reduce confusion and enhance backwards compatibility?

not sure, there are *a lot of flags* in g.region module. Adding a new
one which generally have the same impact as the -g flag (i.e.
key=value output) -- I don't know.

Now `g.region -g` (still there is a warning message) is the same as
`g.region -pg`. I think that the -g or --g flag should have the same
meaning in all GRASS modules: to print parsable output. I changed the
-g flag behaviour mainly because I wanted to allow user to use this
flag in connection with other print flags, e.g. `g.region -eg`.

Yes its definitely not a bad thing to sort out the inconsistencies; you just need to also check how they affect other parts of GRASS. In particuar, gis.m seems to be quite tightly bound to the existing behaviour of g.region and its quirks. If you grep for g.region in the gui/tcltk/gis.m directory you will see quite a few places where it is called with different flags and then the output parsed with a regular expression. The return value of the regexp command isn't checked anywhere, so if the regular expression doesn't match the output from g.region exactly (e.g. because of the new features) then it will fail at some stage.

So it would be worthwhile I think to look at the existing uses of g.region and the matching regexps in gis.m and see if they can be rationalised to make best use of the new features of g.region.
Worth checking throughout the whole source code actually - there are a lot of things that call g.region and parse its output. Like I said, definitely a good idea to sort out the inconsistencies but need to stay backward-compatible until we fix everything that depended on the old behaviour.

Paul

I haven't yet tried this new version of g.region but hope to soon. It sounds
like g.region -g is now issuing an interactive terminal message. If this is
so, I need to note that we are trying to remove all required user
interaction via the terminal. Any command that sends a message and asks the
user for Y/N or something like that makes that command very difficult to use
in a script or GUI language. At least the --q option should kill all such
interaction. We should be able to run the command and have it return
whatever it returns (including an error where appropriate) without requiring
the user to interact via the terminal.

Thanks
Michael

On 1/3/07 12:41 AM, "Martin Landa" <landa.martin@gmail.com> wrote:

Hi,

2007/1/2, Paul Kelly <paul-grass@stjohnspoint.co.uk>:

But the other issue is of course - should we be changing the meaning of
the g.region -g flag at all? Why not keep it as it is and add the new
functionality (key=value output in combination with any other flag) to a
totally new flag, to reduce confusion and enhance backwards compatibility?

not sure, there are *a lot of flags* in g.region module. Adding a new
one which generally have the same impact as the -g flag (i.e.
key=value output) -- I don't know.

Now `g.region -g` (still there is a warning message) is the same as
`g.region -pg`. I think that the -g or --g flag should have the same
meaning in all GRASS modules: to print parsable output. I changed the
-g flag behaviour mainly because I wanted to allow user to use this
flag in connection with other print flags, e.g. `g.region -eg`.

Regards, Martin

__________________________________________
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

I very much agree. In order for the GUI and its display to work properly, we
must be able to obtain information about the current region and to change
it. The most transparent way to do this is entirely through the use of GRASS
commands rather than trying to read WIND or other files. Other
information-getting commands that are used in the GUI include r.info,
v.info, r.univar, v.univar.sh, and r.statistics.

I support trying to cleanup and regularize the output of any such commands
that return information about the GRASS environment. But because they are
used currently in the GUI (and other scripts), we need to be careful about
keeping them backward compatible or synching changes with other systems that
depend on them.

Michael

On 1/3/07 1:53 AM, "Paul Kelly" <paul-grass@stjohnspoint.co.uk> wrote:

So it would be worthwhile I think to look at the existing uses of g.region
and the matching regexps in gis.m and see if they can be rationalised to
make best use of the new features of g.region.
Worth checking throughout the whole source code actually - there are a lot
of things that call g.region and parse its output. Like I said, definitely
a good idea to sort out the inconsistencies but need to stay
backward-compatible until we fix everything that depended on the old
behaviour.

__________________________________________
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

I just was able to compile the cvs version from today. It turns out that
there are 2 issues.

First, g.region -g is functionally replaced by g.region -gp
Second, there has been a format change to the output from g.region -p

Both of these can be fixed in the GUI and I will try to do so today. I have
a couple of suggestions.

I'm not sure about putting the warning in g.region -g. But if it was after
the output, it would be much less harmful in existing scripts (including the
GUI) than if it precedes normal output.

Second, I don't know how the format for g.region -p changed exactly. Perhaps
it's better than before. And I'm strongly in favor of creating better, more
parsable, more consistent, output from commands like g.region. We just need
to be careful about breaking things where it is currently used when this is
done.

It looks like this affects both the main GUI and the georectifier in this
case.

Michael

On 1/3/07 1:53 AM, "Paul Kelly" <paul-grass@stjohnspoint.co.uk> wrote:

Hello Martin

On Wed, 3 Jan 2007, Martin Landa wrote:

Hi,

2007/1/2, Paul Kelly <paul-grass@stjohnspoint.co.uk>:

But the other issue is of course - should we be changing the meaning of
the g.region -g flag at all? Why not keep it as it is and add the new
functionality (key=value output in combination with any other flag) to a
totally new flag, to reduce confusion and enhance backwards compatibility?

not sure, there are *a lot of flags* in g.region module. Adding a new
one which generally have the same impact as the -g flag (i.e.
key=value output) -- I don't know.

Now `g.region -g` (still there is a warning message) is the same as
`g.region -pg`. I think that the -g or --g flag should have the same
meaning in all GRASS modules: to print parsable output. I changed the
-g flag behaviour mainly because I wanted to allow user to use this
flag in connection with other print flags, e.g. `g.region -eg`.

Yes its definitely not a bad thing to sort out the inconsistencies; you
just need to also check how they affect other parts of GRASS. In
particuar, gis.m seems to be quite tightly bound to the existing
behaviour of g.region and its quirks. If you grep for g.region in the
gui/tcltk/gis.m directory you will see quite a few places where it is
called with different flags and then the output parsed with a regular
expression. The return value of the regexp command isn't checked anywhere,
so if the regular expression doesn't match the output from g.region
exactly (e.g. because of the new features) then it will fail at some
stage.

So it would be worthwhile I think to look at the existing uses of g.region
and the matching regexps in gis.m and see if they can be rationalised to
make best use of the new features of g.region.
Worth checking throughout the whole source code actually - there are a lot
of things that call g.region and parse its output. Like I said, definitely
a good idea to sort out the inconsistencies but need to stay
backward-compatible until we fix everything that depended on the old
behaviour.

Paul

__________________________________________
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

Michael Barton wrote:

I haven't yet tried this new version of g.region but hope to soon. It sounds
like g.region -g is now issuing an interactive terminal message.

No it doesn't. The differences between the old and current g.region -g are:

- the WARNING message on the top of the g.region output

- 4 extra lines in the g.region -g output:
projection=
zone=
datum=
ellipsoid=

Maciek

I've fixed the issues that arose from the changes to g.region and committed
the updates to the cvs. Thanks again to Bernhard for getting me set up for
cvs access from home.

Michael

On 1/3/07 1:53 AM, "Paul Kelly" <paul-grass@stjohnspoint.co.uk> wrote:

Hello Martin

On Wed, 3 Jan 2007, Martin Landa wrote:

Hi,

2007/1/2, Paul Kelly <paul-grass@stjohnspoint.co.uk>:

But the other issue is of course - should we be changing the meaning of
the g.region -g flag at all? Why not keep it as it is and add the new
functionality (key=value output in combination with any other flag) to a
totally new flag, to reduce confusion and enhance backwards compatibility?

not sure, there are *a lot of flags* in g.region module. Adding a new
one which generally have the same impact as the -g flag (i.e.
key=value output) -- I don't know.

Now `g.region -g` (still there is a warning message) is the same as
`g.region -pg`. I think that the -g or --g flag should have the same
meaning in all GRASS modules: to print parsable output. I changed the
-g flag behaviour mainly because I wanted to allow user to use this
flag in connection with other print flags, e.g. `g.region -eg`.

Yes its definitely not a bad thing to sort out the inconsistencies; you
just need to also check how they affect other parts of GRASS. In
particuar, gis.m seems to be quite tightly bound to the existing
behaviour of g.region and its quirks. If you grep for g.region in the
gui/tcltk/gis.m directory you will see quite a few places where it is
called with different flags and then the output parsed with a regular
expression. The return value of the regexp command isn't checked anywhere,
so if the regular expression doesn't match the output from g.region
exactly (e.g. because of the new features) then it will fail at some
stage.

So it would be worthwhile I think to look at the existing uses of g.region
and the matching regexps in gis.m and see if they can be rationalised to
make best use of the new features of g.region.
Worth checking throughout the whole source code actually - there are a lot
of things that call g.region and parse its output. Like I said, definitely
a good idea to sort out the inconsistencies but need to stay
backward-compatible until we fix everything that depended on the old
behaviour.

Paul

__________________________________________
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

Hi,
On Wed, Jan 03, 2007 at 05:11:39PM +0100, Maciej Sieczka wrote:

Michael Barton wrote:
> I haven't yet tried this new version of g.region but hope to soon. It sounds
> like g.region -g is now issuing an interactive terminal message.

No it doesn't. The differences between the old and current g.region -g are:

- the WARNING message on the top of the g.region output

- 4 extra lines in the g.region -g output:
projection=
zone=
datum=
ellipsoid=

Maciek

sorry, if this will sound radical, but adding new lines of this kind to program
output is IMHO not *change* but *added funtionality*. It makes g.region more
usable than it was. It the output is more informative, than it was.
Maybe new lines could be clipped to end of the "old" output, not in
front of it.

Jachym

P.S. The -g flag could IMHO remain also in the future. It is faster to use
only one flag (-g) than two flags (-gp).

--
Jachym Cepicky
e-mail: jachym.cepicky@centrum.cz
URL: http://les-ejk.cz
GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub
-----------------------------------------
OFFICE:
Department of Geoinformation Technologies
Zemedelska 3
613 00, Brno
Czech Republick
e-mail: xcepicky@node.mendelu.cz
URL: http://mapserver.mendelu.cz
Tel.: +420 545 134 514

Michael Barton schrieb:

I've fixed the issues that arose from the changes to g.region and committed
the updates to the cvs.

Yes, it is working again. Thank you very much!

At the risk of being a nuisance: d.rast map=k1 -o fails on a known good map as following:

PNG: GRASS_TRUECOLOR status: TRUE
PNG: collecting to file: /home/grassdata/grassuser/user/.tmp/ucon643/24892.0.ppm,
    GRASS_WIDTH=642, GRASS_HEIGHT=465

region for current mapset line 7: <e-w resol:0>
run "g.region"

Mit freundlichen Grüßen / With kindest regards

Stefan Paulick

http://www.urbeli.com
mailto://stefan.paulick@urbeli.com
/*----------------------*/

Jachym Cepicky wrote:

On Wed, Jan 03, 2007 at 05:11:39PM +0100, Maciej Sieczka wrote:

Michael Barton wrote:

I haven't yet tried this new veWrsion of g.region but hope to soon. It sounds
like g.region -g is now issuing an interactive terminal message.

No it doesn't. The differences between the old and current g.region -g are:

- the WARNING message on the top of the g.region output

- 4 extra lines in the g.region -g output:
projection=
zone=
datum=
ellipsoid=

sorry, if this will sound radical, but adding new lines of this kind to program
output is IMHO not *change* but *added funtionality*.

Jachym,

Actually it is not really an *added* functionality, but a modification
to an *already-existing* functionality in GRASS 6. Martin's g.region -g
output is different from the g.region -g output before, isn't it?

I guess this should not happen *during* GRASS 6. Should be left for
GRASS 7.

Sure Martin's approach is right! I much appreciate and enjoy his work
on sanitising GRASS code. Only that *this particular change* might
brake programs depending on g.region output in GRASS 6 so far. That's
all I'm concerned with. That's my last word regarding this case. Please
do whatever you think is right now.

Best,
Maciek