[GRASS-user] integration of sample.c algorithms into r.resample

GRASS GRASS user
61

This sounds OK too.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

From: Paul Kelly <paul-grass@stjohnspoint.co.uk>
Date: Thu, 17 Aug 2006 17:37:35 +0100 (BST)
To: Dylan Beaudette <dylan.beaudette@gmail.com>
Cc: <grassuser@grass.itc.it>, Glynn Clements <glynn@gclements.plus.com>
Subject: Re: [GRASS-user] integration of sample.c algorithms into r.resample

On Thu, 17 Aug 2006, Dylan Beaudette wrote:

On 8/17/06, Paul Kelly <paul-grass@stjohnspoint.co.uk> wrote:

To throw in another suggestion, how about r.resamp.interp? This it would
mean it would be adjacent in the manuals to the other resampling modules
(r.resample and r.resamp.rst) for anyone looking for them, and might also
imply that r.resample (the only one with the full word in its name) was
kind of a default, basic resampler whilst r.resamp.interp and r.resamp.rst
used more advanced and/or interesting resampling methods.

That sounds good to me.

Well I would commit it to CVS if it's OK. I briefly edited the r.bilinear
man page to create a rough manpage for r.resamp.interp (see below): are
there any glaring errors?

Paul

r.resamp.interp(1) Grass User's Manual r.resamp.interp(1)

NAME
        r.resamp.interp - Resamples raster map layers using
        interpolation.

SYNOPSIS
        r.resamp.interp

        r.resamp.interp help

        r.resamp.interp input=name output=name [method=string]
        [--overwrite]

    Flags:
        --overwrite

    Parameters:
        input=name
            Name of input raster map

        output=name
            Name for output raster map

        method=string
            Interpolation method Options: nearest,bilinear,bicubic
            Default: bilinear

DESCRIPTION
        r.resamp.interp fills a grid cell (raster) matrix with
        interpolated values generated from a set of input layer
        data points. A choice of three interpolation methods is
        available; each uses the weighted values of a different
        number of adjacent cells in the input map to determine the
        value of each cell in the output map as follows:

                      nearest neighbour (1 cell)

                      bilinear (4 cells)

                      bicubic (12 cells)

        If there is a current working mask, it applies to the out­
        put raster file. Only those cells falling within the mask
        will be assigned interpolated values. The procedure for
        selection of input data will consider all input data rele­
        vant to interpolating values at the cell centers of the
        current geographic region, ignoring the curent mask. Note
        that for bilinear and bicubic interpolation, cells of the
        output raster that cannot be bounded by the appropriate
        number of input cell centers are set to null.

NOTES
        For longitude-latitude databases, the interpolation algo­
        rithm is based on degree fractions, not on the absolute
        distances between cell centers. Any attempt to implement
        the latter would violate the integrity of the interpola­
        tion method.

SEE ALSO
        g.region, r.resample, r.resamp.rst

AUTHOR
        Glynn Clements

        Last changed: $Date: 2003/04/30 15:17:25 $

        Full index

GRASS 6.3.cvs r.resamp.interp(1)

62

Paul Kelly wrote:

On Thu, 17 Aug 2006, Dylan Beaudette wrote:

On 8/17/06, Paul Kelly <paul-grass@stjohnspoint.co.uk> wrote:

To throw in another suggestion, how about r.resamp.interp? This it would
mean it would be adjacent in the manuals to the other resampling modules
(r.resample and r.resamp.rst) for anyone looking for them, and might also
imply that r.resample (the only one with the full word in its name) was
kind of a default, basic resampler whilst r.resamp.interp and r.resamp.rst
used more advanced and/or interesting resampling methods.

That sounds good to me.

Well I would commit it to CVS if it's OK. I briefly edited the r.bilinear man page to create a rough manpage for r.resamp.interp (see below): are there any glaring errors?

I added it to CVS in raster/r.resamp.interp---so further development can be done there if necessary. Not compiled by default yet; perhaps r.bilinear should be removed when this is done.

Paul

63

Paul Kelly wrote:

>> To throw in another suggestion, how about r.resamp.interp? This it would
>> mean it would be adjacent in the manuals to the other resampling modules
>> (r.resample and r.resamp.rst) for anyone looking for them, and might also
>> imply that r.resample (the only one with the full word in its name) was
>> kind of a default, basic resampler whilst r.resamp.interp and r.resamp.rst
>> used more advanced and/or interesting resampling methods.
>
> That sounds good to me.

Well I would commit it to CVS if it's OK. I briefly edited the r.bilinear
man page to create a rough manpage for r.resamp.interp (see below): are
there any glaring errors?

        r.resamp.interp fills a grid cell (raster) matrix with
        interpolated values generated from a set of input layer
        data points. A choice of three interpolation methods is
        available; each uses the weighted values of a different
        number of adjacent cells in the input map to determine the
        value of each cell in the output map as follows:

                      nearest neighbour (1 cell)

                      bilinear (4 cells)

                      bicubic (12 cells)

The bicubic method uses 16 cells (4x4).

        If there is a current working mask, it applies to the out­
        put raster file.

Huh? The program I wrote doesn't explicitly use the mask, and libgis
only applies the mask to input maps, not output.

Due to the nature of the resampling methods, masked cells will end up
null due to the mask causing the corresponding input cells to be null,
not for any other reason.

If the module was extended to support other interpolation methods
which handled nulls differently, it's conceivable that an output cell
could be non-null in spite of that cell being masked.

--
Glynn Clements <glynn@gclements.plus.com>

64

Michael Barton wrote:

I've been following this thread and am looking forward to using the new
module.

Here's my suggestion on the names.

The new module should inherit the name of r.resample because that is what it
does. Indeed it uses interpolation methods to accomplish this resampling,
but r.interpolate (to me) suggests something that creates a raster surface
from a set of points.

The old module could be renamed to indicate that it resamples using the same
algorithm used in the on-the-fly resampling of g.region in the display. Here
are several suggestions.

r.resample.region
r.dresample
r.gresample
r.region.resample
r.gregion.resample

r.resample.raw?

I suspect that this older module will eventually become unused if the new
module works well. But Glynn makes a good point why we should keep it around
for now.

To put it (yet) another way, the existing r.resample produces the same
result as any module which acts as an "identity" operation for some
combination of parameters, e.g. "r.neighbors method=average size=1",
"r.series method=average" when applied to a single input map,
"r.mapcalc foo = bar", etc.

--
Glynn Clements <glynn@gclements.plus.com>

65

Glynn Clements wrote:

> > This would require some modification to the I/O strategy, specifically
> > the number of rows kept in memory would vary at run-time, and would
> > vary from row to row (the number of source rows and columns
> > corresponding to each destination cell would vary by 1; e.g. a scale
> > factor 3.5 would result in a destination cell corresponding to 3x3,
> > 3x4, 4x3 or 4x4 source cells).
>
> Looks like getting the aggregation to work within a C module will be a bit
> difficult. r.neighbors was my initial thought for this type of functionality,
> but it might complicate the tool chain as you have said down thread...

The main reason why I suggest r.neighbors is that it already has a set
of aggregate functions.

Hmm; so does r.series. It's been suggested before to make a library of
aggregate functions which could be used by multiple modules. Such
discussions have tended to get bogged down with issues related to
modules such as r.statistics, which need to compute aggregates over a
large number of samples.

If we have 3 modules which need to compute aggregates over a
relatively small number of samples, it's probably worth making a
library from the code for r.series and/or r.neighbors to use with such
modules. We can leave the more complex case (r.statistics) for later.

But first, I need to figure out what's wrong with the updated bicubic
interpolation equations.

I've moved the aggregates from r.series/r.neighbors into a separate
library (lib/stats).

I have also written the aggregate resampling module; it supports all
of the existing aggregates which make sense for a resampling module,
namely: average,median,mode,minimum,maximum,quart1,quart3,perc90.

I'll commit it once a name has been agreed upon.

--
Glynn Clements <glynn@gclements.plus.com>

66

Glynn Clements wrote:

I've moved the aggregates from r.series/r.neighbors into a separate
library (lib/stats).

I have also written the aggregate resampling module; it supports all
of the existing aggregates which make sense for a resampling module,
namely: average,median,mode,minimum,maximum,quart1,quart3,perc90.

I'll commit it once a name has been agreed upon.

FWIW my suggestion would be r.resamp.stats, to tie in with the convention established with r.resamp.rst, r.resamp.interp, and to suggest that this module also resamples but does so based on statistical properties of the input map. I think "stats" is easier to understand and remember than whatever abbreviated form of "aggregation" we might choose.

Let the discussion continue...
(I actually think that serious discussion of potential names for new modules is very worthwhile and makes a big difference to how easy it is for users to find the module in the future---more importantly than associating keywords with it)

Paul

67

On 8/20/06, Glynn Clements <glynn@gclements.plus.com> wrote:

Glynn Clements wrote:

> > > This would require some modification to the I/O strategy, specifically
> > > the number of rows kept in memory would vary at run-time, and would
> > > vary from row to row (the number of source rows and columns
> > > corresponding to each destination cell would vary by 1; e.g. a scale
> > > factor 3.5 would result in a destination cell corresponding to 3x3,
> > > 3x4, 4x3 or 4x4 source cells).
> >
> > Looks like getting the aggregation to work within a C module will be a bit
> > difficult. r.neighbors was my initial thought for this type of functionality,
> > but it might complicate the tool chain as you have said down thread...
>
> The main reason why I suggest r.neighbors is that it already has a set
> of aggregate functions.
>
> Hmm; so does r.series. It's been suggested before to make a library of
> aggregate functions which could be used by multiple modules. Such
> discussions have tended to get bogged down with issues related to
> modules such as r.statistics, which need to compute aggregates over a
> large number of samples.
>
> If we have 3 modules which need to compute aggregates over a
> relatively small number of samples, it's probably worth making a
> library from the code for r.series and/or r.neighbors to use with such
> modules. We can leave the more complex case (r.statistics) for later.
>
> But first, I need to figure out what's wrong with the updated bicubic
> interpolation equations.

I've moved the aggregates from r.series/r.neighbors into a separate
library (lib/stats).

I have also written the aggregate resampling module; it supports all
of the existing aggregates which make sense for a resampling module,
namely: average,median,mode,minimum,maximum,quart1,quart3,perc90.

I'll commit it once a name has been agreed upon.

wow. so this new functionality can deal with the resolutoin switching
issues - or was there a cleaner implementation? I am exctied about
testing these against the results from the raster-vector-raster
approach to aggregation that I posted a while back.

does r.aggregate make sense for a module name ?

Dylan

thanks for the hard work.

68

Dylan Beaudette wrote:

> > > > This would require some modification to the I/O strategy, specifically
> > > > the number of rows kept in memory would vary at run-time, and would
> > > > vary from row to row (the number of source rows and columns
> > > > corresponding to each destination cell would vary by 1; e.g. a scale
> > > > factor 3.5 would result in a destination cell corresponding to 3x3,
> > > > 3x4, 4x3 or 4x4 source cells).
> > >
> > > Looks like getting the aggregation to work within a C module will be a bit
> > > difficult. r.neighbors was my initial thought for this type of functionality,
> > > but it might complicate the tool chain as you have said down thread...
> >
> > The main reason why I suggest r.neighbors is that it already has a set
> > of aggregate functions.
> >
> > Hmm; so does r.series. It's been suggested before to make a library of
> > aggregate functions which could be used by multiple modules. Such
> > discussions have tended to get bogged down with issues related to
> > modules such as r.statistics, which need to compute aggregates over a
> > large number of samples.
> >
> > If we have 3 modules which need to compute aggregates over a
> > relatively small number of samples, it's probably worth making a
> > library from the code for r.series and/or r.neighbors to use with such
> > modules. We can leave the more complex case (r.statistics) for later.
> >
> > But first, I need to figure out what's wrong with the updated bicubic
> > interpolation equations.
>
> I've moved the aggregates from r.series/r.neighbors into a separate
> library (lib/stats).
>
> I have also written the aggregate resampling module; it supports all
> of the existing aggregates which make sense for a resampling module,
> namely: average,median,mode,minimum,maximum,quart1,quart3,perc90.
>
> I'll commit it once a name has been agreed upon.

wow. so this new functionality can deal with the resolutoin switching
issues - or was there a cleaner implementation? I am exctied about
testing these against the results from the raster-vector-raster
approach to aggregation that I posted a while back.

The new module uses resolution switching: read the source map at its
native resolution, write the result at the current region's
resolution. The value in each output cell is an aggregate over the set
of input cells whose centres lie within the bounds of the output cell.

does r.aggregate make sense for a module name ?

My local copy is named r.resamp.aggregate, although that might be a
bit too long.

--
Glynn Clements <glynn@gclements.plus.com>

69

On 8/20/06, Glynn Clements <glynn@gclements.plus.com> wrote:

Dylan Beaudette wrote:

> > > > > This would require some modification to the I/O strategy, specifically
> > > > > the number of rows kept in memory would vary at run-time, and would
> > > > > vary from row to row (the number of source rows and columns
> > > > > corresponding to each destination cell would vary by 1; e.g. a scale
> > > > > factor 3.5 would result in a destination cell corresponding to 3x3,
> > > > > 3x4, 4x3 or 4x4 source cells).
> > > >
> > > > Looks like getting the aggregation to work within a C module will be a bit
> > > > difficult. r.neighbors was my initial thought for this type of functionality,
> > > > but it might complicate the tool chain as you have said down thread...
> > >
> > > The main reason why I suggest r.neighbors is that it already has a set
> > > of aggregate functions.
> > >
> > > Hmm; so does r.series. It's been suggested before to make a library of
> > > aggregate functions which could be used by multiple modules. Such
> > > discussions have tended to get bogged down with issues related to
> > > modules such as r.statistics, which need to compute aggregates over a
> > > large number of samples.
> > >
> > > If we have 3 modules which need to compute aggregates over a
> > > relatively small number of samples, it's probably worth making a
> > > library from the code for r.series and/or r.neighbors to use with such
> > > modules. We can leave the more complex case (r.statistics) for later.
> > >
> > > But first, I need to figure out what's wrong with the updated bicubic
> > > interpolation equations.
> >
> > I've moved the aggregates from r.series/r.neighbors into a separate
> > library (lib/stats).
> >
> > I have also written the aggregate resampling module; it supports all
> > of the existing aggregates which make sense for a resampling module,
> > namely: average,median,mode,minimum,maximum,quart1,quart3,perc90.
> >
> > I'll commit it once a name has been agreed upon.
>
> wow. so this new functionality can deal with the resolutoin switching
> issues - or was there a cleaner implementation? I am exctied about
> testing these against the results from the raster-vector-raster
> approach to aggregation that I posted a while back.

The new module uses resolution switching: read the source map at its
native resolution, write the result at the current region's
resolution. The value in each output cell is an aggregate over the set
of input cells whose centres lie within the bounds of the output cell.

> does r.aggregate make sense for a module name ?

My local copy is named r.resamp.aggregate, although that might be a
bit too long.

Glynn. This sounds great. module names... some more ideas:
r.resamp.aggr
r.aggregate (with link and keywords relating it to the other resamp. modules)

looking forward to seeing this in CVS.

Dylan

70

Glynn Clements napisa?(a):

I've moved the aggregates from r.series/r.neighbors into a separate
library (lib/stats).

I have also written the aggregate resampling module; it supports all
of the existing aggregates which make sense for a resampling module,
namely: average,median,mode,minimum,maximum,quart1,quart3,perc90.

Does that mean that r.mode and r.median could be disposable in future?
Any other modules?

Best,
Maciek

71

Maciej Sieczka wrote:

> I've moved the aggregates from r.series/r.neighbors into a separate
> library (lib/stats).
>
> I have also written the aggregate resampling module; it supports all
> of the existing aggregates which make sense for a resampling module,
> namely: average,median,mode,minimum,maximum,quart1,quart3,perc90.

Does that mean that r.mode and r.median could be disposable in future?
Any other modules?

No (although I'm not sure what r.average, r.median and r.mode provide
which can't be done using r.statistics).

The aggregate module computes aggregates over a single cell, whereas
r.mode etc compute aggregates over larger areas, defined by sharing a
common category within a base map.

The aggregate resampling module resamples a map so that each output
cell contains an aggregate of all of the source cells whose centres
lie within the bounds of the output cell.

--
Glynn Clements <glynn@gclements.plus.com>