I'm curious if anyone has developed any scripts to divide a raster process up *spatially* across multiple processors, given a) a tile size and b) an overlap size. We are hoping to run r.sun at 10m across California, and would like to break up the full process into smaller individual tiles. Anyone done anything like this before and would be willing to share your script? Thanks!
--j
--
Jonathan A. Greenberg, PhD
Postdoctoral Scholar
Center for Spatial Technologies and Remote Sensing (CSTARS)
University of California, Davis
One Shields Avenue
The Barn, Room 250N
Davis, CA 95616
Phone: 415-763-5476
AIM: jgrn307, MSN: jgrn307@hotmail.com, Gchat: jgrn307
I'm curious if anyone has developed any
scripts to divide a raster process up *spatially* across
multiple processors, given a) a tile size and b) an overlap
size. We are hoping to run r.sun at 10m across
California, and would like to break up the full process into
smaller individual tiles. Anyone done anything like
this before and would be willing to share your script?
be careful with r.sun tiles that you don't crop away shading
mountains just outside of the region. ie you want to include
as much of the "light catchment" basin as possible.
to minimize edge effects I always try to run r.sun with a bit
bigger domain than I am really interested in & allow for some
overlap. when patching two overlapping tiles back together
perhaps 'min' is the method to use? or do you really need to
patch them back together at all?
how many rows x cols is CA @ 10m? at least it is tall & narrow,
which is the optimum for memory use with the raster engine.
staying with the same map projection for the whole thing?
I guess from the "*spatially*" you've seen the r.sun wiki page with its 'poor-man's multi-processing trick' for per-day MP?
r.sun does not use the segment library AFAIR, so parallizing
that wouldn't help.