As `zoom=' somewhat mimics `rast=', wouldn't it be natural to
extend `zoom=' to allow multiple rasters?
Allowing multiple rasters for `zoom=' may make one wonder about
some further extensions. Firstly, wouldn't it be useful to
allow both `rast=' and `zoom=' be specified at the same time to
calculate the least region covering both the `rast=' and `zoom='
rasters (with the usual `rast=' and `zoom=' behaviour still
followed)? What about adding `vect=' and `region=' as well?
Secondly, the above extensions make it easy to compute set union
(or rather its boundary box) of the regions (specified as named
regions, rasters or vectors), but it seems to be useful to allow
one to calculate set intersection as well. Hence,
`mode=intersect' as a counterpart to the default `mode=union'
(or `mode=traditional'?)
Please note that the last change is somewhat disturbing to the
existing code, since the result of the intersection may well be
an empty region, while AFAIK there's no conception of empty
region in GRASS currently.
Ivan Shmakov pisze:
What about adding `vect=' and `region=' as well?
Talking about g.region vect= - I'd find it very usefull if it honored the 3d vector coordinates too. Currently one has to set top and bottom manually in accordance with his 3d vector.
Maciek
"MS" == Maciej Sieczka <tutey@o2.pl> writes:
>> What about adding `vect=' and `region=' as well?
> Talking about g.region vect= - I'd find it very usefull if it honored
> the 3d vector coordinates too. Currently one has to set top and
> bottom manually in accordance with his 3d vector.
Do you mean something like the following?
--- general/g.region/main.c.~2~ 2008-04-02 01:11:59.000000000 +0700
+++ general/g.region/main.c 2008-04-02 11:15:40.000000000 +0700
@@ -515,6 +515,8 @@
map_window.south = box.S;
map_window.west = box.W;
map_window.east = box.E;
+ map_window.top = box.T;
+ map_window.bottom = box.B;
if (!first)
{
@@ -531,6 +533,10 @@
window.east : map_window.east;
window.west = (window.west < map_window.west) ?
window.west : map_window.west;
+ if (map_window.top > window.top)
+ window.top = map_window.top;
+ if (map_window.bottom < window.bottom)
+ window.bottom = map_window.bottom;
}
if(window.north == window.south)
@@ -543,6 +549,12 @@
window.west = window.west - 0.5 * temp_window.ew_res;
window.east = window.east + 0.5 * temp_window.ew_res;
}
+ if (window.top == window.bottom) {
+ window.bottom = (window.bottom
+ - 0.5 * temp_window.tb_res);
+ window.top = (window.top
+ + 0.5 * temp_window.tb_res);
+ }
if(flag.res_set->answer)
G_align_window (&window, &temp_window);
Ivan Shmakov <ivan@theory.asu.ru> writes:
Maciej Sieczka <tutey@o2.pl> writes:
>> Talking about g.region vect= - I'd find it very usefull if it
>> honored the 3d vector coordinates too. Currently one has to set top
>> and bottom manually in accordance with his 3d vector.
> Do you mean something like the following?
> --- general/g.region/main.c.~2~ 2008-04-02 01:11:59.000000000 +0700
> +++ general/g.region/main.c 2008-04-02 11:15:40.000000000 +0700
> @@ -515,6 +515,8 @@
> map_window.south = box.S;
> map_window.west = box.W;
> map_window.east = box.E;
> + map_window.top = box.T;
> + map_window.bottom = box.B;
> if (!first)
> {
[...]
BTW, I'm not familiar with either 3D-vectors or 3D-rasters, so
could someone with a better knowledge of them test this (and
possibly the other [1]) patch? Or should I put it to Trac?
[1] http://permalink.gmane.org/gmane.comp.gis.grass.devel/26185
Ivan Shmakov <ivan@theory.asu.ru> writes:
Ivan Shmakov <ivan@theory.asu.ru> writes:
Maciej Sieczka <tutey@o2.pl> writes:
>>> Talking about g.region vect= - I'd find it very usefull if it
>>> honored the 3d vector coordinates too. Currently one has to set top
>>> and bottom manually in accordance with his 3d vector.
>> Do you mean something like the following?
[...]
> BTW, I'm not familiar with either 3D-vectors or 3D-rasters, so could
> someone with a better knowledge of them test this (and possibly the
> other [1]) patch? Or should I put it to Trac?
> [1] http://permalink.gmane.org/gmane.comp.gis.grass.devel/26185
I have opened a ticket [1] for the issue.
[1] http://trac.osgeo.org/grass/ticket/121