[GRASS-user] GRASS63cvs v.rast.stats reports zero for many CATs

GRASS GRASS user
1

Fellow GRASSers -

I am using GRASS 6.3 cvs, the Kynge’s build, and I have an issue using v.rast.stats on a raster of slope. Many (n>100) of my archaeological sites, which are all polygons, produced 9 columns of zeros for the slope stat calculations. I repeated the exercise, using different column names, and it repeated the results.

The oddest part is that I successfully calculated elevation stats from a DEM raster using the same v.rast.stats command. The slope raster was produced directly from the DEM, so resolution, etc. are exactly the same.

I investigated some of the polys that were missing slope information, and indeed, the raster is completely intact in the area of these polygons, with values other than zero, and the polygon itself is clean.

In attempting to do the same calculations with my aspect raster, there were also many sites where the aspect calculation resulted in 0 (for both of these, even the ‘n’ field, number of cells, is 0). These sites were not always the same as the ones that had slope calculations of zeros!

I am running the stat calculations with slope again, after cleaning the vector file, but I still am not optimistic that this will help since my v.rast.stats calculations on elevation were successful where the slope ones were not.

Also, it takes about 7 hours to calculate the stats for my 893 polygons (16 meter grid resolution probably has something to do with it, but wanted to make sure this isn’t a fixable thing).

I tried searching the user list, but found nothing related to this problem with v.rast.stats.
Thanks all,
Brandon

Brandon M. Gabler
Doctoral Candidate
Department of Anthropology
University of Arizona
Tucson, AZ 85721
Phone: (520) 621-8455
Fax: (520) 621-2088
bgabler@email.arizona.edu

“Who? When? Whither? are the questions with which the archaeologist challenges the refuse heaps, scattered potsherds, and broken shafts, to tell of the builders who came and lived and went their way into the templed past.” – Edgar Lee Hewett, in Pajarito Plateau and its Ancient People, 1938

2

On Friday 06 April 2007 13:36, Brandon M. Gabler wrote:

Fellow GRASSers -

I am using GRASS 6.3 cvs, the Kynge's build, and I have an issue
using v.rast.stats on a raster of slope. Many (n>100) of my
archaeological sites, which are all polygons, produced 9 columns of
zeros for the slope stat calculations. I repeated the exercise, using
different column names, and it repeated the results.

The oddest part is that I successfully calculated elevation stats
from a DEM raster using the same v.rast.stats command. The slope
raster was produced directly from the DEM, so resolution, etc. are
exactly the same.

Hi,

r.slope.aspect will create maps with null-cells in some cases- this is a
feature not a bug, see the manual page. Perhaps the input DEM did not have
any null cells at these areas, and thus had good results from the trouble
areas...

I investigated some of the polys that were missing slope information,
and indeed, the raster is completely intact in the area of these
polygons, with values other than zero, and the polygon itself is clean.

were there any null cells?

In attempting to do the same calculations with my aspect raster,
there were also many sites where the aspect calculation resulted in 0
(for both of these, even the 'n' field, number of cells, is 0). These
sites were not always the same as the ones that had slope
calculations of zeros!

I am running the stat calculations with slope again, after cleaning
the vector file, but I still am not optimistic that this will help
since my v.rast.stats calculations on elevation were successful where
the slope ones were not.

Also, it takes about 7 hours to calculate the stats for my 893
polygons (16 meter grid resolution probably has something to do with
it, but wanted to make sure this isn't a fixable thing).

While there are some solutions to the general problem of 'zonal statistics' in
GRASS, I tend to use the 'starspan' application for these operations. It is
VERY fast, and has been used in numerous papers. It can directly read GRASS
raster and vector data, which is a definite plus.

google starspan for some ideas. also- matt perry's blog has some examples if I
am not mistaken.

cheers,

--
Dylan Beaudette
Soils and Biogeochemistry Graduate Group
University of California at Davis
530.754.7341

3

Thanks Dylan, I will check out starspan for future work!

Also, there were no null cells, at least in the vicinity of the vectors that had
reported zeros. So I suspect that is not the issue. I don't know if that changes
anything, but such is life.

Thanks again,
Brandon
--
Brandon M. Gabler
Research Associate
Department of Anthropology
1009 E South Campus Drive, Building #30A
University of Arizona
Tucson, AZ 85721
Phone: 520-621-8455
Fax: 520-621-2088

Quoting Dylan Beaudette <dylan.beaudette@gmail.com>:

On Friday 06 April 2007 13:36, Brandon M. Gabler wrote:

Fellow GRASSers -

I am using GRASS 6.3 cvs, the Kynge's build, and I have an issue
using v.rast.stats on a raster of slope. Many (n>100) of my
archaeological sites, which are all polygons, produced 9 columns of
zeros for the slope stat calculations. I repeated the exercise, using
different column names, and it repeated the results.

The oddest part is that I successfully calculated elevation stats
from a DEM raster using the same v.rast.stats command. The slope
raster was produced directly from the DEM, so resolution, etc. are
exactly the same.

Hi,

r.slope.aspect will create maps with null-cells in some cases- this is a
feature not a bug, see the manual page. Perhaps the input DEM did not have
any null cells at these areas, and thus had good results from the trouble
areas...

I investigated some of the polys that were missing slope information,
and indeed, the raster is completely intact in the area of these
polygons, with values other than zero, and the polygon itself is clean.

were there any null cells?

In attempting to do the same calculations with my aspect raster,
there were also many sites where the aspect calculation resulted in 0
(for both of these, even the 'n' field, number of cells, is 0). These
sites were not always the same as the ones that had slope
calculations of zeros!

I am running the stat calculations with slope again, after cleaning
the vector file, but I still am not optimistic that this will help
since my v.rast.stats calculations on elevation were successful where
the slope ones were not.

Also, it takes about 7 hours to calculate the stats for my 893
polygons (16 meter grid resolution probably has something to do with
it, but wanted to make sure this isn't a fixable thing).

While there are some solutions to the general problem of 'zonal statistics' in
GRASS, I tend to use the 'starspan' application for these operations. It is
VERY fast, and has been used in numerous papers. It can directly read GRASS
raster and vector data, which is a definite plus.

google starspan for some ideas. also- matt perry's blog has some examples if I
am not mistaken.

cheers,

--
Dylan Beaudette
Soils and Biogeochemistry Graduate Group
University of California at Davis
530.754.7341

4

On 4/6/07, Dylan Beaudette <dylan.beaudette@gmail.com> wrote:

While there are some solutions to the general problem of ‘zonal statistics’ in
GRASS, I tend to use the ‘starspan’ application for these operations. It is
VERY fast, and has been used in numerous papers. It can directly read GRASS
raster and vector data, which is a definite plus.

google starspan for some ideas. also- matt perry’s blog has some examples if I
am not mistaken.

The post on starspan can be found here:
http://www.perrygeo.net/wordpress/?p=30

–
Matthew T. Perry
http://www.perrygeo.net

5

Dylan Beaudette wrote:

On Friday 06 April 2007 13:36, Brandon M. Gabler wrote:

Fellow GRASSers -

I am using GRASS 6.3 cvs, the Kynge's build, and I have an issue
using v.rast.stats on a raster of slope. Many (n>100) of my
archaeological sites, which are all polygons, produced 9 columns of
zeros for the slope stat calculations.

Can you provide a GRASS location containing the data necessary to
reproduce your problem, and the exact v.rats.stats command? Otherwise
it's hard to say what could be the problem.

The oddest part is that I successfully calculated elevation stats
from a DEM raster using the same v.rast.stats command. The slope
raster was produced directly from the DEM, so resolution, etc. are
exactly the same.

Is it possible that the slope raster has really small values at these
locations, ie. with numbers after 10th decimal place? There is a note
in the v.rast.stats (it's a shell script), line 165:

#check if DBF driver used, in this case cut to 10 chars col names:

Propably Markus (script author) can explain why this is necessary.

Maciek

6

Thank you for the tips, Maciej,

On a hunch, prior to your email, I did re-try the exercise with a shorter prefix (s16 instead of slope16), and this solved the problem. I think column width may have been the problem. I had inspected the values at those locations, and they had normal slopes (7, 6, or 9 degrees, etc.).

Curious problem, solved thanks to suggstions from the grasslist as always!
Brandon

On Apr 7, 2007, at 5:24 AM, Maciej Sieczka wrote:

Dylan Beaudette wrote:

On Friday 06 April 2007 13:36, Brandon M. Gabler wrote:

Fellow GRASSers -

I am using GRASS 6.3 cvs, the Kynge's build, and I have an issue
using v.rast.stats on a raster of slope. Many (n>100) of my
archaeological sites, which are all polygons, produced 9 columns of
zeros for the slope stat calculations.

Can you provide a GRASS location containing the data necessary to
reproduce your problem, and the exact v.rats.stats command? Otherwise
it's hard to say what could be the problem.

The oddest part is that I successfully calculated elevation stats
from a DEM raster using the same v.rast.stats command. The slope
raster was produced directly from the DEM, so resolution, etc. are
exactly the same.

Is it possible that the slope raster has really small values at these
locations, ie. with numbers after 10th decimal place? There is a note
in the v.rast.stats (it's a shell script), line 165:

#check if DBF driver used, in this case cut to 10 chars col names:

Propably Markus (script author) can explain why this is necessary.

Maciek

7

On Sat, Apr 07, 2007 at 02:24:30PM +0200, Maciej Sieczka wrote:
...

Is it possible that the slope raster has really small values at these
locations, ie. with numbers after 10th decimal place? There is a note
in the v.rast.stats (it's a shell script), line 165:

#check if DBF driver used, in this case cut to 10 chars col names:

Propably Markus (script author) can explain why this is necessary.

Necessary, but not desired :slight_smile: The problem is the 10 chars
limitation in the DBF specifications, at least in the implementation
which we use (OGR/SHAPELIB). You cannot have longer column names in DBF.

Solution: Use SQLite instead (doesn't need a server). See
g.manual grass-sqlite
for details. I just see that it explains how to create the SQLite DB...
This isn't needed as GRASS will do it for you automatically! Will
change (simplify) the docs now. You just create a new mapset and
then run

db.connect driver=sqlite database='$GISDBASE/$LOCATION_NAME/$MAPSET/sqlite.db'
db.connect -p
db.tables -p
# of course there is no table yet

Then run
g.copy vect=oldmap,newmap
and everything is converted. Then v.rast.stats again...

cheers
Markus

8

Markus Neteler wrote:

On Sat, Apr 07, 2007 at 02:24:30PM +0200, Maciej Sieczka wrote:
...

Is it possible that the slope raster has really small values at these
locations, ie. with numbers after 10th decimal place? There is a note
in the v.rast.stats (it's a shell script), line 165:

#check if DBF driver used, in this case cut to 10 chars col names:

Propably Markus (script author) can explain why this is necessary.

Necessary, but not desired :slight_smile: The problem is the 10 chars
limitation in the DBF specifications, at least in the implementation
which we use (OGR/SHAPELIB). You cannot have longer column names in DBF.

Markus,

Forgive me. This was a dumb question. First of all, the column *name*
lenght is not relevant here (in error I interpreted that v.rast.stats
script trims the column fields lenght, not the column name lenght).
Secondly, the 10 chars column name limit is documeneted in "SQL support
in GRASS GIS" section of GRASS manual.

Brandon,

In order to be able to say what could be the real reason of your
problem, please provide data and info necessary to reproduce it.

Maciek