#1838: r.mask: allow use of vector map as input
-------------------------+--------------------------------------------------
Reporter: mlennert | Owner: grass-dev@…
Type: enhancement | Status: new
Priority: normal | Milestone: 7.0.0
Component: Raster | Version: svn-trunk
Keywords: mask vector | Platform: Unspecified
Cpu: Unspecified |
-------------------------+--------------------------------------------------
A wish coming regularly from my students: it would be nice if r.mask
accepted a vector map as input.
#1838: r.mask: allow use of vector map as input
----------------------------------+-----------------------------------------
Reporter: mlennert | Owner: grass-dev@…
Type: enhancement | Status: new
Priority: normal | Milestone: 7.0.0
Component: Raster | Version: svn-trunk
Keywords: mask, vector, r.mask | Platform: Unspecified
Cpu: Unspecified |
----------------------------------+-----------------------------------------
Comment(by mmetz):
Replying to [comment:1 neteler]:
> Sounds very reasonable. Maybe they can develop the method? It will
include
> (perhaps) SQL select option and column selection, then the
rasterization...
`r.mask` got new `vector`, `layer`, `cats`, and `where` options in r54302.
The `input` option has been renamed to `raster`.
If you want to create a MASK from a raster map, you now need to set the
raster option. If you want to create a MASK from a vector map, you now
need to set the vector option. Only vector areas will be considered for
creating a MASK from a vector.
When a MASK is created from a raster, the extents and resolution of the
raster map are used because r.reclass is used (that's the unchanged
default behaviour as in GRASS 6), but when a MASK is created from a
vector, the current region settings are used.
One wish tho for next release. r.mask should be able to accept multiple
vectors. For example what if I want to create a mask using the costline
AND lakes shapefile?
Replying to [comment:2 mmetz]:
> Replying to [comment:1 neteler]:
> > Sounds very reasonable. Maybe they can develop the method? It will
include
> > (perhaps) SQL select option and column selection, then the
rasterization...
>
> `r.mask` got new `vector`, `layer`, `cats`, and `where` options in
r54302. The `input` option has been renamed to `raster`.
..
> When a MASK is created from a raster, the extents and resolution of the
raster map are used because r.reclass is used (that's the unchanged
default behaviour as in GRASS 6), but when a MASK is created from a
vector, the current region settings are used.
Thanks!
Nevertheless, currently, if the region extent doesn't match, the produced
raster MASK is empty. Manually, I need to extract the vector features of
my interest (`v.extract`), set the region (`g.region vect=`) and then use
`r.mask` along with the `vector=` option.
Would it be easy to make the region adjustment, when using a vector,
automatic? Even if the user supplies an where="SQL clause"? If this action
is not difficult to code, are there reasons for a user he would not want
to match (at least) the region extent to the queried vector map?
I need to integrate in a script this exact operation (hardcoded example
here, the idea is to support scripting of course):
{{{
r.mask vect=wrs2_descending where="PATH=161 and ROW=076"
}}}
One reason a user would not want to match the region extent to the queried
vector map could be that he/she is only interested in an area that partly
overlaps with the vector map, with polygons falling only partly within the
region. This still works with our suggestion, but only if the region is
set back to the initial one after the mask is created I guess.
Replying to [comment:6 pvanbosgeo]:
> One reason a user would not want to match the region extent to the
queried vector map could be that he/she is only interested in an area that
partly overlaps with the vector map, with polygons falling only partly
within the region. This still works with our suggestion, but only if the
region is set back to the initial one after the mask is created I guess.
If a user is interested in an area that partly overlaps with the vector
map, he doesn't really want to
{{{
r.mask vector=SomeVector
}}}
He rather needs to manually find the area of interest that will become a
MASK. This sounds as an exception, rather than a general rule. What do
you think?
To be honest, I find it hard to justify not running `v.to.rast` + r.mask
as a two step process. You either respect the current region setting, or
the v.to.rast operation is partially undefined. Having the module change
the region (and if so, internally, via WIND_OVERRIDE & the
grass.use_temp_region() python function) for any reason seems like a
slight misfeature to me.
Consider the case that the vector is much larger than the raster (national
coastline, I'm offen making coastal "land.mask" rasters from that), you
wouldn't want to rasterize the entire country at the current raster
resolution. Of course it's possible to only shrink the region with a
little scripting work, and it could be a nice efficiency trick to do that,
but be careful that the logic for it might fail for lat/lon near the
dateline)
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.
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.
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.
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.
···
On Mon, May 20, 2013 at 3:15 PM, GRASS GIS <trac@osgeo.org> wrote:
One reason a user would not want to match the region extent to the
queried vector map could be that he/she is only interested in an area that
partly overlaps with the vector map, with polygons falling only partly
within the region. This still works with our suggestion, but only if the
region is set back to the initial one after the mask is created I guess.
If a user is interested in an area that partly overlaps with the vector
map, he doesn’t really want to
{{{
r.mask vector=SomeVector
}}}
He rather needs to manually find the area of interest that will become a
MASK. This sounds as an exception, rather than a general rule. What do
you think?
To be honest, I find it hard to justify not running v.to.rast + r.mask
as a two step process. You either respect the current region setting, or
the v.to.rast operation is partially undefined. Having the module change
the region (and if so, internally, via WIND_OVERRIDE & the
grass.use_temp_region() python function) for any reason seems like a
slight misfeature to me.
Consider the case that the vector is much larger than the raster (national
coastline, I’m offen making coastal “land.mask” rasters from that), you
wouldn’t want to rasterize the entire country at the current raster
resolution. Of course it’s possible to only shrink the region with a
little scripting work, and it could be a nice efficiency trick to do that,
but be careful that the logic for it might fail for lat/lon near the
dateline)
O-K, I see. So, not even a flag "-v" that will work *only* when a
"vector=" and will obtain the bounding box coordinates of the queried
vector map/feature(s)?
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...
So the question is: I need to MASK that vector feature(s) out
(or in)
from my raster processing workflow: So I'll MASK'em. Intuitively, but maybe
now
maybe _not_ wise
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.
Replying to [comment:9 nikosa]:
> O-K, I see. So, not even a flag "-v" that will work *only* when a
"vector=" and will obtain the bounding box coordinates of the queried
vector map/feature(s)?
-1
As the others, I do not think that setting region and mask should be mixed
in one single module. They are two different things.