Paulo van Breugel wrote: Hi Paulo!
> If you have a vector layer with (some) polygons that occur partly within > the region of interest, finding the area that should become a mask means in > that case spitting the polygon(s). Yes, of course you could do that, but > you can equally well (easier in fact) set the region to match your vector > layer (or the region of interest) manually. I don't really understand the above. > An exception? I don't know, each user will use the functions available in a > different way. I personally would prefer the current implementation, or > more in general, to avoid functions to set the region automatically. In my > opinion that better fits the general work flow in GRASS: the user > explicitly sets the region, and functions operate on that region. Sure, I agree. > On the other hand, r.mask with a raster as input is an exception as > mentioned already mentioned, and one could argue that it is better to have > the same behaviour both when using raster or vector as input. My idea comes from what (I maybe wrongly consider as a fact) the r.mask module is used for: a user wants to use a MASK in order to filter out (or in) cells while processing raster data. So the question is: I need to MASK that vector feature(s) out from my raster processing workflow: So I'll MASK'em. Intuitively, but maybe now wise as you and Hamish note, a user could simply say: r.mask vector=VectorMap where="Some SQL statement" and the module will set-up for him/her a MASK based on what he/her expects. > It is important thought that r.mask does not change the region if you use > raster as input, and that is something I really think should remain the > case when using a vector as input. That means that even if you would > implement the suggestion above, adjusting the region to the extend of the > vector layer before creating the mask, that region should be set back to > the initial extend after the mask is created. Yes, of course the *current region settings* should be respected. Anyway, thank you for your time answering/commenting. It's just an idea that might make life easier... if... Thanks, Nikos _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev