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

[Dylan Beaudette]

Hi Michael

it was in a previous message from Glynn.

please refer to the link on this page:
http://casoilresource.lawr.ucdavis.edu/drupal/node/275

with a better breakdown of my previously mentioned test of Glynn's r.bilinear 
method=bicubic here:

http://169.237.35.250/~dylan/temp/raster_sampling/

Cheers,



On Monday 14 August 2006 15:52, Michael Barton wrote:
> Dylan,
>
> We wanted to try the new resampling module but can't find it in the cvs.
> Where is it?
>
> 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: Dylan Beaudette <dylan.beaudette at gmail.com>
> > Date: Mon, 14 Aug 2006 08:14:19 -0700
> > To: Maciej Sieczka <tutey at o2.pl>
> > Cc: <grassuser at grass.itc.it>, Glynn Clements <glynn at gclements.plus.com>
> > Subject: Re: [GRASS-user] integration of sample.c algorithms into
> > r.resample
> >
> > On 8/14/06, Maciej Sieczka <tutey at o2.pl> wrote:
> >> Glynn Clements napisa?(a):
> >>> Dylan Beaudette wrote:
> >>>> When I use your new version of r.bilinear method=nearest on a CELL
> >>>> image, the
> >>>> output is DCELL. While this can be fixed with r.mapcalc it shouldn't
> >>>> be too hard to add this to the new module (?) .
> >>>
> >>> It's easy enough to change, although I'm not sure whether it's the
> >>> right thing to do. It's arguable that the *only* difference between
> >>> the methods should be the way in which the result is calculated. Out
> >>> of the nine possible combinations of CELL/FCELL/DCELL input and
> >>> nearest/bilinear/bicubic methods, at least 8 of them will produce a
> >>> floating-point output map, so consistency would favour doing likewise
> >>> for the one remaining combination.
> >>>
> >>> Whilst it would be possible to forcibly convert a CELL result to
> >>> FCELL/DCELL with r.mapcalc in cases where that was required, it might
> >>> not necessarily be obvious that a conversion is necessary until the
> >>> first time you actually use method=nearest and end up having to figure
> >>> out what happened.
> >>
> >> Glynn,
> >>
> >> That's right. But there is one situation when the output *will* be CELL
> >> for sure - if the input is CELL and method=nearest. Maybe your resample
> >> module could take that into account?
> >>
> >> Other combinations are indeed hard to predict, as the most appropriate
> >> output datatype will also depend on the combinations of output region
> >> extent and input/output cell size and shape. So I guess defaulting to
> >> DCELL is very good idea.
> >>
> >> Maciek
> >
> > I agree with Maciek, in all cases but one defaulting to DCELL seems
> > like a good idea. However, it might be overly confusing / complicated
> > when an input map and NN interpolation produce a DCELL map. However, I
> > found that truncating the DCELL to CELL values worked perfectly well.
> >
> > Dylan

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