it lets you use v.what.rast for centroids as well as points.
I have made a (100m) buffer around a number of points, and in addition to
the raster stats for the buffer provided by v.rast.stats I want to know
the exact value at the center point (field sampling station). In this
case my centroid is exactly in the middle of the area so it's ok. I'm not
so sure that this patch is useful when the centroid is randomly placed
within the area, hence this email. Then again the result is actually
uploaded to the centroid, not the area, so maybe all-correct just
sometimes requires a grain of salt in the interpretation.
???
Another issue touched by a recent thread* re. bounding boxes of features
within a vector map: v.rast.stats is VERY slow. This is because it creates
a r.mapcalc MASK at the full raster region resolution for each cat it
processes. When picking out small vector buffers from a large raster this
is highly inefficient. It would be much better to find the bounding box
of each selected vector cat, zoom in on it with the GRASS_REGION or
WIND_OVERRIDE enviro variables for the duration of the r.mapcalc and
r.univar calls for each cat.
I would be cool to have a C module which could do 'v.info -g' bounds for
cats=1,3,5-9,13 &/or where='SQL query'. ??
Hamish
ps- r.category label setting updates are mostly done, it just needs some
cleaning. I expect it will need more testing and debugging than most
changes as the labeling lib fns are very dusty.
On 10/9/07 5:42 AM, "Hamish" <hamish_nospam@yahoo.com> wrote:
Hi,
any comments re. the following patch?
it lets you use v.what.rast for centroids as well as points.
I have made a (100m) buffer around a number of points, and in addition to
the raster stats for the buffer provided by v.rast.stats I want to know
the exact value at the center point (field sampling station). In this
case my centroid is exactly in the middle of the area so it's ok. I'm not
so sure that this patch is useful when the centroid is randomly placed
within the area, hence this email. Then again the result is actually
uploaded to the centroid, not the area, so maybe all-correct just
sometimes requires a grain of salt in the interpretation.
This brings up an issue that we might want to think about for GRASS 7.
Currently, centroids must always be created manually to transform a closed
polyline into an area. While we might want to keep this as an option (but
maybe not), I think it would be better to have some kind of 'area-creation'
utility that would transform a close polyline into an area by automatically
adding a centroid at a predefined center location (geometric center or other
measure) and adding a cat value. Then analytical utilities like you are
discussing here could be more reliable.
Another issue touched by a recent thread* re. bounding boxes of features
within a vector map: v.rast.stats is VERY slow. This is because it creates
a r.mapcalc MASK at the full raster region resolution for each cat it
processes. When picking out small vector buffers from a large raster this
is highly inefficient. It would be much better to find the bounding box
of each selected vector cat, zoom in on it with the GRASS_REGION or
WIND_OVERRIDE enviro variables for the duration of the r.mapcalc and
r.univar calls for each cat.
I would be cool to have a C module which could do 'v.info -g' bounds for
cats=1,3,5-9,13 &/or where='SQL query'. ??
Hamish
ps- r.category label setting updates are mostly done, it just needs some
cleaning. I expect it will need more testing and debugging than most
changes as the labeling lib fns are very dusty.
Just want to say thanks for these new extensions to r.cat -> r.category.
Michael
__________________________________________
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University
This brings up an issue that we might want to think about for GRASS 7.
Currently, centroids must always be created manually to transform a
closed polyline into an area. While we might want to keep this as an
option (but maybe not), I think it would be better to have some kind of
'area-creation' utility that would transform a close polyline into an
area by automatically adding a centroid at a predefined center location
(geometric center or other measure) and adding a cat value. Then
analytical utilities like you are discussing here could be more
reliable.
(v.type + v.centroids)
I don't think you can convert automatically all closed boundaries as
some of the closed boundaries may be islands/holes within an area, and
you risk turning them into positives.
This brings up an issue that we might want to think about for GRASS 7.
Currently, centroids must always be created manually to transform a
closed polyline into an area. While we might want to keep this as an
option (but maybe not), I think it would be better to have some kind of
'area-creation' utility that would transform a close polyline into an
area by automatically adding a centroid at a predefined center location
(geometric center or other measure) and adding a cat value. Then
analytical utilities like you are discussing here could be more
reliable.
(v.type + v.centroids)
I don't think you can convert automatically all closed boundaries as
some of the closed boundaries may be islands/holes within an area, and
you risk turning them into positives.
I agree with Hamish, however, I think it might be worth considering that
we could have 2 new area creation buttons: "create area" and "create
island/hole" That could make it easier for the new user to start with
digitizing in GRASS. An advanced user would maybe choose to use the
"draw boundary" and "draw centroid" buttons, which would sit there next
to the new area drawing buttons. The purpose of the GUI is after all to
make it easier/friendlier to operate GRASS.
I was thinking more along the lines of something where you specified a set
of vector features (cat=... or where=...), clicked run and after a check to
make sure they are closed polylines it would add a central centroid and make
them areas.
Michael
On 10/10/07 12:11 AM, "Hamish" <hamish_nospam@yahoo.com> wrote:
Michael Barton wrote:
This brings up an issue that we might want to think about for GRASS 7.
Currently, centroids must always be created manually to transform a
closed polyline into an area. While we might want to keep this as an
option (but maybe not), I think it would be better to have some kind of
'area-creation' utility that would transform a close polyline into an
area by automatically adding a centroid at a predefined center location
(geometric center or other measure) and adding a cat value. Then
analytical utilities like you are discussing here could be more
reliable.
(v.type + v.centroids)
I don't think you can convert automatically all closed boundaries as
some of the closed boundaries may be islands/holes within an area, and
you risk turning them into positives.
Hamish
__________________________________________
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University