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