[GRASS-dev] [bug #4742] (grass) i.fusion.brovey, i.in.spotvgt, v.rast.stats: don't use g.region

Justin_Hickey_via_RT · June 26, 2006, 6:59pm

this bug's URL: http://intevation.de/rt/webrt?serial_num=4742
-------------------------------------------------------------------------

Subject: i.fusion.brovey, i.in.spotvgt, v.rast.stats: don't use g.region

Glynn wrote on the grass-dev:

scripts shouldn't modify the WIND file unless persistently changing the
current region is the script's intended function.

use either WIND_OVERRIDE or GRASS_REGION (the latter is cleaner, but
the former is probably easier).

Maciek

-------------------------------------------- Managed by Request Tracker

Markus_Neteler1 · June 26, 2006, 7:17pm

On Mon, Jun 26, 2006 at 08:59:40PM +0200, Request Tracker wrote:

this bug's URL: http://intevation.de/rt/webrt?serial_num=4742
-------------------------------------------------------------------------

Subject: i.fusion.brovey, i.in.spotvgt, v.rast.stats: don't use g.region

Glynn wrote on the grass-dev:

> scripts shouldn't modify the WIND file unless persistently changing the
> current region is the script's intended function.

> use either WIND_OVERRIDE or GRASS_REGION (the latter is cleaner, but
> the former is probably easier).

Hi Maciek,

I answer since I am the author of all scripts:

Please look at the algorithm of i.fusion.brovey: it makes no sense
to operate at current resolution. But i.fusion.brovey saves the
region and restores it back.

v.rast.stats: same story.

Same thing with i.in.spotvgt: to perform the algorithm, we have
at least to set to the resolution of the imported map. Again,
also i.in.spotvgt saves and restores the current user region.
Since it is an import command, it should behave differently. GRASS
import commands are expected to import a full map.

We could discuss that the scripts internally only modify the resolution
but would keep the boundary coordinates. Not sure if it is then the
desried behaviour but feel free to implement that. But i.in.spotvgt
should be kept as implemented.

Markus

Markus_Neteler1 · June 26, 2006, 7:40pm

On Mon, Jun 26, 2006 at 09:17:21PM +0200, Markus Neteler wrote:

On Mon, Jun 26, 2006 at 08:59:40PM +0200, Request Tracker wrote:
> this bug's URL: http://intevation.de/rt/webrt?serial_num=4742
> -------------------------------------------------------------------------
>
> Subject: i.fusion.brovey, i.in.spotvgt, v.rast.stats: don't use g.region
>
> Glynn wrote on the grass-dev:
>
> > scripts shouldn't modify the WIND file unless persistently changing the
> > current region is the script's intended function.
>
> > use either WIND_OVERRIDE or GRASS_REGION (the latter is cleaner, but
> > the former is probably easier).
>

Hi Maciek,

I answer since I am the author of all scripts:

I answer again since I found my last answer confusing

i.in.spotvgt: it is an import script. The GRASS import commands are
expected to import a full map at original resolution. The internal
bit shuffling must therefore be done at the original map region
and resolution. The script saves the current user region and restores
it back.

i.fusion.brovey: Please look at the algorithm, it makes no sense to
to operate at user (random) resolution. But i.fusion.brovey saves the
region and restores it back as well.
Discussion: only fetch raster map resolution, but operate in user
region - feel free to implement this.

v.rast.stats: uses resolution of queried raster map (I don't think
that it makes too much sense to work at arbitray resolutions) but
respects the user defined coordinates. The script saves the current
region and restores it back.

Maybe you want to transfer the resolution management from v.rast.stats
to i.fusion.brovey. But I don't see much other changes to be useful.

Markus

H_B · June 27, 2006, 2:04am

> > this bug's URL: http://intevation.de/rt/webrt?serial_num=4742
> > -----------------------------------------------------------------
> >
> > Subject: i.fusion.brovey, i.in.spotvgt, v.rast.stats: don't use
> > g.region
> >
> > Glynn wrote on the grass-dev:
> >
> > > scripts shouldn't modify the WIND file unless persistently
> > > changing the current region is the script's intended function.
> >
> > > use either WIND_OVERRIDE or GRASS_REGION (the latter is cleaner,
> > > but the former is probably easier).

in practice WIND_OVERRIDE is actually more work? see below.

Markus:

i.in.spotvgt: it is an import script. The GRASS import commands are
expected to import a full map at original resolution. The internal
bit shuffling must therefore be done at the original map region
and resolution. The script saves the current user region and restores
it back.

(guessed) current region usage:

g.region save=region.save
g.region rast=$input
do_stuff()
g.region region.save
g.remove region=region.save

same thing, using WIND_OVERRIDE:

g.region save=region.save
g.region rast=$input
g.region save=region.tmp
g.region region.save
WIND_OVERRIDE=region.tmp
export WIND_OVERRIDE
do_stuff()
unset WIND_OVERRIDE # unneeded if script exits, but good hygiene
g.remove region=region.save,region.tmp

the current way seems simpler to me - with the problem that if the
script exits prematurely you will be left in a different region than the
one you started in.

using g.region is much better than hacking a WIND file directly - parity
checking, etc. This is a danger with using GRASS_REGION=""

i.fusion.brovey: Please look at the algorithm, it makes no sense to
to operate at user (random) resolution. But i.fusion.brovey saves the
region and restores it back as well.
Discussion: only fetch raster map resolution, but operate in user
region - feel free to implement this.

but,but,but ... "g.region -a" is needed in this case which can change
the bounds too?

v.rast.stats: uses resolution of queried raster map (I don't think
that it makes too much sense to work at arbitray resolutions) but
respects the user defined coordinates. The script saves the current
region and restores it back.

again, is "g.region -a" needed here?

For C (and SWIG) modules, I think we need a lib fn like

char * G_window_string(cellhd);

(any better G_() name?)

that will form a GRASS_REGION string from a cell-head structure.
maybe check that it is valid also (rows*nsres=ns_extent etc)??

with scripts I guess you could do

eval `g.region -g`
GRASS_REGION="north:$n;south:$s;..."
or

ORIGINAL_REGION=`g.region -p | tr '\n' ';' | sed -e 's/ //g' -e 's/;$//'`
RES=50
GRASS_REGION=`echo "$ORIGINAL_REGION" | sed -e "s/nsres:[^;]/nsres:$RES/"`

in any case I think (with error checking) we should favour GRASS_REGION
over WIND_OVERRIDE as a cleaner solution. With a C lib fn it shouldn't
be any more work to create.

Hamish

cmbarton · June 27, 2006, 3:47pm

See below.

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: Hamish <hamish_nospam@yahoo.com>
Date: Tue, 27 Jun 2006 14:04:04 +1200
To: Markus Neteler <neteler@itc.it>
Cc: <grass-bugs@intevation.de>, <grass-dev@grass.itc.it>
Subject: Re: [GRASS-dev] [bug #4742] (grass) i.fusion.brovey, i.in.spotvgt,
v.rast.stats: don't use g.region

in practice WIND_OVERRIDE is actually more work? see below.

Markus:

i.in.spotvgt: it is an import script. The GRASS import commands are
expected to import a full map at original resolution. The internal
bit shuffling must therefore be done at the original map region
and resolution. The script saves the current user region and restores
it back.

(guessed) current region usage:

g.region save=region.save
g.region rast=$input
do_stuff()
g.region region.save
g.remove region=region.save

same thing, using WIND_OVERRIDE:

g.region save=region.save
g.region rast=$input
g.region save=region.tmp
g.region region.save
WIND_OVERRIDE=region.tmp
export WIND_OVERRIDE
do_stuff()
unset WIND_OVERRIDE # unneeded if script exits, but good hygiene
g.remove region=region.save,region.tmp

Actually, this is making it overly complicated. It should actually be as
follows.

g.region -u save=region.save # save a region but don't change WIND
WIND_OVERRIDE=region.save
export WIND_OVERRIDE # use region.save like WIND but don't change WIND
g.region rast=$input
do_stuff()
unset WIND_OVERRIDE # unneeded if script exits, but good hygiene
g.remove region=region.save

The first way is not a problem for a simple script like this. It becomes a
problem when you are doing a lot of region changes for independent displays
in a GUI and don't want to mess things up for different displays or for
people doing something from the command line.

g.region rast=$input

Glynn_Clements1 · June 27, 2006, 4:00pm

Hamish wrote:

> > > this bug's URL: http://intevation.de/rt/webrt?serial_num=4742
> > > -----------------------------------------------------------------
> > >
> > > Subject: i.fusion.brovey, i.in.spotvgt, v.rast.stats: don't use
> > > g.region
> > >
> > > Glynn wrote on the grass-dev:
> > >
> > > > scripts shouldn't modify the WIND file unless persistently
> > > > changing the current region is the script's intended function.
> > >
> > > > use either WIND_OVERRIDE or GRASS_REGION (the latter is cleaner,
> > > > but the former is probably easier).

in practice WIND_OVERRIDE is actually more work? see below.

Markus:
> i.in.spotvgt: it is an import script. The GRASS import commands are
> expected to import a full map at original resolution. The internal
> bit shuffling must therefore be done at the original map region
> and resolution. The script saves the current user region and restores
> it back.

(guessed) current region usage:

g.region save=region.save
g.region rast=$input
do_stuff()
g.region region.save
g.remove region=region.save

same thing, using WIND_OVERRIDE:

g.region save=region.save
g.region rast=$input
g.region save=region.tmp
g.region region.save
WIND_OVERRIDE=region.tmp
export WIND_OVERRIDE
do_stuff()
unset WIND_OVERRIDE # unneeded if script exits, but good hygiene
g.remove region=region.save,region.tmp

You don't need to touch the current region at all. Just:

  g.region rast=$input save=region.tmp.$$
  WIND_OVERRIDE=region.tmp.$$
  export WIND_OVERRIDE
  do_stuff()
  g.remove region=region.tmp.$$

If do_stuff() is a single command, you could use a temporary
environment binding, i.e.:

  g.region rast=$input save=region.tmp.$$
  WIND_OVERRIDE=region.tmp.$$ do_stuff()
  g.remove region=region.tmp.$$

For C (and SWIG) modules, I think we need a lib fn like

char * G_window_string(cellhd);

(any better G_() name?)

that will form a GRASS_REGION string from a cell-head structure.
maybe check that it is valid also (rows*nsres=ns_extent etc)??

with scripts I guess you could do

eval `g.region -g`
GRASS_REGION="north:$n;south:$s;..."
or

ORIGINAL_REGION=`g.region -p | tr '\n' ';' | sed -e 's/ //g' -e 's/;$//'`
RES=50
GRASS_REGION=`echo "$ORIGINAL_REGION" | sed -e "s/nsres:[^;]/nsres:$RES/"`

in any case I think (with error checking) we should favour GRASS_REGION
over WIND_OVERRIDE as a cleaner solution. With a C lib fn it shouldn't
be any more work to create.

GRASS_REGION is cleaner in that you don't have to worry about:

a) choosing a region name which doesn't conflict with any existing
region, or
b) the saved region being left behind if the script terminates
prematurely.

It's currently more effort to use GRASS_REGION from within a shell
script; extending g.region to allow output in GRASS_REGION format
would eliminate that issue; you could just do e.g.:

GRASS_REGION=`g.region -e rast=$input`

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

H_B · June 28, 2006, 2:45pm

Actually, this is making it overly complicated. It should actually be
as follows.

g.region -u save=region.save # save a region but don't change WIND
WIND_OVERRIDE=region.save
export WIND_OVERRIDE # use region.save like WIND but don't change WIND
g.region rast=$input
do_stuff()
unset WIND_OVERRIDE # unneeded if script exits, but good hygiene
g.remove region=region.save

I am not sure that the region code is 100% working as you expect......

step by step:

g.region -u save=region.save # save a region but don't change WIND

it wouldn't change it anyway as no modifying parms were given? (like
rast=)

WIND_OVERRIDE=region.save
export WIND_OVERRIDE # use region.save like WIND but don't change WIND

ok

g.region rast=$input

but now you have in fact changed the region [written to the WIND file]?
(but the following modules are using WIND_OVERRIDE so you don't
notice)

do_stuff()
unset WIND_OVERRIDE # unneeded if script exits, but good hygiene
g.remove region=region.save

I'll work through a spearfish test as I don't have my head around this
fully:

G> g.region -d
G> g.region -p
projection: 1 (UTM)
zone: 13
datum: nad27
ellipsoid: clark66
north: 4928010
south: 4913700
west: 589980
east: 609000
nsres: 30
ewres: 30
rows: 477
cols: 634

G> g.region -u save=region.save
G> g.region -p
[same as above]

G> WIND_OVERRIDE=region.save
G> export WIND_OVERRIDE
G> g.region -p
[same as above]

G> g.region rast=elevation.10m
G> g.region -p
projection: 1 (UTM)
zone: 13
datum: nad27
ellipsoid: clark66
north: 4928000
south: 4914020
west: 590010
east: 609000
nsres: 10
ewres: 10
rows: 1398
cols: 1899

[changed!]

G> r.univar roads
100%
total null and non-null cells: 2654802

[1398*1899 = 2654802 so region being used is elevation.10m not
region.save!]

G> unset WIND_OVERRIDE
G> g.remove region=region.save

#final:
G> g.region -p
projection: 1 (UTM)
zone: 13
datum: nad27
ellipsoid: clark66
north: 4928000
south: 4914020
west: 590010
east: 609000
nsres: 10
ewres: 10
rows: 1398
cols: 1899

[left in elevation.10m's region, not starting region!]

trying with Glynn's method:

You don't need to touch the current region at all. Just:

g.region rast=$input save=region.tmp.$$
WIND_OVERRIDE=region.tmp.$$
export WIND_OVERRIDE
do_stuff()
g.remove region=region.tmp.$$

G> unset WIND_OVERRIDE
G> g.region -d
G> g.region -p
projection: 1 (UTM)
zone: 13
datum: nad27
ellipsoid: clark66
north: 4928010
south: 4913700
west: 589980
east: 609000
nsres: 30
ewres: 30
rows: 477
cols: 634

G> g.region rast=elevation.10m save=region.tmp.$$
G> g.region -p
projection: 1 (UTM)
zone: 13
datum: nad27
ellipsoid: clark66
north: 4928000
south: 4914020
west: 590010
east: 609000
nsres: 10
ewres: 10
rows: 1398
cols: 1899

[rrrrr. wrong. above needs "-u". let's try again, also with --o for
safety]

G> g.region -d
G> g.region -u rast=elevation.10m save=region.tmp.$$ --overwrite
G> g.region -p
..
nsres: 30
ewres: 30
..

[good; now region is still original but elevation.10m's region is saved]

G> WIND_OVERRIDE=region.tmp.$$
G> export WIND_OVERRIDE
G> g.region -p
..
nsres: 10
ewres: 10
rows: 1398
cols: 1899

[encouraging]

G> r.univar roads
100%
total null and non-null cells: 2654802

[we are using 10m res region from region.tmp.$$]

G> cat $MAPSET/WIND | grep res | grep -v resol3
e-w resol: 30
n-s resol: 30
t-b resol: 1

[WIND is untouched, good]

G> unset WIND_OVERRIDE
G> g.remove region=region.tmp.$$

G> g.region -p
..
nsres: 30
ewres: 30
rows: 477
cols: 634

back where we started in default region.

perhaps this accounts for some occasional gis.m weirdness?

Hamish

H_B · June 28, 2006, 3:04pm

some GIS.m / menu.tcl issues:

* launch r.digit from gis.m menu with no Map Display open leads to a
<region not set> error.

* d.font in menu.tcl has "execute term d.font" which is wrong. then
complains about can't get socket.. it is looking for an active x
monitor? This doesn't actually need a term at all?

* g.access. Does this really need to run in a term?

* g.gisenv: change to run_panel? currently it runs with "--ui" which
kills output. if run_panel you can't edit, add a second menu item for
that?

* g.region -p, g.version -c are broken. Move g.version to help menu?

Hamish

Glynn_Clements1 · June 28, 2006, 4:34pm

Glynn Clements wrote:

You don't need to touch the current region at all. Just:

  g.region rast=$input save=region.tmp.$$
  WIND_OVERRIDE=region.tmp.$$
  export WIND_OVERRIDE
  do_stuff()
  g.remove region=region.tmp.$$

Oops; the first g.region also needs the -u switch.

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

cmbarton · June 28, 2006, 6:35pm

Glynn's version was more compact, but I can answer your questions on my
version 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

From: Hamish <hamish_nospam@yahoo.com>
Date: Thu, 29 Jun 2006 02:45:13 +1200
To: Michael Barton <michael.barton@asu.edu>
Cc: <grass-dev@grass.itc.it>
Subject: Re: [GRASS-dev] [bug #4742] (grass) i.fusion.brovey, i.in.spotvgt,
v.rast.stats: don't use g.region

Actually, this is making it overly complicated. It should actually be
as follows.

g.region -u save=region.save # save a region but don't change WIND
WIND_OVERRIDE=region.save
export WIND_OVERRIDE # use region.save like WIND but don't change WIND
g.region rast=$input
do_stuff()
unset WIND_OVERRIDE # unneeded if script exits, but good hygiene
g.remove region=region.save

I am not sure that the region code is 100% working as you expect......

step by step:

g.region -u save=region.save # save a region but don't change WIND

it wouldn't change it anyway as no modifying parms were given? (like
rast=)

Just being safe

WIND_OVERRIDE=region.save
export WIND_OVERRIDE # use region.save like WIND but don't change WIND

ok

g.region rast=$input

but now you have in fact changed the region [written to the WIND file]?
(but the following modules are using WIND_OVERRIDE so you don't
notice)

Ah. This is where WIND_OVERRIDE (and GRASS_REGION) is useful. For all
functional purposes (display AND for any GIS operation like query or mapcalc
output) the region is reset to $input. BUT it is region.save that changes,
not WIND. Until WIND_OVERRIDE is reset, WIND just sets there and nothing
happens to it; region.save becomes the active WIND file for all activities.

do_stuff()

Same as above. All GIS functions behave as if region.save were WIND. WIND is
ignored.

unset WIND_OVERRIDE # unneeded if script exits, but good hygiene

Now WIND is NOT ignored; region.save is now treated like any normal saved
region file.

g.remove region=region.save

I'll work through a spearfish test as I don't have my head around this
fully:

G> g.region -d
G> g.region -p
projection: 1 (UTM)
zone: 13
datum: nad27
ellipsoid: clark66
north: 4928010
south: 4913700
west: 589980
east: 609000
nsres: 30
ewres: 30
rows: 477
cols: 634

G> g.region -u save=region.save
G> g.region -p
[same as above]

G> WIND_OVERRIDE=region.save
G> export WIND_OVERRIDE
G> g.region -p
[same as above]

G> g.region rast=elevation.10m
G> g.region -p
projection: 1 (UTM)
zone: 13
datum: nad27
ellipsoid: clark66
north: 4928000
south: 4914020
west: 590010
east: 609000
nsres: 10
ewres: 10
rows: 1398
cols: 1899

[changed!]

G> r.univar roads
100%
total null and non-null cells: 2654802

[1398*1899 = 2654802 so region being used is elevation.10m not
region.save!]

G> unset WIND_OVERRIDE
G> g.remove region=region.save

#final:
G> g.region -p
projection: 1 (UTM)
zone: 13
datum: nad27
ellipsoid: clark66
north: 4928000
south: 4914020
west: 590010
east: 609000
nsres: 10
ewres: 10
rows: 1398
cols: 1899

[left in elevation.10m's region, not starting region!]

trying with Glynn's method:

You don't need to touch the current region at all. Just:

g.region rast=$input save=region.tmp.$$
WIND_OVERRIDE=region.tmp.$$
export WIND_OVERRIDE
do_stuff()
g.remove region=region.tmp.$$

G> unset WIND_OVERRIDE
G> g.region -d
G> g.region -p
projection: 1 (UTM)
zone: 13
datum: nad27
ellipsoid: clark66
north: 4928010
south: 4913700
west: 589980
east: 609000
nsres: 30
ewres: 30
rows: 477
cols: 634

G> g.region rast=elevation.10m save=region.tmp.$$
G> g.region -p
projection: 1 (UTM)
zone: 13
datum: nad27
ellipsoid: clark66
north: 4928000
south: 4914020
west: 590010
east: 609000
nsres: 10
ewres: 10
rows: 1398
cols: 1899

[rrrrr. wrong. above needs "-u". let's try again, also with --o for
safety]

G> g.region -d
G> g.region -u rast=elevation.10m save=region.tmp.$$ --overwrite
G> g.region -p
..
nsres: 30
ewres: 30
..

[good; now region is still original but elevation.10m's region is saved]

G> WIND_OVERRIDE=region.tmp.$$
G> export WIND_OVERRIDE
G> g.region -p
..
nsres: 10
ewres: 10
rows: 1398
cols: 1899

[encouraging]

G> r.univar roads
100%
total null and non-null cells: 2654802

[we are using 10m res region from region.tmp.$$]

G> cat $MAPSET/WIND | grep res | grep -v resol3
e-w resol: 30
n-s resol: 30
t-b resol: 1

[WIND is untouched, good]

G> unset WIND_OVERRIDE
G> g.remove region=region.tmp.$$

G> g.region -p
..
nsres: 30
ewres: 30
rows: 477
cols: 634

back where we started in default region.

perhaps this accounts for some occasional gis.m weirdness?

Hamish

H_B · June 29, 2006, 11:18am

Michael Barton wrote:

>> g.region -u save=region.save
>> WIND_OVERRIDE=region.save
>> export WIND_OVERRIDE # use region.save like WIND but don't change WIND
>> g.region rast=$input
>
> but now you have in fact changed the region [written to the WIND file]?
> (but the following modules are using WIND_OVERRIDE so you don't notice)

Ah. This is where WIND_OVERRIDE (and GRASS_REGION) is useful. For all
functional purposes (display AND for any GIS operation like query or
mapcalc output) the region is reset to $input. BUT it is region.save
that changes, not WIND. Until WIND_OVERRIDE is reset, WIND just sets
there and nothing happens to it; region.save becomes the active WIND
file for all activities.

I will try again with a non-grass terminal window watching the WIND file:
(and the same with the region.save file- placing them side by side)

cd ~/grassdata/spearfish60/user1
watch "cat WIND"

then in the GRASS session: (spearfish)

G> g.region -d
G> g.region -p
north: 4928010
south: 4913700
east: 609000
west: 589980
cols: 634
rows: 477
e-w resol: 30
n-s resol: 30

G> g.region -u save=region.save
G> g.region -p

[same as WIND; region.save is the same region as DEFAULT_WIND now]

G> export WIND_OVERRIDE=region.save

G> g.region rast=elevation.10m

Yes, you are right, I see region.save is the one that changes to res=10m.

G> g.region -p
nsres=10
G> r.univar elevation.10m
2654802 cells (= 10m res)

G> unset WIND_OVERRIDE # probably bad to g.remove region.save before unsetting!
G> g.region -p
nsres=30

G> g.remove region=region.save

So both methods are ok - I'm slowly getting my head around it.

Hamish

Glynn_Clements1 · June 29, 2006, 5:28pm

Hamish wrote:

some GIS.m / menu.tcl issues:

* launch r.digit from gis.m menu with no Map Display open leads to a
<region not set> error.

* d.font in menu.tcl has "execute term d.font" which is wrong. then
complains about can't get socket.. it is looking for an active x
monitor? This doesn't actually need a term at all?

d.font doesn't need a terminal.

* g.access. Does this really need to run in a term?

No.

* g.gisenv: change to run_panel? currently it runs with "--ui" which
kills output. if run_panel you can't edit, add a second menu item for
that?

g.gisenv uses a weird hack for printing the settings when it is run
without arguments. It should just check for the case where neither
get= nor set= were given.

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

cmbarton · July 3, 2006, 4:35pm

Hamish,

See 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

From: Hamish <hamish_nospam@yahoo.com>
Date: Thu, 29 Jun 2006 03:04:07 +1200
To: Michael Barton <michael.barton@asu.edu>
Cc: <grass-dev@grass.itc.it>
Subject: gis.m issues

some GIS.m / menu.tcl issues:

* launch r.digit from gis.m menu with no Map Display open leads to a
<region not set> error.

This is a problem with r.digit.

It won't start up in an xterm. I can't get it to start in an xterm from the
command line either--xterm -e r.digit just starts the TclTk gui. It flashes
a small dialog that disappears too quickly for me to read.

Other commands like i.points start up fine in an xterm. So I don't know what
is wrong.

There is a different issue with d.rast.edit in that it wants to have a map
displayed in an xmon, but there is not place to specify the map (i.e., you
must open it separately using d.rast).

* d.font in menu.tcl has "execute term d.font" which is wrong. then
complains about can't get socket.. it is looking for an active x
monitor? This doesn't actually need a term at all?

fixed

* g.access. Does this really need to run in a term?

fixed

* g.gisenv: change to run_panel? currently it runs with "--ui" which
kills output. if run_panel you can't edit, add a second menu item for
that?

fixed. I did 2 menu entries: one to show current settings and the other to
change settings.

* g.region -p, g.version -c are broken. Move g.version to help menu?

fixed

Hamish

H_B · July 4, 2006, 2:24am

Michael Barton wrote:

> some GIS.m / menu.tcl issues:
>
> * launch r.digit from gis.m menu with no Map Display open leads to a
> <region not set> error.

This is a problem with r.digit.

It won't start up in an xterm. I can't get it to start in an xterm
from the command line either--xterm -e r.digit just starts the TclTk
gui. It flashes a small dialog that disappears too quickly for me to
read.

please update from CVS.

now grass-run.sh (lib/init/g-r.src) pauses if the module ends in an
error.

also r.digit has been changed to never use a startup GUI.

Other commands like i.points start up fine in an xterm. So I don't
know what is wrong.

r.digit needs a GIS.m Map Display window open to get region info from.

There is a different issue with d.rast.edit in that it wants to have a
map displayed in an xmon, but there is not place to specify the map
(i.e., you must open it separately using d.rast).

we can work on that, either with a bgmap= option or full bgcmd= like
v.digit.

same issue for r.digit, but I'd rather we leave r.digit alone and focus
on a new v.digit/r.digit replacement (write to ascii file on exit then
feed to "v.in.ascii format=standard" or r.in.poly). I think it is pretty
simple --- but we need to pick a Wx/Gtk Python flavour to move ahead!

Hamish

cmbarton · July 4, 2006, 3:17am

From: Hamish <hamish_nospam@yahoo.com>
Date: Tue, 4 Jul 2006 14:24:39 +1200
To: Michael Barton <michael.barton@asu.edu>
Cc: <grass-dev@grass.itc.it>
Subject: Re: gis.m issues

Michael Barton wrote:

some GIS.m / menu.tcl issues:

* launch r.digit from gis.m menu with no Map Display open leads to a
<region not set> error.

This is a problem with r.digit.

It won't start up in an xterm. I can't get it to start in an xterm
from the command line either--xterm -e r.digit just starts the TclTk
gui. It flashes a small dialog that disappears too quickly for me to
read.

please update from CVS.

now grass-run.sh (lib/init/g-r.src) pauses if the module ends in an
error.

also r.digit has been changed to never use a startup GUI.

I updated at the end of last week. Has it been changed again since then? I
tried to update today, but make failed on an internationalization section
error (sent to grass-dev this afternoon).

Other commands like i.points start up fine in an xterm. So I don't
know what is wrong.

r.digit needs a GIS.m Map Display window open to get region info from.

It should be getting this, so I'm not sure what is wrong.

There is a different issue with d.rast.edit in that it wants to have a
map displayed in an xmon, but there is not place to specify the map
(i.e., you must open it separately using d.rast).

we can work on that, either with a bgmap= option or full bgcmd= like
v.digit.

same issue for r.digit, but I'd rather we leave r.digit alone and focus
on a new v.digit/r.digit replacement (write to ascii file on exit then
feed to "v.in.ascii format=standard" or r.in.poly).

I agree

I think it is pretty
simple --- but we need to pick a Wx/Gtk Python flavour to move ahead!

I've done considerable background research and strongly favor wxPython.
Jachym, Trevor, and David Finlayson seem on board on this. Glynn is overall
neutral, though favoring PyGTK a bit. I'm sold on the Python platform and
think the wxWidgets extension is better cross-platform. I don't know whether
GTK has some better widgets or not, but wxPython has more than we need for
now and the future.

WxPython for Linux uses GTK; it uses native Mac and Windows widgets on those
platforms. AFAICT, wxPython creates a very nice interface in all supported
platforms using the same code. There are a few sections that are specific to
Windows, Linux, or Mac, but they are easy to avoid.

So that's what I think. Jachym, Trevor, David, and I are trying to create a
prototype wxPython interface to see if it works OK on Mac, Linux, and
Windows before we completely commit to it, however.

I'm gone on vacation for a week and a half, but will be working on this
afterwards, going through the new book on wxPython.

Cheers,
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

Syd_Visser · July 4, 2006, 2:18pm

We are moving over to Python and wxPython for most of our development work and therefore would definitely be in favor of grass going in that direction.
I noticed there are some VTK modules in grass now.
Has anyone looked at what Enthought ( http://www.enthought.com/ ) is doing using Python and wxPython especially MayaVi2 (3D visualization using VTK) https://svn.enthought.com/enthought/wiki/MayaVi.

Syd

> From: Hamish <hamish_nospam at yahoo.com>
> Date: Tue, 4 Jul 2006 14:24:39 +1200
> To: Michael Barton <michael.barton at asu.edu>
> Cc: <grass-dev at grass.itc.it>
> Subject: Re: gis.m issues
>
> Michael Barton wrote:
>

>I've done considerable background research and strongly favor wxPython.
>Jachym, Trevor, and David Finlayson seem on board on this. Glynn is overall
>neutral, though favoring PyGTK a bit. I'm sold on the Python platform and
>think the wxWidgets extension is better cross-platform. I don't know whether
>GTK has some better widgets or not, but wxPython has more than we need for
>now and the future.

>WxPython for Linux uses GTK; it uses native Mac and Windows widgets on those
>platforms. AFAICT, wxPython creates a very nice interface in all supported
>platforms using the same code. There are a few sections that are specific to
>Windows, Linux, or Mac, but they are easy to avoid.

>So that's what I think. Jachym, Trevor, David, and I are trying to create a
>prototype wxPython interface to see if it works OK on Mac, Linux, and
>Windows before we completely commit to it, however.

>I'm gone on vacation for a week and a half, but will be working on this
>afterwards, going through the new book on wxPython.

>Cheers,
>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

--
/////////////////////////////////////////////
Syd Visser P.Geo
SJ Geophysics Ltd
sydv@sjgeophysics.com
www.sjgeophysics.com

Markus_Neteler1 · July 4, 2006, 2:25pm

On Tue, Jul 04, 2006 at 07:18:04AM -0700, syd visser wrote:

We are moving over to Python and wxPython for most of our development
work and therefore would definitely be in favor of grass going in that
direction.

It did so last night I submitted the updated GRASS 5's wxPython
bindings to GRASS 6.1-CVS. See also:
http://grass.gdf-hannover.de/wiki/GRASS_and_Python

I noticed there are some VTK modules in grass now.
Has anyone looked at what Enthought ( http://www.enthought.com/ ) is
doing using Python and wxPython especially MayaVi2 (3D visualization
using VTK) https://svn.enthought.com/enthought/wiki/MayaVi.

It would be very nice to have more people working on
Python bindings.

Markus

Syd

> From: Hamish <hamish_nospam at yahoo.com>
> Date: Tue, 4 Jul 2006 14:24:39 +1200
> To: Michael Barton <michael.barton at asu.edu>
> Cc: <grass-dev at grass.itc.it>
> Subject: Re: gis.m issues
>
> Michael Barton wrote:
>

>I've done considerable background research and strongly favor wxPython.
>Jachym, Trevor, and David Finlayson seem on board on this. Glynn is
overall
>neutral, though favoring PyGTK a bit. I'm sold on the Python platform and
>think the wxWidgets extension is better cross-platform. I don't know
whether
>GTK has some better widgets or not, but wxPython has more than we need for
>now and the future.

>WxPython for Linux uses GTK; it uses native Mac and Windows widgets on
those
>platforms. AFAICT, wxPython creates a very nice interface in all supported
>platforms using the same code. There are a few sections that are
specific to
>Windows, Linux, or Mac, but they are easy to avoid.

>So that's what I think. Jachym, Trevor, David, and I are trying to
create a
>prototype wxPython interface to see if it works OK on Mac, Linux, and
>Windows before we completely commit to it, however.

>I'm gone on vacation for a week and a half, but will be working on this
>afterwards, going through the new book on wxPython.

>Cheers,
>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

--
/////////////////////////////////////////////
Syd Visser P.Geo
SJ Geophysics Ltd
sydv@sjgeophysics.com
www.sjgeophysics.com

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

--
Markus Neteler <neteler itc it> http://mpa.itc.it/markus/
ITC-irst - Centro per la Ricerca Scientifica e Tecnologica
MPBA - Predictive Models for Biol. & Environ. Data Analysis
Via Sommarive, 18 - 38050 Povo (Trento), Italy