[GRASS-dev] Re: [GRASS-user] check vector geometry

Jachym Cepicky wrote:

at your service

And vice-versa.

Works like a charm! Anybody minds it applied?

What a nice working Sunday. Thanks Jachym!

Maciek

P.S.

I'm wondering if flags should be exclusive or not in Grass modules, in
general.

For example, I asked Jachym to make it possible to his new '-t' flag
not to be excluded if used together with '-g', and it works. No matter
what flag seqeunce, if both are used, first goes the '-g' output, then
'-t'. But maybe I asked him for a wrong thing, maybe flags should be
exclusive? Or if they should be not exclusive, should the order they
are called metter? Eg. should '-tg' and '-gt' output in the same sequence?

Other modules (eg. g.region and r.info) don't allow for using many
flags at the same time, and they have some hierachy in excluding them,
but I can't find a pattern for that (is there one?).

Moreover, I found a strange thing about g.region. Try this:

$ g.region -e
region north-south extent: 270.000000
region east-west extent: 300.000000

$ g.region -g
n=4916070
s=4915800
w=602940
e=603240
nsres=30
ewres=30
rows=9
cols=10

BUT A COMBINATION OF BOTH GIVES NEITHER OF THE ABOVE:

$ g.region -eg
ns_extent=270.000000
ew_extent=300.000000

The region extent is printed, like if -e alone was used, but instead of
"region north-south extent" we get "ns_extent". Same thing, but
different wording.

?

Maciek

Thanks for the great patch Jachym. Looking forward to giving it a try.

Macieck:: i think that some flags are more condusive to being used
together than others, i.e. : g.region res=1 -ap both the 'a' and 'p'
flags are respected.

for something like the example you gave with g.region -eg -- I would
imagine that there is a case statement that computes these values, but
only one at a time (for efficiency in the old days?) . perhaps work
needs to be done to standardize flag parsing...

cheers,

dylan

On 9/24/06, Maciej Sieczka <tutey@o2.pl> wrote:

Jachym Cepicky wrote:
> at your service

And vice-versa.

Works like a charm! Anybody minds it applied?

What a nice working Sunday. Thanks Jachym!

Maciek

P.S.

I'm wondering if flags should be exclusive or not in Grass modules, in
general.

For example, I asked Jachym to make it possible to his new '-t' flag
not to be excluded if used together with '-g', and it works. No matter
what flag seqeunce, if both are used, first goes the '-g' output, then
'-t'. But maybe I asked him for a wrong thing, maybe flags should be
exclusive? Or if they should be not exclusive, should the order they
are called metter? Eg. should '-tg' and '-gt' output in the same sequence?

Other modules (eg. g.region and r.info) don't allow for using many
flags at the same time, and they have some hierachy in excluding them,
but I can't find a pattern for that (is there one?).

Moreover, I found a strange thing about g.region. Try this:

$ g.region -e
region north-south extent: 270.000000
region east-west extent: 300.000000

$ g.region -g
n=4916070
s=4915800
w=602940
e=603240
nsres=30
ewres=30
rows=9
cols=10

BUT A COMBINATION OF BOTH GIVES NEITHER OF THE ABOVE:

$ g.region -eg
ns_extent=270.000000
ew_extent=300.000000

The region extent is printed, like if -e alone was used, but instead of
"region north-south extent" we get "ns_extent". Same thing, but
different wording.

?

Maciek

_______________________________________________
grassuser mailing list
grassuser@grass.itc.it
http://grass.itc.it/mailman/listinfo/grassuser

hi,

On Sun, Sep 24, 2006 at 01:33:09PM -0700, Dylan Beaudette wrote:

Thanks for the great patch Jachym. Looking forward to giving it a try.

someone with clear imagination about how to write code in C and who
knows SUBMITTING file by heart would have to review it. it works, but
i'm not shure, if the code is celear enough

Macieck:: i think that some flags are more condusive to being used
together than others, i.e. : g.region res=1 -ap both the 'a' and 'p'
flags are respected.

for something like the example you gave with g.region -eg -- I would
imagine that there is a case statement that computes these values, but
only one at a time (for efficiency in the old days?) . perhaps work
needs to be done to standardize flag parsing...

in most cases, flags are handeld via

    if (flag1) {
    }
    else if (flag2) {
    }
    ...

this we have to check and rewrite (if it makes sence).

just my 2 cents

jachym

cheers,

dylan

On 9/24/06, Maciej Sieczka <tutey@o2.pl> wrote:
>Jachym Cepicky wrote:
>> at your service
>
>And vice-versa.
>
>Works like a charm! Anybody minds it applied?
>
>What a nice working Sunday. Thanks Jachym!
>
>Maciek
>
>P.S.
>
>I'm wondering if flags should be exclusive or not in Grass modules, in
>general.
>
>For example, I asked Jachym to make it possible to his new '-t' flag
>not to be excluded if used together with '-g', and it works. No matter
>what flag seqeunce, if both are used, first goes the '-g' output, then
>'-t'. But maybe I asked him for a wrong thing, maybe flags should be
>exclusive? Or if they should be not exclusive, should the order they
>are called metter? Eg. should '-tg' and '-gt' output in the same sequence?
>
>Other modules (eg. g.region and r.info) don't allow for using many
>flags at the same time, and they have some hierachy in excluding them,
>but I can't find a pattern for that (is there one?).
>
>
>
>Moreover, I found a strange thing about g.region. Try this:
>
>$ g.region -e
>region north-south extent: 270.000000
>region east-west extent: 300.000000
>
>$ g.region -g
>n=4916070
>s=4915800
>w=602940
>e=603240
>nsres=30
>ewres=30
>rows=9
>cols=10
>
>BUT A COMBINATION OF BOTH GIVES NEITHER OF THE ABOVE:
>
>$ g.region -eg
>ns_extent=270.000000
>ew_extent=300.000000
>
>The region extent is printed, like if -e alone was used, but instead of
>"region north-south extent" we get "ns_extent". Same thing, but
>different wording.
>
>?
>
>Maciek
>
>_______________________________________________
>grassuser mailing list
>grassuser@grass.itc.it
>http://grass.itc.it/mailman/listinfo/grassuser
>

--
Jachym Cepicky
e-mail: jachym.cepicky@centrum.cz
URL: http://les-ejk.cz
GPG: http://les-ejk.cz/gnupg_public_key/jachym_cepicky-gpg_public_key.asc
-----------------------------------------
OFFICE:
GDF-Hannover
Mengendamm 16d
30177 Hannover
Germany
e-mail: cepicky@gdf-hannover.de
URL: http://gdf-hannover.de
Tel.: +49 511-39088507

Maciej Sieczka wrote:

And vice-versa.

Works like a charm! Anybody minds it applied?

What a nice working Sunday. Thanks Jachym!

Maciek

P.S.

I'm wondering if flags should be exclusive or not in Grass modules, in
general.

It depends upon the nature of the flags; flags should not be mutually
exclusive unless there is a reason.

Generally speaking, flags which select a particular mode of operation
may be mutually exclusive if it isn't useful (or practical) to perform
multiple distinct tasks in a single run (you can always run the
program once for each mode). OTOH, flags which modify specific aspects
(e.g. human-readable vs machine-readable output) should operate
independently of other flags.

For example, I asked Jachym to make it possible to his new '-t' flag
not to be excluded if used together with '-g', and it works. No matter
what flag seqeunce, if both are used, first goes the '-g' output, then
'-t'. But maybe I asked him for a wrong thing, maybe flags should be
exclusive? Or if they should be not exclusive, should the order they
are called metter? Eg. should '-tg' and '-gt' output in the same sequence?

Flags are either present or absent; a module cannot determine the
order in which flags are specified.

If you want various items of data output in a specific order, use an
option with multiple values, e.g. output=region,topology vs
output=topology,region.

Other modules (eg. g.region and r.info) don't allow for using many
flags at the same time, and they have some hierachy in excluding them,
but I can't find a pattern for that (is there one?).

Moreover, I found a strange thing about g.region. Try this:

$ g.region -e
region north-south extent: 270.000000
region east-west extent: 300.000000

$ g.region -g
n=4916070
s=4915800
w=602940
e=603240
nsres=30
ewres=30
rows=9
cols=10

BUT A COMBINATION OF BOTH GIVES NEITHER OF THE ABOVE:

$ g.region -eg
ns_extent=270.000000
ew_extent=300.000000

The region extent is printed, like if -e alone was used, but instead of
"region north-south extent" we get "ns_extent". Same thing, but
different wording.

That makes sense. The -e flag displays the extents, while -g selects a
machine-readable format. Using both should display the extents in a
machine-readable format.

Note that -g is essentially shorthand for -pg; any option which
selects an output format implies -p unless some other option is given.

It's arguable that -pe should display the extents as well as the other
region parameters, and -peg should do likewise but using
machine-readable format.

Similarly, -lg should display lat/lon boundaries in shell format.

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

Glynn Clements wrote:

Maciej Sieczka wrote:

P.S.

I'm wondering if flags should be exclusive or not in Grass modules, in
general.

It depends upon the nature of the flags; flags should not be mutually
exclusive unless there is a reason.

Generally speaking, flags which select a particular mode of operation
may be mutually exclusive if it isn't useful (or practical) to perform
multiple distinct tasks in a single run (you can always run the
program once for each mode). OTOH, flags which modify specific aspects
(e.g. human-readable vs machine-readable output) should operate
independently of other flags.

For example, I asked Jachym to make it possible to his new '-t' flag
not to be excluded if used together with '-g', and it works. No matter
what flag seqeunce, if both are used, first goes the '-g' output, then
'-t'. But maybe I asked him for a wrong thing, maybe flags should be
exclusive? Or if they should be not exclusive, should the order they
are called metter? Eg. should '-tg' and '-gt' output in the same sequence?

Flags are either present or absent; a module cannot determine the
order in which flags are specified.

If you want various items of data output in a specific order, use an
option with multiple values, e.g. output=region,topology vs
output=topology,region.

Other modules (eg. g.region and r.info) don't allow for using many
flags at the same time, and they have some hierachy in excluding them,
but I can't find a pattern for that (is there one?).

Moreover, I found a strange thing about g.region. Try this:

$ g.region -e
region north-south extent: 270.000000
region east-west extent: 300.000000

$ g.region -g
n=4916070
s=4915800
w=602940
e=603240
nsres=30
ewres=30
rows=9
cols=10

BUT A COMBINATION OF BOTH GIVES NEITHER OF THE ABOVE:

$ g.region -eg
ns_extent=270.000000
ew_extent=300.000000

The region extent is printed, like if -e alone was used, but instead of
"region north-south extent" we get "ns_extent". Same thing, but
different wording.

That makes sense. The -e flag displays the extents, while -g selects a
machine-readable format. Using both should display the extents in a
machine-readable format.

Indeed it makes much sense, I get it. Hmm, but then -gc, -gl should
also output in a machine-readable format - but they don't, they still
print like if -c, -l was used alone.

Moreover, g.region description says: "-g Print the current region
(shell script style)". It doesn't mention the fact it can be combined
with other flags to make them print in shell script style - it only
mentions the region.

Given these, how should g.region be fixed then?

I suppose that -g alone should not work at all. Only when combined with
-p,-e,-c,-l it should print their machine-readable version. That would
make things clear and consistent. Of course not a plan for Grass 6.
Grass 7?

Note that -g is essentially shorthand for -pg; any option which
selects an output format implies -p unless some other option is given.

That's good to know, but it is not the way it is explained in Description.

It's arguable that -pe should display the extents as well as the other
region parameters, and -peg should do likewise but using
machine-readable format.

I second that.

Similarly, -lg should display lat/lon boundaries in shell format.

Ditto.

Maciek

hi,
since nobody complained, i just commited the patch in cvs

i hope, it will work as desired

jachym

On Sun, Sep 24, 2006 at 10:44:55PM +0200, Jachym Cepicky wrote:

hi,

On Sun, Sep 24, 2006 at 01:33:09PM -0700, Dylan Beaudette wrote:
> Thanks for the great patch Jachym. Looking forward to giving it a try.

someone with clear imagination about how to write code in C and who
knows SUBMITTING file by heart would have to review it. it works, but
i'm not shure, if the code is celear enough

>
> Macieck:: i think that some flags are more condusive to being used
> together than others, i.e. : g.region res=1 -ap both the 'a' and 'p'
> flags are respected.
>
> for something like the example you gave with g.region -eg -- I would
> imagine that there is a case statement that computes these values, but
> only one at a time (for efficiency in the old days?) . perhaps work
> needs to be done to standardize flag parsing...
>

in most cases, flags are handeld via

    if (flag1) {
    }
    else if (flag2) {
    }
    ...

this we have to check and rewrite (if it makes sence).

just my 2 cents

jachym

> cheers,
>
> dylan
>
> On 9/24/06, Maciej Sieczka <tutey@o2.pl> wrote:
> >Jachym Cepicky wrote:
> >> at your service
> >
> >And vice-versa.
> >
> >Works like a charm! Anybody minds it applied?
> >
> >What a nice working Sunday. Thanks Jachym!
> >
> >Maciek
> >
> >P.S.
> >
> >I'm wondering if flags should be exclusive or not in Grass modules, in
> >general.
> >
> >For example, I asked Jachym to make it possible to his new '-t' flag
> >not to be excluded if used together with '-g', and it works. No matter
> >what flag seqeunce, if both are used, first goes the '-g' output, then
> >'-t'. But maybe I asked him for a wrong thing, maybe flags should be
> >exclusive? Or if they should be not exclusive, should the order they
> >are called metter? Eg. should '-tg' and '-gt' output in the same sequence?
> >
> >Other modules (eg. g.region and r.info) don't allow for using many
> >flags at the same time, and they have some hierachy in excluding them,
> >but I can't find a pattern for that (is there one?).
> >
> >
> >
> >Moreover, I found a strange thing about g.region. Try this:
> >
> >$ g.region -e
> >region north-south extent: 270.000000
> >region east-west extent: 300.000000
> >
> >$ g.region -g
> >n=4916070
> >s=4915800
> >w=602940
> >e=603240
> >nsres=30
> >ewres=30
> >rows=9
> >cols=10
> >
> >BUT A COMBINATION OF BOTH GIVES NEITHER OF THE ABOVE:
> >
> >$ g.region -eg
> >ns_extent=270.000000
> >ew_extent=300.000000
> >
> >The region extent is printed, like if -e alone was used, but instead of
> >"region north-south extent" we get "ns_extent". Same thing, but
> >different wording.
> >
> >?
> >
> >Maciek
> >
> >_______________________________________________
> >grassuser mailing list
> >grassuser@grass.itc.it
> >http://grass.itc.it/mailman/listinfo/grassuser
> >

--
Jachym Cepicky
e-mail: jachym.cepicky@centrum.cz
URL: http://les-ejk.cz
GPG: http://les-ejk.cz/gnupg_public_key/jachym_cepicky-gpg_public_key.asc
-----------------------------------------
OFFICE:
GDF-Hannover
Mengendamm 16d
30177 Hannover
Germany
e-mail: cepicky@gdf-hannover.de
URL: http://gdf-hannover.de
Tel.: +49 511-39088507

_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev

--
Jachym Cepicky
e-mail: jachym.cepicky@centrum.cz
URL: http://les-ejk.cz
GPG: http://les-ejk.cz/gnupg_public_key/jachym_cepicky-gpg_public_key.asc
-----------------------------------------
OFFICE:
GDF-Hannover
Mengendamm 16d
30177 Hannover
Germany
e-mail: cepicky@gdf-hannover.de
URL: http://gdf-hannover.de
Tel.: +49 511-39088507

Maciej Sieczka wrote:

>> The region extent is printed, like if -e alone was used, but instead of
>> "region north-south extent" we get "ns_extent". Same thing, but
>> different wording.

> That makes sense. The -e flag displays the extents, while -g selects a
> machine-readable format. Using both should display the extents in a
> machine-readable format.

Indeed it makes much sense, I get it. Hmm, but then -gc, -gl should
also output in a machine-readable format - but they don't, they still
print like if -c, -l was used alone.

Moreover, g.region description says: "-g Print the current region
(shell script style)". It doesn't mention the fact it can be combined
with other flags to make them print in shell script style - it only
mentions the region.

Given these, how should g.region be fixed then?

I suggest:

1. Make -g, -l and -m orthogonal to other options, i.e. any option
which displays some information should take account of these options.

2. Make -p, -e and -c orthogonal rather than mutually exclusive, i.e.
any combination of those three flags should be allowed, with multiple
flags resulting in multiple pieces of information being displayed.

3. If either -g or -l (or both) are given, and none of -p, -e or -c
are given, assume -p.

I suppose that -g alone should not work at all. Only when combined with
-p,-e,-c,-l it should print their machine-readable version. That would
make things clear and consistent. Of course not a plan for Grass 6.
Grass 7?

See #3 above. This can be implemented now, as all of the "intended"
combinations of flags will still produce the same output. Only the
behaviour for unintended combinations will change.

> Note that -g is essentially shorthand for -pg; any option which
> selects an output format implies -p unless some other option is given.

That's good to know, but it is not the way it is explained in Description.

I suspect that the behaviour is accidental rather than by design. -g
chooses a specific mode, but the code which handles -e also checks the
state of -g. IOW, it's both a mode and a modifier.

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

Hi,

? [1] ?, the patch attached.

Martin

[1] http://gama.fsv.cvut.cz/~landa/.../grass/g_region_pg.txt

2006/9/25, Maciej Sieczka <tutey@o2.pl>:

Glynn Clements wrote:
> Maciej Sieczka wrote:

>> P.S.
>>
>> I'm wondering if flags should be exclusive or not in Grass modules, in
>> general.

> It depends upon the nature of the flags; flags should not be mutually
> exclusive unless there is a reason.
>
> Generally speaking, flags which select a particular mode of operation
> may be mutually exclusive if it isn't useful (or practical) to perform
> multiple distinct tasks in a single run (you can always run the
> program once for each mode). OTOH, flags which modify specific aspects
> (e.g. human-readable vs machine-readable output) should operate
> independently of other flags.

>> For example, I asked Jachym to make it possible to his new '-t' flag
>> not to be excluded if used together with '-g', and it works. No matter
>> what flag seqeunce, if both are used, first goes the '-g' output, then
>> '-t'. But maybe I asked him for a wrong thing, maybe flags should be
>> exclusive? Or if they should be not exclusive, should the order they
>> are called metter? Eg. should '-tg' and '-gt' output in the same sequence?

> Flags are either present or absent; a module cannot determine the
> order in which flags are specified.
>
> If you want various items of data output in a specific order, use an
> option with multiple values, e.g. output=region,topology vs
> output=topology,region.

>> Other modules (eg. g.region and r.info) don't allow for using many
>> flags at the same time, and they have some hierachy in excluding them,
>> but I can't find a pattern for that (is there one?).
>>
>> Moreover, I found a strange thing about g.region. Try this:
>>
>> $ g.region -e
>> region north-south extent: 270.000000
>> region east-west extent: 300.000000
>>
>> $ g.region -g
>> n=4916070
>> s=4915800
>> w=602940
>> e=603240
>> nsres=30
>> ewres=30
>> rows=9
>> cols=10
>>
>> BUT A COMBINATION OF BOTH GIVES NEITHER OF THE ABOVE:
>>
>> $ g.region -eg
>> ns_extent=270.000000
>> ew_extent=300.000000
>>
>> The region extent is printed, like if -e alone was used, but instead of
>> "region north-south extent" we get "ns_extent". Same thing, but
>> different wording.

> That makes sense. The -e flag displays the extents, while -g selects a
> machine-readable format. Using both should display the extents in a
> machine-readable format.

Indeed it makes much sense, I get it. Hmm, but then -gc, -gl should
also output in a machine-readable format - but they don't, they still
print like if -c, -l was used alone.

Moreover, g.region description says: "-g Print the current region
(shell script style)". It doesn't mention the fact it can be combined
with other flags to make them print in shell script style - it only
mentions the region.

Given these, how should g.region be fixed then?

I suppose that -g alone should not work at all. Only when combined with
-p,-e,-c,-l it should print their machine-readable version. That would
make things clear and consistent. Of course not a plan for Grass 6.
Grass 7?

> Note that -g is essentially shorthand for -pg; any option which
> selects an output format implies -p unless some other option is given.

That's good to know, but it is not the way it is explained in Description.

> It's arguable that -pe should display the extents as well as the other
> region parameters, and -peg should do likewise but using
> machine-readable format.

I second that.

> Similarly, -lg should display lat/lon boundaries in shell format.

Ditto.

Maciek

_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev

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

(attachments)

g_region_pg.diff.gz (3.11 KB)

Something making things complicated is that

g.region -p

and

g.region -g

return different suites of region values and also format the values
differently for latlon (-g in decimal degrees, while -p uses dd:mm:ss
format). This kind of inconsistency also occurs in other modules (e.g.
r.describe).

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: Maciej Sieczka <tutey@o2.pl>
Date: Mon, 25 Sep 2006 17:09:13 +0200
To: Glynn Clements <glynn@gclements.plus.com>
Cc: GRASSLIST <grassuser@grass.itc.it>, Jachym Cepicky
<jachym.cepicky@centrum.cz>, grass-dev <grass-dev@grass.itc.it>
Subject: [GRASS-dev] Re: [GRASS-user] check vector geometry

Given these, how should g.region be fixed then?

I suppose that -g alone should not work at all. Only when combined with
-p,-e,-c,-l it should print their machine-readable version. That would
make things clear and consistent. Of course not a plan for Grass 6.
Grass 7?

Hi Glynn,

well, trying to follow your suggestion, see [1] and the patch.

Best, Martin

[1] http://gama.fsv.cvut.cz/~landa/.../grass/g_region_log2.txt

2006/9/25, Glynn Clements <glynn@gclements.plus.com>:

Maciej Sieczka wrote:

> >> The region extent is printed, like if -e alone was used, but instead of
> >> "region north-south extent" we get "ns_extent". Same thing, but
> >> different wording.
>
> > That makes sense. The -e flag displays the extents, while -g selects a
> > machine-readable format. Using both should display the extents in a
> > machine-readable format.
>
> Indeed it makes much sense, I get it. Hmm, but then -gc, -gl should
> also output in a machine-readable format - but they don't, they still
> print like if -c, -l was used alone.
>
> Moreover, g.region description says: "-g Print the current region
> (shell script style)". It doesn't mention the fact it can be combined
> with other flags to make them print in shell script style - it only
> mentions the region.
>
> Given these, how should g.region be fixed then?

I suggest:

1. Make -g, -l and -m orthogonal to other options, i.e. any option
which displays some information should take account of these options.

2. Make -p, -e and -c orthogonal rather than mutually exclusive, i.e.
any combination of those three flags should be allowed, with multiple
flags resulting in multiple pieces of information being displayed.

3. If either -g or -l (or both) are given, and none of -p, -e or -c
are given, assume -p.

> I suppose that -g alone should not work at all. Only when combined with
> -p,-e,-c,-l it should print their machine-readable version. That would
> make things clear and consistent. Of course not a plan for Grass 6.
> Grass 7?

See #3 above. This can be implemented now, as all of the "intended"
combinations of flags will still produce the same output. Only the
behaviour for unintended combinations will change.

> > Note that -g is essentially shorthand for -pg; any option which
> > selects an output format implies -p unless some other option is given.
>
> That's good to know, but it is not the way it is explained in Description.

I suspect that the behaviour is accidental rather than by design. -g
chooses a specific mode, but the code which handles -e also checks the
state of -g. IOW, it's both a mode and a modifier.

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

_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev

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

(attachments)

g_region_pg2.diff.gz (5.59 KB)

Michael Barton wrote:

Something making things complicated is that

g.region -p

and

g.region -g

return different suites of region values

AFAICT, -g returns a subset of -p (or, to put it another way, -g
"formats" some of the values as an empty string). It should be
straightforward to add the missing values.

and also format the values
differently for latlon (-g in decimal degrees, while -p uses dd:mm:ss
format). This kind of inconsistency also occurs in other modules (e.g.
r.describe).

That isn't necessarily a problem; -g is supposed to change the format
of the output. Decimal degrees are easier to deal with, so if only one
format is available for -g, it should be decimal degrees.

It wouldn't be hard to add further options to select between decimal
degrees and DMS. Either an alternative to -g, which is equivalent to
-g except for the handling of lat/lon coordinates, or (preferably)
another modifier which would affect both human-readable and
machine-readable output (if the default format differs depending upon
whether -g is used, you need two modifiers, one to force decimal
degrees and one to force DMS).

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