[GRASS-user] r.resamp observations

Hi,

after resampling some maps, some observations-

highlights:
* apparent data bug in r.resamp.stats
* r.resamp* modules are inconsistent in usage
* there seems to be some inter-module spatial bias going on
* message bug in r.resamp.rst
* g.region+"r.mapcalc new=old" shows the least spatial bias WRT null/
   non-NULL (use to make coverage masks for other more sloppy methods)

original map: 10m, 4150x2900 cells
target res: 50m, 100m, 200m (,500m).
(Modules may be assuming target is finer than original, but I'm going
the other way)

inconsistency:
r.resamp.interp propagates nulls by default
  # shrinks map

r.resamp.stats doesn't propagate nulls by default (-n flag)
  # grows map (maybe just an artifact of southward bug? [see below])

r.resamp.rst doesn't propogate nulls by default
  # 50m resample grows map by 2-3 cells.
  # if 50m resample MASKed to original extent it looks good
  # as the res->500m, it only grows towards North East (?)
  # for ->500m it seems to shift the data NE too, but that may
  # just be a trick of the eye

To get the "best" resampled null-edge: (no growth, cells stradle vect edge)
g.region res=50
r.mapcalc "50m_mask=if(isnull(original.10m), null(), 1)"

r.resamp.interp method=bilinear and bicubic will shrink the map when
it sees a null (which makes sense). This means that it is not much use
to folks who need info at the edges. (unless using some trick like
r.patch'ing the edges back in from another method :-/)

bug:
r.resamp.stats seems to shift the data southward by ~ 1 cell vs.
r.resamp.interp, r.resamp.rst, and g.region+r.mapcalc methods.

inconsistency:
r.resamp.rst must be run in the source resolution, while the other
methods are run from the target resolution.

bug:
r.resamp.rst from 10m to 100m:
ew_res=100 ns_res=100
Processing all selected output files will require
1444200 bytes of disk space for temp files.
Temporarily changing the region to desired resolution ...
Changing back to the original region ...
Percent complete:
Not enough disk space--cannot write files
Not enough disk space--cannot write files
Not enough disk space--cannot write files
Not enough disk space--cannot write files
Not enough disk space--cannot write files
Not enough disk space--cannot write files
Not enough disk space--cannot write files
Not enough disk space--cannot write files
...

(many gigs free)

trying it with
   2>&1 | grep -v "Not enough disk space"
it finishes, results look ok. Same command 10m->50m worked fine.
I also see the warnings with res=200.

For .rst with res=500 the north-east shift is more obvious.

.. and finally: at 100m,200m,+ resolutions there seems to be a northward
bias in g.region+r.mapcalc method vs. resamp.rst and resamp.interp/bicubic.
?

Hamish

Hamish wrote:

inconsistency:
r.resamp.interp propagates nulls by default
  # shrinks map

This is to be expected. Filling nulls by extrapolation would require a
radically different approach. Use r.fillnulls first.

r.resamp.stats doesn't propagate nulls by default (-n flag)
  # grows map (maybe just an artifact of southward bug? [see below])

The default is to compute the aggregate over all non-null cells.

The main reason for the inconsistency is that ignoring nulls is
trivial for an aggregate but not possible for an algebraic expression
over a fixed set of values (instead, you have to specifically compute
substitute values through e.g. extrapolation).

r.resamp.interp method=bilinear and bicubic will shrink the map when
it sees a null (which makes sense). This means that it is not much use
to folks who need info at the edges. (unless using some trick like
r.patch'ing the edges back in from another method :-/)

This can't be helped. An interpolate between a known value and an
unknown value is itself an unknown value.

bug:
r.resamp.stats seems to shift the data southward by ~ 1 cell vs.
r.resamp.interp, r.resamp.rst, and g.region+r.mapcalc methods.

Is this with a recent CVS copy? There was a bug which resulted in a
south-west shift of 0.5 map units, which was fixed on 2006/12/07.

Other than that, can you provide exact regions?

.. and finally: at 100m,200m,+ resolutions there seems to be a northward
bias in g.region+r.mapcalc method vs. resamp.rst and resamp.interp/bicubic.
?

The exact region settings, both bounds and resolution, are necessary
in order to try to reproduce these results.

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

Glynn Clements wrote:

> bug:
> r.resamp.stats seems to shift the data southward by ~ 1 cell vs.
> r.resamp.interp, r.resamp.rst, and g.region+r.mapcalc methods.

Is this with a recent CVS copy? There was a bug which resulted in a
south-west shift of 0.5 map units, which was fixed on 2006/12/07.

ok, that's probably it; no time to retest now. Note the CVS log message
says it applies to lat-lon locations, and this was not LL.

Hamish

Hamish wrote:

> > r.resamp.stats seems to shift the data southward by ~ 1 cell vs.
> > r.resamp.interp, r.resamp.rst, and g.region+r.mapcalc methods.
>
> Is this with a recent CVS copy? There was a bug which resulted in a
> south-west shift of 0.5 map units, which was fixed on 2006/12/07.

ok, that's probably it; no time to retest now. Note the CVS log message
says it applies to lat-lon locations, and this was not LL.

Actually, it applies to all locations, but a 0.5 unit shift is a lot
more significant if the units are degrees.

The other side of the coin is that it was supposed to be a 0.5 cell
shift, i.e. round rather than truncate so that cells were selected by
their centres rather than their corners. The 0.5 unit shift was
instead of the 0.5 cell shift; it may be the lack of the 0.5 cell
shift that is at issue.

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