This is less of a science question and more of an accounting question, done within grids. I’m trying to think of a fast way to do this.

I have a nearly global grid with 0.25° resolution. The grid cell values consists of counts.

What I’d like to form is a grid of the sums of 3x3 cells (center cell, plus 8 surrounding cells). Can grdmath do something like this quickly?

No. But grdfilter can. Just make a 3x3 grid with ones and us it as a custom operator in -Fo.

1 Like

Thanks, Paul. 20 minutes ago, I just read about grdfilter, but couldn’t quite piece it together. Great suggestion!

Not having quite the success I had hoped for. I created a 3x3 grid of all 1’s using:

`gmt grdmath -R-1/1/-1/1 -I1 1 = tfil.grd`

And then applied it in grdfilter:

`gmt grdfilter tg2.grd -Fotfil.grd -D0 -Gtg2a.grd`

but only got zeros back in tg2a.grd. What other part did I miss?

Two issues, unfortunately:

- It should be -Ff not -Fo. f is a custom filter (your case), while o is an operator (coefficients must sum to zero)
- There was a bug in grdfilter so when -Ff|o was used the weights were replaced with zeros…

I have submitted a PR.

Thanks, Paul. I had been trying to interpret the line in the man page, for the -Fo option that went:

Weights are assumed to sum to zero so no accumulation of weight sums and normalization will be done.

I also tried it with -Ff as well, but only got NaNs back.

Thank you for submitting the PR. I’ll stand by!

Yes, the -Ff also summed up with zero weights but also divided by the weight sum of zero, giving NaN…

An alternative is to `grd2xyz ... | blockmean ... `

Yes, with -Ss, but now you only get output every 3.

Fix now merged in master.

Can it be downloaded via git? Or does it need a little more time?

Using the -Ff option, I get non-NaN values, but they’re not a sum of the center cell with those surrounding it.

I wasn’t sure what these values were, but then I figured out that they are the mean value of the center plus surrounding eight cells. Simply multiply by 9, and the counts needed are obtained. Very cool!

Paul, there are some edge issues.

The grid I’m working with has -R-180/180/-60/60 gridline registered. At the ±180° longitude line, and along ±60° (in lat), the counts are not correct, because the number of cells is < 9.

I had been simply scaling by 9 to recover the counts needed (see the above post). For grid cells located adjacent to the -R edges, the scalar needed is 6.

The way I’m trying to apply this, it seems I’m “abusing” grdfilter, and being left with edges with incorrect counts. I suspect things get worse when I recover 3x3 counts in the grid corners, because there, the scalar will be 4.

Now what to do?

Maybe do -180/180 separately from 0/360 and patch in the 180 result from the 0/360 where 180 is in the middle.

As for ±60, can you get data for ±61 and then only keep results for up to ±60?, i.e., never use the edge cell results.

Its not really an issue of grdfilter. This is an outcome of what I’m actually wanting to obtain.

I have 1/4 degree cells with counts inside of them (number of observations). What I’m after is a count of the 3x3 set of cells, centered at 1/4 degrees.

grdfilter, with -Ff and a 3x3 set of 1 valued cells, gives the mean count across the cells.

Inside the grid (i.e., not along an edge), recovery of the actual count is obtained by scaling the mean count by 9. Along the edges the scale factor is 6. In the corners the scale factor is 4. Its not really an issue of bleed-over; its more of an issue of how many neighboring cells were actually used when grdfilter computed the mean (for each cell).

This isn’t a task being done on a regular basis, but, in my case, grdfilter was helpful for checking counts (within cells) that had been created, externally, for a gridded product. Until I looked closely and discovered that edge cells were not in agreement between grdfilter and my external computation. The number of cells being used to compute the count mean is important, when trying to get back to sums of counts.