[GRASS-dev] maybe bugs

Hello,

before I submit a bug report I just want to know if I found bugs or features
and/or if it is already fixed:

using cvs 2-3 days ago

1)
gis.m monitor freezes sometimes when loading new raster - "please wait ..."
remains and a raster is displayed only when I close gis.m and restart it - I
can tell when this happens but once/twice in each session.

2)
g.region still does not work as I know it e.g.
zoom to full extend
'g.region save=africa'
zoom in
select in monitor 'zoom to...saved region'
the displayed region is somewhere but definitely not region=africa

-> same behaviour in CLI and gis.m

3)
zoom out in monitor makes the display window smaller and smaller - this bug
has been reported before and I thought it would have been fixed

4)
r.patch does not patch two raster but parts of the first raster with adjacent
parts of the second one - can somebody report the same behaviour?

I will submit it as bugs if somebody can confirm this behaviour, best regards,
Martin

Martin Wegmann napisa?(a):

before I submit a bug report I just want to know if I found bugs or features
and/or if it is already fixed:

using cvs 2-3 days ago

1)
gis.m monitor freezes sometimes when loading new raster - "please wait ..."
remains and a raster is displayed only when I close gis.m and restart it - I
can tell when this happens but once/twice in each session.

Could you provide a reproducable test case based on spearfish?

2)
g.region still does not work as I know it e.g.
zoom to full extend
'g.region save=africa'
zoom in
select in monitor 'zoom to...saved region'
the displayed region is somewhere but definitely not region=africa

g.region has been working perfectly fine for me from CLI, I have tested
that just again. It's got to be something about gis.m region handling -
either you are missing something, or there is a bug in gis.m. Please
provide a reproducible test case for spearfish.

-> same behaviour in CLI and gis.m

'g.region save=window; d.zoom; g.region=window' from CLI seems all OK
for me. Can you provide a scenario where it fails in CLI for you?

3)
zoom out in monitor makes the display window smaller and smaller - this bug
has been reported before and I thought it would have been fixed

I don't understand. Can you elaborate?

4)
r.patch does not patch two raster but parts of the first raster with adjacent
parts of the second one - can somebody report the same behaviour?

Please provide a test case explaining what's wrong and what's expected.
Or maybe you forgot that r.patch is region sensitive?

Maciek

On Thursday 27 July 2006 13:05, Maciej Sieczka wrote:
[...]

> 1)
> gis.m monitor freezes sometimes when loading new raster - "please wait
> ..." remains and a raster is displayed only when I close gis.m and
> restart it - I can't tell when this happens but once/twice in each

session.

Could you provide a reproducable test case based on spearfish?

well, it happens now and then; I have the impression that large files causes
the error, but not every time - sorry. I'll try to investigate further.

> 2)
> g.region still does not work as I know it e.g.
> zoom to full extend
> 'g.region save=africa'
> zoom in
> select in monitor 'zoom to...saved region'
> the displayed region is somewhere but definitely not region=africa

g.region has been working perfectly fine for me from CLI, I have tested
that just again. It's got to be something about gis.m region handling -
either you are missing something, or there is a bug in gis.m. Please
provide a reproducible test case for spearfish.

> -> same behaviour in CLI and gis.m

'g.region save=window; d.zoom; g.region=window' from CLI seems all OK
for me. Can you provide a scenario where it fails in CLI for you?

well, perhaps I missed a part but doing the steps:

g.region save=africa
d.zoom
g.region africa
I get a small subset somewhere in the middle of Africa
(what is as well the region I get with r.patch see below->)

> 3)
> zoom out in monitor makes the display window smaller and smaller - this
> bug has been reported before and I thought it would have been fixed

I don't understand. Can you elaborate?

try:

zoom into map
zoom out: very elongated rectangle
map becomes smaller but is squeezed to one border (depending of the
orientation of the elongated rectangle)

> 4)
> r.patch does not patch two raster but parts of the first raster with
> adjacent parts of the second one - can somebody report the same
> behaviour?

Please provide a test case explaining what's wrong and what's expected.
Or maybe you forgot that r.patch is region sensitive?

well, I think as long as I haven't solved the g.region problem r.patch might
as well be restricted to the region settings.

hmm, I restarted the whole GRASS session and now it (g.region, r.patch only)
works, something must have looked the g.region settings. I try to reproduce
this behaviour, but I have no idea what causes g.region to unconsider the new
g.region settings. I'll mail if I found out.

regards, Martin

Martin Wegmann napisa?(a):

well, perhaps I missed a part but doing the steps:

g.region save=africa
d.zoom
g.region africa
I get a small subset somewhere in the middle of Africa
(what is as well the region I get with r.patch see below->)

Maybe this explains: gis.m doesn't read nor write to the WIND file,
while d.zoom/g.region do. What you change with d.zoom/g.region will not
affect gis.m display (unless you press 'Zoom to current region' from
gis.m menu) and vice versa: if you zoom/pan in the gis.m canvas it will
not affect WIND file, ie. current region settings. Check with g.region
-p for yourself.

3)
zoom out in monitor makes the display window smaller and smaller - this
bug has been reported before and I thought it would have been fixed

I don't understand. Can you elaborate?

try:

zoom into map
zoom out: very elongated rectangle
map becomes smaller but is squeezed to one border (depending of the
orientation of the elongated rectangle)

gis.m or d.m (d.zoom)?

If d.m, it behaves exactly the same as d.zoom and there's nothing there
could be done about it.

In of gis.m you have drawing modes:
Constrain map to region geometry
Map filles display window

The first mode behaves pretty much like d.zoom (only it doesn't modify
WIND file), the latter is maybe what you are looking for.

Does that explain?

4)
r.patch does not patch two raster but parts of the first raster with
adjacent parts of the second one - can somebody report the same
behaviour?

Please provide a test case explaining what's wrong and what's expected.
Or maybe you forgot that r.patch is region sensitive?

well, I think as long as I haven't solved the g.region problem r.patch might
as well be restricted to the region settings.

hmm, I restarted the whole GRASS session and now it (g.region, r.patch only)
works, something must have looked the g.region settings. I try to reproduce
this behaviour, but I have no idea what causes g.region to unconsider the new
g.region settings. I'll mail if I found out.

I suppose this is all your missundersting of region handling in gis.m.

Best,
Maciek

On Thursday 27 July 2006 13:39, Martin Wegmann wrote:

On Thursday 27 July 2006 13:05, Maciej Sieczka wrote:
[...]

> > 1)
> > gis.m monitor freezes sometimes when loading new raster - "please wait
> > ..." remains and a raster is displayed only when I close gis.m and
> > restart it - I can't tell when this happens but once/twice in each
>>
>>session.
>
> Could you provide a reproducable test case based on spearfish?

well, it happens now and then; I have the impression that large files
causes the error, but not every time - sorry. I'll try to investigate
further.

I executed a script (r.patch) which takes about 30 min to finish, after
executing I wanted to redraw some maps and zoom in but nothing happened
(please wait ...). After 1 1/2 hours the script was finished but the monitor
was still blank - redraw did not solve the problem.

closing gis.m (not closing the GRASS session), restarting gis.m solved the
problem - the raster is displayed again.
Memory problem?

Martin

[...]

On Thursday 27 July 2006 14:29, Maciej Sieczka wrote:

Martin Wegmann napisa?(a):
> well, perhaps I missed a part but doing the steps:
>
> g.region save=africa
> d.zoom
> g.region africa
> I get a small subset somewhere in the middle of Africa
> (what is as well the region I get with r.patch see below->)

Maybe this explains: gis.m doesn't read nor write to the WIND file,
while d.zoom/g.region do. What you change with d.zoom/g.region will not
affect gis.m display (unless you press 'Zoom to current region' from
gis.m menu) and vice versa: if you zoom/pan in the gis.m canvas it will
not affect WIND file, ie. current region settings. Check with g.region
-p for yourself.

it means, if I zoom into a region with gis.m and say 'g.region save=XX' in the
CLI and afterwards "zoom to .. region" it won't work - I tried it - well it
does not make sense for me who is working on the CLI and GUI.

How do I define a new region, if gis.m and g.region does not talk to each
other? Everytime starting d.mon x0 - d.rast XX - d.zoom - g.region save=XY
and then it works in gis.m as well or is there a "gis.m-way"

sorry, if I misunderstood you but I am a bit confused about g.region/d.zoom
vs. gis.m.

>>> 3)
>>> zoom out in monitor makes the display window smaller and smaller - this
>>> bug has been reported before and I thought it would have been fixed
>>
>> I don't understand. Can you elaborate?
>
> try:
>
> zoom into map
> zoom out: very elongated rectangle
> map becomes smaller but is squeezed to one border (depending of the
> orientation of the elongated rectangle)

gis.m or d.m (d.zoom)?

gis.m with the included zoom function in the monitor

If d.m, it behaves exactly the same as d.zoom and there's nothing there
could be done about it.

In of gis.m you have drawing modes:
Constrain map to region geometry
Map filles display window

The first mode behaves pretty much like d.zoom (only it doesn't modify
WIND file), the latter is maybe what you are looking for.

Does that explain?

thanks, now I found the buttons on the right hand side - ,-)

well but it does not explain why the visible extend (white space vs. grey
background) becomes smaller and smaller (by zooming out with very elongated
rectangle) when selecting "constrain map to region geometry", does it?

>>> 4)
>>> r.patch does not patch two raster but parts of the first raster with
>>> adjacent parts of the second one - can somebody report the same
>>> behaviour?
>>
>> Please provide a test case explaining what's wrong and what's expected.
>> Or maybe you forgot that r.patch is region sensitive?
>
> well, I think as long as I haven't solved the g.region problem r.patch
> might as well be restricted to the region settings.
>
>
> hmm, I restarted the whole GRASS session and now it (g.region, r.patch
> only) works, something must have looked the g.region settings. I try to
> reproduce this behaviour, but I have no idea what causes g.region to
> unconsider the new g.region settings. I'll mail if I found out.

I suppose this is all your missundersting of region handling in gis.m.

hmm, probably, thanks so far; I think I have to become more accustomed to
gis.m.

have a nice evening, Martin

Martin Wegmann napisa?(a):

On Thursday 27 July 2006 14:29, Maciej Sieczka wrote:

Martin Wegmann napisa?(a):

Maybe this explains: gis.m doesn't read nor write to the WIND file,
while d.zoom/g.region do. What you change with d.zoom/g.region will not
affect gis.m display (unless you press 'Zoom to current region' from
gis.m menu) and vice versa: if you zoom/pan in the gis.m canvas it will
not affect WIND file, ie. current region settings. Check with g.region
-p for yourself.

it means, if I zoom into a region with gis.m and say 'g.region save=XX' in the
CLI and afterwards "zoom to .. region" it won't work - I tried it - well it
does not make sense for me who is working on the CLI and GUI.

How do I define a new region, if gis.m and g.region does not talk to each
other?

There is a 'Set current region (WIND file) to match display' in the
'Zoom to...' menu. I haven't used it ever (I'm using gis.m very little
at all), but I guess it's for such purpose (I only wonder how it behaves
in different drawing modes ('Constrain map to region geometry' and 'Map
filles display window') as well as if it doesn't have problems with
resolution allignment. Please give a try and report back if you don't mind.

zoom into map
zoom out: very elongated rectangle
map becomes smaller but is squeezed to one border (depending of the
orientation of the elongated rectangle)

In of gis.m you have drawing modes:
Constrain map to region geometry
Map filles display window

The first mode behaves pretty much like d.zoom (only it doesn't modify
WIND file), the latter is maybe what you are looking for.

thanks, now I found the buttons on the right hand side - ,-)

well but it does not explain why the visible extend (white space vs. grey
background) becomes smaller and smaller (by zooming out with very elongated
rectangle) when selecting "constrain map to region geometry", does it?

You propably have a point here. Michael?

I suppose this is all your missundersting of region handling in gis.m.

hmm, probably, thanks so far; I think I have to become more accustomed to
gis.m.

Honestly - me too :).

Maciek

On Thursday 27 July 2006 15:46, Martin Wegmann wrote:

On Thursday 27 July 2006 13:39, Martin Wegmann wrote:
> On Thursday 27 July 2006 13:05, Maciej Sieczka wrote:
> [...]

[...]

I executed a script (r.patch) which takes about 30 min to finish, after
executing I wanted to redraw some maps and zoom in but nothing happened
(please wait ...). After 1 1/2 hours the script was finished but the
monitor was still blank - redraw did not solve the problem.

closing gis.m (not closing the GRASS session), restarting gis.m solved the
problem - the raster is displayed again.
Memory problem?

I get this error in the shell after I closed gis.m when no raster is displayed
and a script is running:

bgerror failed to handle background error.
    Original error: wrong # args: should be "Gm::cleanup destroywin"
    Error in bgerror: this isn't a Tk applicationunable to create
widget ".bgerrorDialog"
bgerror failed to handle background error.
    Original error: can't
read "_widget(.gronsole.gronsole.text.cmd323.progress,var)": no such element
in array
    Error in bgerror: this isn't a Tk applicationunable to create
widget ".bgerrorDialog"

Martin

On Thursday 27 July 2006 19:41, Maciej Sieczka wrote:

Martin Wegmann napisa?(a):
> On Thursday 27 July 2006 14:29, Maciej Sieczka wrote:
>> Martin Wegmann napisa?(a):
>>
>> Maybe this explains: gis.m doesn't read nor write to the WIND file,
>> while d.zoom/g.region do. What you change with d.zoom/g.region will not
>> affect gis.m display (unless you press 'Zoom to current region' from
>> gis.m menu) and vice versa: if you zoom/pan in the gis.m canvas it will
>> not affect WIND file, ie. current region settings. Check with g.region
>> -p for yourself.
>
> it means, if I zoom into a region with gis.m and say 'g.region save=XX'
> in the CLI and afterwards "zoom to .. region" it won't work - I tried it
> - well it does not make sense for me who is working on the CLI and GUI.
>
> How do I define a new region, if gis.m and g.region does not talk to each
> other?

There is a 'Set current region (WIND file) to match display' in the
'Zoom to...' menu. I haven't used it ever (I'm using gis.m very little
at all), but I guess it's for such purpose (I only wonder how it behaves
in different drawing modes ('Constrain map to region geometry' and 'Map
filles display window') as well as if it doesn't have problems with
resolution allignment. Please give a try and report back if you don't mind.

'Set current region (WIND file) to match display' sets the current extend
to "current region"

Selecting "zoom to current region" zoomes into the previously displayed area.

it works well after I understood gis.m, however how do I do "g.region save= "
in gis.m?

Is it planned to solve the lacking interaction between CLI g.region and gis.m?

e.g. doing 'g.region region=africa' in the CLI and refresh the monitor does
not work
or
zooming in with gis.m - doing g.region save in CLI - zoom to saved region in
gis.m does not work

>>> zoom into map
>>> zoom out: very elongated rectangle
>>> map becomes smaller but is squeezed to one border (depending of the
>>> orientation of the elongated rectangle)
>>
>> In of gis.m you have drawing modes:
>> Constrain map to region geometry
>> Map filles display window
>>
>> The first mode behaves pretty much like d.zoom (only it doesn't modify
>> WIND file), the latter is maybe what you are looking for.
>
> thanks, now I found the buttons on the right hand side - ,-)
>
> well but it does not explain why the visible extend (white space vs. grey
> background) becomes smaller and smaller (by zooming out with very
> elongated rectangle) when selecting "constrain map to region geometry",
> does it?

You propably have a point here. Michael?

>> I suppose this is all your missundersting of region handling in gis.m.
>
> hmm, probably, thanks so far; I think I have to become more accustomed to
> gis.m.

Honestly - me too :).

thanks so far, cheers, Martin

I just fixed a sort of bug in the one-click zoom out and commited it to the
cvs. It was working the way it was supposed to, but not how most people
might expect.

Now, when you do a single click with the zoomout tool, the map zooms out by
a given percentage (i.e., gets smaller) and is centered at the point you
clicked.

There was no problem with the zoomout box. The part of the map visible in
the display will get smaller and move so that it all fits into the box at
the place you draw the box. This is the converse of the zoomin box. There
the map gets bigger so that the area in the box fills the screen.

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: Martin Wegmann <wegmann@biozentrum.uni-wuerzburg.de>
Date: Thu, 27 Jul 2006 11:34:43 +0200
To: grass devel <grass-dev@grass.itc.it>
Subject: [GRASS-dev] maybe bugs

3)
zoom out in monitor makes the display window smaller and smaller - this bug
has been reported before and I thought it would have been fixed

I understand the confusion after the many years of having a single region
that affected everything--including all displays. What is causing the
confusion is the mechanics of making it possible for different displays to
independently have their own map layers to display and their own region
properties. If 2 displays are to have different region settings, they can't
be controlled by a g.region module that sets the region for everything.

For your specific issue, probably the best thing would be to add a save
region selection to the region menu button on each map display window
toolbar.

In the meantime, you can select the option to set the WIND file to the
displayed region in the display toolbar menu button, then open g.region and
save to a named region.

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: Martin Wegmann <wegmann@biozentrum.uni-wuerzburg.de>
Date: Thu, 27 Jul 2006 18:43:23 +0200
To: <grass-dev@grass.itc.it>
Subject: Re: [GRASS-dev] maybe bugs

it means, if I zoom into a region with gis.m and say 'g.region save=XX' in the
CLI and afterwards "zoom to .. region" it won't work - I tried it - well it
does not make sense for me who is working on the CLI and GUI.

How do I define a new region, if gis.m and g.region does not talk to each
other? Everytime starting d.mon x0 - d.rast XX - d.zoom - g.region save=XY
and then it works in gis.m as well or is there a "gis.m-way"

sorry, if I misunderstood you but I am a bit confused about g.region/d.zoom
vs. gis.m.

Michael Barton wrote:

I understand the confusion after the many years of having a single region
that affected everything--including all displays.

This isn't entirely accurate. The display library allows a region to
be associated with each frame, and will use that in preference to the
current region.

One consequence of this is that modules which use the display library
may behave differently to those which use the raster library directly.
For this reason, some tutorials recommend running d.erase whenever the
current region is changed (IOW, forcing the frame's region to match
the current region, which seems to defeat the purpose of associating a
region with a frame).

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

Interesting. Consistency?

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: Glynn Clements <glynn@gclements.plus.com>
Date: Sat, 29 Jul 2006 00:20:08 +0100
To: Michael Barton <michael.barton@asu.edu>
Cc: Martin Wegmann <wegmann@biozentrum.uni-wuerzburg.de>,
<grass-dev@grass.itc.it>, GRASS user list <grassuser@grass.itc.it>
Subject: Re: [GRASS-user] Re: [GRASS-dev] maybe bugs

Michael Barton wrote:

I understand the confusion after the many years of having a single region
that affected everything--including all displays.

This isn't entirely accurate. The display library allows a region to
be associated with each frame, and will use that in preference to the
current region.

One consequence of this is that modules which use the display library
may behave differently to those which use the raster library directly.
For this reason, some tutorials recommend running d.erase whenever the
current region is changed (IOW, forcing the frame's region to match
the current region, which seems to defeat the purpose of associating a
region with a frame).

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