Any thoughts on finally rearranging the raster map storage format soon
after 6.2 is released? (into $MAPSET/raster/$MAPNAME/cell etc)
This will break a lot of modules but it needs to happen some time..
Other queued raster format updates could be done at the same time.
- majorly rewrite the meta-data setup (see previous email)
- Put LZW compression back in?
- Start from scratch using netCDF, XML, or some other newfangled system?
(Glynn, Frank, Andrea?, et al: How horrible or apt is GRASS's raster
format anyway? for a format accessed row by row, is it fairly
nice?)
This needs someone to do it too of course .. as well as necessitate
bumping us up to GRASS 7.0, FWTIW.
But if we decide to do it, we can break it soon after a release and
force everyone to fix things as they want their pet module back
FWIW, I support moving to this kind of organization. Although painful in the
short run, it will make life much easier once implemented.
Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402
From: Hamish <hamish_nospam@yahoo.com>
Date: Mon, 31 Oct 2005 19:32:23 +1300
To: grass5 <grass5@grass.itc.it>
Subject: [GRASS5] raster map file format
Any thoughts on finally rearranging the raster map storage format soon
after 6.2 is released? (into $MAPSET/raster/$MAPNAME/cell etc)
This will break a lot of modules but it needs to happen some time..
Other queued raster format updates could be done at the same time.
- majorly rewrite the meta-data setup (see previous email)
- Put LZW compression back in?
- Start from scratch using netCDF, XML, or some other newfangled system?
(Glynn, Frank, Andrea?, et al: How horrible or apt is GRASS's raster
format anyway? for a format accessed row by row, is it fairly
nice?)
This needs someone to do it too of course .. as well as necessitate
bumping us up to GRASS 7.0, FWTIW.
But if we decide to do it, we can break it soon after a release and
force everyone to fix things as they want their pet module back
Any thoughts on finally rearranging the raster map storage format soon
after 6.2 is released? (into $MAPSET/raster/$MAPNAME/cell etc)
This will break a lot of modules but it needs to happen some time..
Other queued raster format updates could be done at the same time.
- majorly rewrite the meta-data setup (see previous email)
- Put LZW compression back in?
- Start from scratch using netCDF, XML, or some other newfangled system?
(Glynn, Frank, Andrea?, et al: How horrible or apt is GRASS's raster
format anyway? for a format accessed row by row, is it fairly
nice?)
This needs someone to do it too of course .. as well as necessitate
bumping us up to GRASS 7.0, FWTIW.
But if we decide to do it, we can break it soon after a release and
force everyone to fix things as they want their pet module back
thoughts?
Yes, let's do the raster layout modification and go for GRASS 7. Other
things to do
- the parameter/flags cleanup (more consistency)
- virtual raster maps via GDAL
- separation of raster lib (into Rast_*() functions) and G_*() libgis
What about detaching zoom/pan from region settings for digitising?
That could fix crashes (look for them in bug tracking system). Or
maybee just remove digitising from GRASS and make it yet tighter with
qgis?
Or maybee we need new roadmap? New vision for GRASS future. Target
audience, features etc.?
Just my 2c.
Maris Nartiss.
2005/11/3, Markus Neteler <neteler@itc.it>:
Hamish wrote:
>Any thoughts on finally rearranging the raster map storage format soon
>after 6.2 is released? (into $MAPSET/raster/$MAPNAME/cell etc)
>This will break a lot of modules but it needs to happen some time..
>
>Other queued raster format updates could be done at the same time.
> - majorly rewrite the meta-data setup (see previous email)
> - Put LZW compression back in?
> - Start from scratch using netCDF, XML, or some other newfangled system?
> (Glynn, Frank, Andrea?, et al: How horrible or apt is GRASS's raster
> format anyway? for a format accessed row by row, is it fairly
>nice?)
>
>This needs someone to do it too of course .. as well as necessitate
>bumping us up to GRASS 7.0, FWTIW.
>
>But if we decide to do it, we can break it soon after a release and
>force everyone to fix things as they want their pet module back
>
>thoughts?
>
>
Yes, let's do the raster layout modification and go for GRASS 7. Other
things to do
- the parameter/flags cleanup (more consistency)
- virtual raster maps via GDAL
- separation of raster lib (into Rast_*() functions) and G_*() libgis
Zoom is very useful in digitizing--for checking snapping, following fine
features and shifting back to outline areas, etc.
However, it should not change the display region and it should not cause
crashes.
Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402
On Sat, 2005-11-05 at 23:13 -0700, Michael Barton wrote:
Zoom is very useful in digitizing--for checking snapping, following fine
features and shifting back to outline areas, etc.
However, it should not change the display region and it should not
cause crashes.
Michael
Absolutely, that's what I meant. I just want zooming not to change the
initial region resolution, like you. While I find it handy, that the
region extents change along with panning in v.digit.
> From: Maciek Sieczka <werchowyna@epf.pl>
>
> On Thu, 2005-11-03 at 18:39 +0200, Mris Nartis wrote:
>> What about detaching zoom/pan from region settings for digitising?
>
> My point of view on zoom&pan in v.digit vs region settings: pan is a
> helpful feature, zoom is unwanted, annoying feature and the source of
> crashes.
>
> Maciek
--------------------
W polskim Internecie s± setki milionów stron. My przekazujemy Tobie tylko najlepsze z nich! http://katalog.epf.pl/
> Zoom is very useful in digitizing--for checking snapping, following
> fine features and shifting back to outline areas, etc.
> However, it should not change the display region and it should not
> cause crashes.
Absolutely, that's what I meant. I just want zooming not to change the
initial region resolution, like you. While I find it handy, that the
region extents change along with panning in v.digit.
It's not hard to do, in the C code just save the region settings to a
Cell_head struct at startup [G_get_window()] and restore to those on
exit [G_put_window()]. Need to call d.erase or C equiv. at exit then.
see lib/gis/*_window.c for G_get_window(), G_set_window(),
G_put_window() and friends.
That is if v.digit's zoom.c really needs to be using G_put_window() at
all? (G_set.. is local to the module, G_put.. writes to the WIND file)
File a wish if there isn't already one there for it.
I'd like to add, a bit different from what Maciek suggests, that any zooming
OR panning in v.digit should stay in v.digit and have no effect on the
region for display or analysis outside of v.digit.
The last thing I want is to set the region the way I want for display or
analysis, then do some digitizing and have to reset the region again. I
guess I don't see why v.digit should have any effect on the region settings
at all.
Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402
From: Hamish <hamish_nospam@yahoo.com>
Date: Mon, 07 Nov 2005 18:40:08 +1300
To: Maciek Sieczka <werchowyna@epf.pl>
Cc: <michael.barton@asu.edu>, <maris.gis@gmail.com>, <grass5@grass.itc.it>
Subject: Re: [GRASS5] zoom and pan in v.digit (was raster map file format)
Zoom is very useful in digitizing--for checking snapping, following
fine features and shifting back to outline areas, etc.
However, it should not change the display region and it should not
cause crashes.
Absolutely, that's what I meant. I just want zooming not to change the
initial region resolution, like you. While I find it handy, that the
region extents change along with panning in v.digit.
It's not hard to do, in the C code just save the region settings to a
Cell_head struct at startup [G_get_window()] and restore to those on
exit [G_put_window()]. Need to call d.erase or C equiv. at exit then.
see lib/gis/*_window.c for G_get_window(), G_set_window(),
G_put_window() and friends.
That is if v.digit's zoom.c really needs to be using G_put_window() at
all? (G_set.. is local to the module, G_put.. writes to the WIND file)
File a wish if there isn't already one there for it.
I'd like to add, a bit different from what Maciek suggests, that any zooming
OR panning in v.digit should stay in v.digit and have no effect on the
region for display or analysis outside of v.digit.
v.digit does this so that any external commands which it invokes use
the same region settings as v.digit.
AFAICT, there are two cases, both in display.c:
1. display_bg() executes a sequence of user-specified commands to draw
the background.
2. display_erase() executes d.erase to erase the background.
The second is gratuitous; it should just erase the background itself.
However, there's no getting around the former; the only way to make an
external command use a specific region is to modify the WIND file.
One option is to save the WIND file prior to executing the commands
then restore them afterwards.
Another option would be to modify G_get_window() so that you can force
it to read a different file by using an environment variable. Then,
v.digit could write the modified region to a temporary file and force
the background commands to use that via the environment variable.
In either case, the auto-redraw feature won't work, as the commands
will get the normal region rather than v.digit's internal version.
Given what you've said, I don't see any way of realistically getting around
the issue of background zoom either, given the tools at hand.
I guess trying to deal with the reported crashes (I haven't had problems but
haven't used it much) and the need to restart a line when panning/zooming
(this is important) are bigger priorities.
Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402
From: Glynn Clements <glynn@gclements.plus.com>
Date: Mon, 07 Nov 2005 21:11:23 +0000
To: Michael Barton <michael.barton@asu.edu>
Cc: <grass5@grass.itc.it>
Subject: Re: [GRASS5] zoom and pan in v.digit (was raster map file format)
Michael Barton wrote:
I'd like to add, a bit different from what Maciek suggests, that any zooming
OR panning in v.digit should stay in v.digit and have no effect on the
region for display or analysis outside of v.digit.
v.digit does this so that any external commands which it invokes use
the same region settings as v.digit.
AFAICT, there are two cases, both in display.c:
1. display_bg() executes a sequence of user-specified commands to draw
the background.
2. display_erase() executes d.erase to erase the background.
The second is gratuitous; it should just erase the background itself.
However, there's no getting around the former; the only way to make an
external command use a specific region is to modify the WIND file.
One option is to save the WIND file prior to executing the commands
then restore them afterwards.
Another option would be to modify G_get_window() so that you can force
it to read a different file by using an environment variable. Then,
v.digit could write the modified region to a temporary file and force
the background commands to use that via the environment variable.
In either case, the auto-redraw feature won't work, as the commands
will get the normal region rather than v.digit's internal version.
How about introducing a "stack of WIND settings" from which you can pop
previous settings and push new settings, and maybe select them from a list?
Then, assuming d.view.pop and d.view.push commands, not only v.digit could
push on entering and popping on leaving, but I guess other users/scripts would
benefit.
It would be just a kind of versioning system for the WIND file, wouldn't it?
-- Daniel Calvelo Aros
---------- Original Message -----------
From: Glynn Clements <glynn@gclements.plus.com>
To: Michael Barton <michael.barton@asu.edu>
Cc: grass5@grass.itc.it
Sent: Mon, 7 Nov 2005 21:11:23 +0000
Subject: Re: [GRASS5] zoom and pan in v.digit (was raster map file format)
Michael Barton wrote:
> I'd like to add, a bit different from what Maciek suggests, that any zooming
> OR panning in v.digit should stay in v.digit and have no effect on the
> region for display or analysis outside of v.digit.
v.digit does this so that any external commands which it invokes use
the same region settings as v.digit.
AFAICT, there are two cases, both in display.c:
1. display_bg() executes a sequence of user-specified commands to
draw the background.
2. display_erase() executes d.erase to erase the background.
The second is gratuitous; it should just erase the background itself.
However, there's no getting around the former; the only way to make
an external command use a specific region is to modify the WIND file.
One option is to save the WIND file prior to executing the commands
then restore them afterwards.
Another option would be to modify G_get_window() so that you can
force it to read a different file by using an environment variable.
Then,
v.digit could write the modified region to a temporary file and
force the background commands to use that via the environment variable.
In either case, the auto-redraw feature won't work, as the commands
will get the normal region rather than v.digit's internal version.
Sounds interesting, though I have no idea what would be involved
programming-wise.
Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402
From: Daniel Calvelo Aros <dcalvelo@minag.gob.pe>
Reply-To: <daniel.calvelo@minag.gob.pe>
Date: Mon, 07 Nov 2005 22:32:22 -0500
To: Glynn Clements <glynn@gclements.plus.com>, Michael Barton
<michael.barton@asu.edu>
Cc: <grass5@grass.itc.it>
Subject: Re: [GRASS5] zoom and pan in v.digit (was raster map file format)
How about introducing a "stack of WIND settings" from which you can pop
previous settings and push new settings, and maybe select them from a list?
Then, assuming d.view.pop and d.view.push commands, not only v.digit could
push on entering and popping on leaving, but I guess other users/scripts would
benefit.
It would be just a kind of versioning system for the WIND file, wouldn't it?
-- Daniel Calvelo Aros
---------- Original Message -----------
From: Glynn Clements <glynn@gclements.plus.com>
To: Michael Barton <michael.barton@asu.edu>
Cc: grass5@grass.itc.it
Sent: Mon, 7 Nov 2005 21:11:23 +0000
Subject: Re: [GRASS5] zoom and pan in v.digit (was raster map file format)
Michael Barton wrote:
I'd like to add, a bit different from what Maciek suggests, that any zooming
OR panning in v.digit should stay in v.digit and have no effect on the
region for display or analysis outside of v.digit.
v.digit does this so that any external commands which it invokes use
the same region settings as v.digit.
AFAICT, there are two cases, both in display.c:
1. display_bg() executes a sequence of user-specified commands to
draw the background.
2. display_erase() executes d.erase to erase the background.
The second is gratuitous; it should just erase the background itself.
However, there's no getting around the former; the only way to make
an external command use a specific region is to modify the WIND file.
One option is to save the WIND file prior to executing the commands
then restore them afterwards.
Another option would be to modify G_get_window() so that you can
force it to read a different file by using an environment variable.
Then,
v.digit could write the modified region to a temporary file and
force the background commands to use that via the environment variable.
In either case, the auto-redraw feature won't work, as the commands
will get the normal region rather than v.digit's internal version.
How about introducing a "stack of WIND settings" from which you can
pop previous settings and push new settings, and maybe select them
from a list? Then, assuming d.view.pop and d.view.push commands, not
only v.digit could push on entering and popping on leaving, but I
guess other users/scripts would benefit.
It would be just a kind of versioning system for the WIND file,
wouldn't it?
How about introducing a "stack of WIND settings" from which you can pop
previous settings and push new settings, and maybe select them from a list?
Then, assuming d.view.pop and d.view.push commands, not only v.digit could
push on entering and popping on leaving, but I guess other users/scripts would
benefit.
It would be just a kind of versioning system for the WIND file, wouldn't it?
You can already save and load named regions using g.region's save= and
region= options.
It would be simpler for v.region to do it itself, though.
as well as necessitate
as well as necessitate