[GRASS-dev] g.region print flags combination

[Michael Barton]

Martin,

I support your goals in making the output from g.region more consistent and
more informative. Now that everyone is communicating, I think we can all
sync things. We'll have to go through scripts to make sure that they are not
broken. Keeping the -g flag working by itself in the old way might make this
less of an issue.

If I understand this correctly, all g.region output will default to the new
-p style, unless modified by the -g flag. If modified by the -g flag, it
will be output in 'script' style.

Here are some general principles to make 'script' style more parsable by
scripts. Hopefully these can serve as guidelines for cleanup of other
commands like you did with g.region.

1. All output should be in the form of [key][separator][value]

2. The [key] should be the same for a given command in 'script' format,
regardless of what other modifier is used or the environment in which it is
used. That is, for 'script' style, [key] should not be "e" in one setting
and "east" in another. The same [key] should be formatted the same
regardless of the location setting (i.e., UTM vs latlon vs XY)

3. The [separator] should be the same in ALL commands using a 'script' style
output. Currently, the "=" is most widely used. It should be used in ALL
commands with 'script' style output.

4. The [value] should be in the same format regardless the location
environment or any other context. A script may not know a priori whether the
user is in a UTM or latlon environment. In fact, it may be trying to get
this information from the GRASS command. It would certainly be nice if ALL
commands that accepted coordinate input could read both decimal degrees and
DD:MM:SS formats.

5. There should be no spaces or other extraneous characters between
[key][separator][value], or at the end or beginning of this string.

6. There should be no warnings or other extraneous text printed with
'script' format. The assumption is that script format is not designed for
humans to read (although they certainly can, of course). If it fails for
some reason, it should get the standard error message. for that command. I
would strongly suggest getting rid of the warnings in script format for
g.region.

7. The lines of output should be the same regardless of the location
environment or any other context factor. R.describe is particularly
problematic in this regard, making it useless for scripting.

8. I would love to have -g work the same in all information producing
commands. It would making parsing r.info and v.info SO much easier.

I hope this can be helpful in the future. Others who work with scripts might
want to add to this also.

Michael


On 1/4/07 1:28 AM, "Martin Landa" <landa.martin at gmail.com> wrote:

> Hi all,
> 
> I would like to summarize all complication with the new behaviour of
> g.region. I would like also to ask you some question, to fix and close
> this issue finally;-)
> 
> 1) The -g flag can be used in combination with all print flags, e.g.
> 
> g.region -cg
> 
> I think it is without problem. There was idea to add a new flag for
> shell script style. I hope it is possible to use the -g flag for this
> work as well.
> 
> 2) It is possible to mix print flags, e.g.
> 
> g.region -pc
> 
> or for parsable output
> 
> g.region -pcg
> 
> There should not be any problem.
> 
> 3) The -p flag was changed.
> 
> projection: 99 (Krovak)
> zone: 0
> datum: towgs84=570.8,85.7,462.8,4.998,1.587,5.261,3.56
> 
> ->
> 
> projection : 99 (Krovak)
> zone       : 0
> datum      : towgs84=570.8,85.7,462.8,4.998,1.587,5.261,3.56
> 
> Not sure what formatting is more appropriate.
> 
> 4) g.region -g X g.region -pg --- I wanted to make -g flag more
> universal, e.g. to distinguish
> 
> g.region -pcl
> g.region -cl
> 
> and
> 
> g.region -pclg instead of g.region -gcl <-- problem
> g.region -gcl <-- problem
> 
> The question of the warning in `g.region -g` -- it can be printed at
> the end of the output or removed.
> 
> 5) New lines in shell script style output, I think this modification
> can be done in 6.x branch.
> 
> These lines can be added to the end of the output for backward
> compability -- OK?
> 
> Thanks for feedback!
> 
> Regards, Martin
> 
> 2007/1/2, Maciej Sieczka <tutey at o2.pl>:
>> Martin Landa wrote:
>> 
>>> 2007/1/2, Maciej Sieczka <tutey at o2.pl>:
>>> 
>>>> "g.region -g" works OK now, but it prints a WARNING message on the top.
>>>> It also prints few extra lines, compared to before, namely:
>>>> 
>>>> projection=1
>>>> zone=34
>>>> datum=wgs84
>>>> ellipsoid=wgs84
>>>> 
>>>> Your WARNING message is correct and desired, as well as the extra info
>>>>  is usefull, but those several additional lines might brake some user's
>>>> scripts.
>>> 
>>> So should I disable this warning, right?
>> 
>> I guess so. But somebody more knowledgable should decide.
>> 
>>> I think the additional lines would not break any scripts, which parse
>>> `g.region -g` output in a reasonable way (eval, awk) (?).
>> 
>> Those extra lines might brake all scripts that don't use eval, I
>> suppose. Eg. parsing with awk by line number will fail now:
>> 
>> # grab the current region settings
>> g.region -g > $TMP.${PROG}.region
>> 
>> # extract variables from the grabbed region
>> north=`awk 'BEGIN {FS="="} (NR==1) {print $2}' $TMP.${PROG}.region`
>> south=`awk 'BEGIN {FS="="} (NR==2) {print $2}' $TMP.${PROG}.region`
>> west=`awk 'BEGIN {FS="="} (NR==3) {print $2}' $TMP.${PROG}.region`
>> east=`awk 'BEGIN {FS="="} (NR==4) {print $2}' $TMP.${PROG}.region`
>> nsres=`awk 'BEGIN {FS="="} (NR==5) {print $2}' $TMP.${PROG}.region`
>> ewres=`awk 'BEGIN {FS="="} (NR==6) {print $2}' $TMP.${PROG}.region`
>> rows=`awk 'BEGIN {FS="="} (NR==7) {print $2}' $TMP.${PROG}.region`
>> cols=`awk 'BEGIN {FS="="} (NR==8) {print $2}' $TMP.${PROG}.region`
>> 
>> Is that "reasonable" I don't know, but it used to work with g.region -g
>> before your recent changes, and now it fails, because top 4 lines of
>> g.region -g output are different now.
>> 
>> I personally don't care too much, I have fixed my script to use eval,
>> but what with other users?
>> 
>> I absolutely agree you are doing a Good Thing fixing g.region -g as you
>> do, but I'm affraid it should wait till GRASS 7, for legacy reasons.
>> 
>> Maciek
>> 
> 

__________________________________________
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