[GRASS5] Window Extents and region settings in X...

GRASS GRASS developer
1

I noticed after the bit of work I've done on d.area, that I still have a
small inconsistency with much of the rest of the display code. Here's
the scenario:

1) User open's monitor
2) Monitor's dimensions aren't proportional to the current region
   settings.
3) Display program set's up region setting translation after opening
   driver.
4) Display program draws to monitor, but large portions in the Y or
   X extents are unused.

This is especially disconcerting looking when a portion of a vector map
abruptly cuts off, even though there's more vector data and window real
estate available. It's less disturbing with raster data, given its
rectangularity already...

I noticed I wasn't catching this with d.area and portions of the vector
will be drawn outside the "clipping area" because portions of the
polygons lie within the "drawing area" and hence the whole polygon is
returned, despite Vect_constraint_window() (which behaves correctly).

I wonder if it is desirable to keep this behavior, or to see if we can't
have region settings (for display purposes) extended in whichever
direction has the unused window real estate? I'm not sure that such a
thing could be done in the driver/raster lib area in such a way that
the display modules would all automatically utilize that adjusted
window.

P.S. For those of you following my d.area ramblings: Other than the
clipping thing, it seems to work well (albeit slow in extreme
circumstances). I did try to compare it to d.vect.cats and noticed that
d.vect.cats seems to have a *HUGE MEMORY LEAK*. So, d.vect.cats was
unusable as a comparison (I had to end up killing it if I tried to draw
all the possible categories for a certain large vector map).
--
Eric G. Miller <egm2@jps.net>

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

2

Eric G. Miller wrote:

I noticed after the bit of work I've done on d.area, that I still have a
small inconsistency with much of the rest of the display code. Here's
the scenario:

1) User open's monitor
2) Monitor's dimensions aren't proportional to the current region
   settings.
3) Display program set's up region setting translation after opening
   driver.
4) Display program draws to monitor, but large portions in the Y or
   X extents are unused.

This is especially disconcerting looking when a portion of a vector map
abruptly cuts off, even though there's more vector data and window real
estate available. It's less disturbing with raster data, given its
rectangularity already...

I noticed I wasn't catching this with d.area and portions of the vector
will be drawn outside the "clipping area" because portions of the
polygons lie within the "drawing area" and hence the whole polygon is
returned, despite Vect_constraint_window() (which behaves correctly).

I wonder if it is desirable to keep this behavior, or to see if we can't
have region settings (for display purposes) extended in whichever
direction has the unused window real estate? I'm not sure that such a
thing could be done in the driver/raster lib area in such a way that
the display modules would all automatically utilize that adjusted
window.

P.S. For those of you following my d.area ramblings: Other than the
clipping thing, it seems to work well (albeit slow in extreme
circumstances). I did try to compare it to d.vect.cats and noticed that
d.vect.cats seems to have a *HUGE MEMORY LEAK*. So, d.vect.cats was
unusable as a comparison (I had to end up killing it if I tried to draw
all the possible categories for a certain large vector map).
--

I think that region handling should be changed somehow. But that's task
for g51. My suggestion (not thought over deeply yet) is to distinguish region
used by:
1) modules creating new data
    which would use current region saved in WIND
and
2) monitor + display/query modules
    which would use region stored in memory of monitor.
    Each monitor would have it's own region.

Monitor region would always cover whole area of monitor.

New functions could be used for manipulating currend WIND, for example
display WIND on monitor (by rectangle), set WIND to region of selected
monitor, create WIND interactively on monitor, ...

Some problems with one shared region as is used now:
- user cannot rely on current state of monitor, if region was changed for
   a while, d.erase must be run even if region was reset to original size.
- it is impossible to run some script on data and at the same time
   explore maps on monitor (I forgot several times about it and I was very
   surprised why created data are incomplete)
- write access to database is always required even if user want only
   read/explore data.
- (more?)

I'm waiting for your criticism.

Radim

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

3

On Wed, 28 Feb 2001, Radim Blazek wrote:

Eric G. Miller wrote:
> I noticed after the bit of work I've done on d.area, that I still have a
> small inconsistency with much of the rest of the display code. Here's
> the scenario:
>
I think that region handling should be changed somehow. But that's task
for g51. My suggestion (not thought over deeply yet) is to distinguish region
used by:
1) modules creating new data
    which would use current region saved in WIND
and
2) monitor + display/query modules
    which would use region stored in memory of monitor.
    Each monitor would have it's own region.

Monitor region would always cover whole area of monitor.

New functions could be used for manipulating currend WIND, for example
display WIND on monitor (by rectangle), set WIND to region of selected
monitor, create WIND interactively on monitor, ...

Some problems with one shared region as is used now:
- user cannot rely on current state of monitor, if region was changed for
   a while, d.erase must be run even if region was reset to original size.
- it is impossible to run some script on data and at the same time
   explore maps on monitor (I forgot several times about it and I was very
   surprised why created data are incomplete)
- write access to database is always required even if user want only
   read/explore data.
- (more?)

This issue also arises in interfacing with other programs in my case
R. This was also why, in discussion with Markus in Chatham in August, I
asked whether some kind of metadata checkin/checkout daemon might not be
an idea, so that each piece of data knew what was happening to the
others. In the same way as with WIND changing in relation to the display,
an external program can't know or update for region changes, and maybe it
should, so that regions stay harmonised. Something like a grassmaster,
that GRASS programs and external programs could ask for appropriate
metadata, to supplement (replace?) files in the present database
structure. This is very unclear, but some mechanism for ensuring coherence
seems to be needed.

Roger

--
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Breiviksveien 40, N-5045 Bergen,
Norway. voice: +47 55 95 93 55; fax +47 55 95 93 93
e-mail: Roger.Bivand@nhh.no
and: Department of Geography and Regional Development, University of
Gdansk, al. Mar. J. Pilsudskiego 46, PL-81 378 Gdynia, Poland.

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

4

On Wed, Feb 28, 2001 at 06:09:49PM +0100, Radim Blazek wrote:

I think that region handling should be changed somehow. But that's task
for g51. My suggestion (not thought over deeply yet) is to distinguish region
used by:
1) modules creating new data
    which would use current region saved in WIND
and
2) monitor + display/query modules
    which would use region stored in memory of monitor.
    Each monitor would have it's own region.

Monitor region would always cover whole area of monitor.

                                    (or frame ...)

New functions could be used for manipulating currend WIND, for example
display WIND on monitor (by rectangle), set WIND to region of selected
monitor, create WIND interactively on monitor, ...

Some problems with one shared region as is used now:
- user cannot rely on current state of monitor, if region was changed for
   a while, d.erase must be run even if region was reset to original size.
- it is impossible to run some script on data and at the same time
   explore maps on monitor (I forgot several times about it and I was very
   surprised why created data are incomplete)
- write access to database is always required even if user want only
   read/explore data.
- (more?)

I'm waiting for your criticism.

More or less sounds like a decent idea. There's the tricky issue of
resolution. Would we calculate resolution based on a scaling from
screen resolution, window extents and mapunit extents? A little tricky
with things like polar wrap around... Anyways, your right to say it
should be later. I work on a little clipping code for d.area so it's
output is "conforming"...

--
Eric G. Miller <egm2@jps.net>

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

5

On Wed, Feb 28, 2001 at 07:34:04PM +0100, Roger Bivand wrote:

This issue also arises in interfacing with other programs in my case
R. This was also why, in discussion with Markus in Chatham in August, I
asked whether some kind of metadata checkin/checkout daemon might not be
an idea, so that each piece of data knew what was happening to the
others. In the same way as with WIND changing in relation to the display,
an external program can't know or update for region changes, and maybe it
should, so that regions stay harmonised. Something like a grassmaster,
that GRASS programs and external programs could ask for appropriate
metadata, to supplement (replace?) files in the present database
structure. This is very unclear, but some mechanism for ensuring coherence
seems to be needed.

Seems like you'd have to have some kind of event-notify scheme for this.
I'm not sure what you mean by checkin/checkout. Are you referring to
some kind of versioning or locking system? A caller would have to
handle a change of state "signal" whenever it occurred. I also think a
general solution for things like saving state data (such a selections)
between program invokations but only for the duration of the session,
would be good. Something to consider for 5.1...

--
Eric G. Miller <egm2@jps.net>

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'