I wonder what kind of function you're using since it seems the zonal()
limitation is more a safety than a necessity. It's just that you need many
levels of aggregation when the raster can't be completely loaded in memory
and probably Robert couldn't come up with a generic solution for
aggregation so put this limitation.

If your function needs the whole chunk of values, then it would probably
require more work, but if your function can be computed using small chunks,
you could possibly get rid of the safety and run your zonal in two steps
(or more).

Etienne


2013/2/12 Matt Landis <landis@isciences.com>

> Ned, Forrest, et al.,
> We have run into the same problems you have.  Our solution was a non-R
> solution in which we used GDAL to rasterize the polygon layer (which was
> substantially faster than the R equivalents) and then the Python
> scipy.ndimage functions to calculate the zonal stats.  There is a
> description of this approach here:
> https://sites.google.com/site/spatialpython/zonal-statistics.
>
> Nothing against the raster package, which I use on a daily basis and
> thoroughly enjoy.  But this is one of the few (only?) tasks for which I
> haven't been able to find a fast R-based approach.
>
> M
>
>
>
> On Mon, Feb 11, 2013 at 11:03 PM, Forrest Stevens <forrest@ufl.edu> wrote:
>
> > On Mon, Feb 11, 2013 at 10:44 PM, Ned Horning <horning@amnh.org> wrote:
> > > Hi - Are there alternatives to using the raster package "zonal"
> function
> > > for
> > > large images when using functions for the "stat" parameter?
> >
> > I would be interested to know as well.  I have found both extract and
> > zonal to be unworkably slow over large datasets.  As a workaround I
> > currently am using RPyGeo to run zonal statistics using the ArcGIS
> > GeoProcessing environment.  I'd like to keep it all in R without the
> > overhead of invoking the ArcGIS environment, but as of right now it
> > takes a fraction of the time to jump through those hoops, even with
> > moderately sized raster and polygon datasets.
> >
> > I hope this causes no offense to Robert and Jacob regarding the raster
> > package... It's truly indispensable and makes R a joy to work with for
> > most raster-based tasks.. But I think there's room for improvement
> > somewhere along that analysis chain, with a bottleneck that can
> > hopefully be bypassed at some point soon (I haven't had time to dig
> > into the source but maybe one day!)
> >
> > Sincerely,
> > Forrest Stevens
> >
> > --
> > Ph.D. Candidate, QSE3 IGERT Fellow
> > Department of Geography
> > Land Use and Environmental Change Institute
> > University of Florida
> > www.clas.ufl.edu/users/forrest
> >
> > _______________________________________________
> > R-sig-Geo mailing list
> > R-sig-Geo@r-project.org
> > https://stat.ethz.ch/mailman/listinfo/r-sig-geo
> >
>
>
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Matthew Landis, Ph.D.
> Research Scientist
> ISciences, LLC
> 61 Main St., Suite 200
> Burlington VT 05401
>
> 802-864-2999
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>         [[alternative HTML version deleted]]
>
> _______________________________________________
> R-sig-Geo mailing list
> R-sig-Geo@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>

	[[alternative HTML version deleted]]

