[GRASS-dev] Re: [GRASS-user] problems using r.proj with large data set

[Glynn Clements]

Glynn Clements wrote:

> > > Assuming that it works out okay, I'll probably end up merging
> > > r.proj.seg into r.proj, with the macro handling the details of whether
> > > to read from a tile cache (large maps) or from a single block of
> > > memory (small maps).
> > 
> > This makes sense. For small maps is it much faster to not use the cache?
> 
> I haven't performed timings; to be of much use, they would need to be
> done with "real-world" cases.
> 
> As it stands, even if you made the cache large enough to hold the
> entire map, it would currently get written out to a temporary file
> then read back in on demand.
> 
> There's bound to be some overhead to using an extra level of
> indirection, but it's probably trivial compared to the projection
> calculations (and particularly compared to bicubic interpolation).
> 
> One of the next things which needs to be done to r.proj.seg is to add
> an option to set the cache size. Once that's done, I'll look into
> trapping the case where the cache can hold the entire map, and
> eliminate the temporary file in that situation.

I've done that; some (not exactly representative) results reprojecting
GTOPO30 to spearfish (30m, 634 cols x 477 rows):

$ r.proj input=w140n90 location=global mapset=glynn output=proj method=nearest

real	0m2.971s
user	0m2.922s
sys	0m0.023s
$ r.proj.seg memory=100 input=w140n90 location=global mapset=glynn output=proj method=nearest

real	0m2.929s
user	0m2.891s
sys	0m0.018s
$ r.proj input=w140n90 location=global mapset=glynn output=proj method=bilinear

real	0m3.419s
user	0m3.280s
sys	0m0.106s
$ r.proj.seg input=w140n90 location=global mapset=glynn output=proj method=bilinear memory=100

real	0m3.461s
user	0m3.346s
sys	0m0.088s
$ r.proj input=w140n90 location=global mapset=glynn output=proj method=cubic

real	0m3.877s
user	0m3.731s
sys	0m0.111s
$ r.proj.seg memory=100 input=w140n90 location=global mapset=glynn output=proj method=cubic

real	0m4.169s
user	0m4.058s
sys	0m0.093s

The speed of r.proj.seg relative to r.proj ranges from ~1.4% faster
(nearest) to ~7.5% slower (bicubic). If those results hold up for
representative data, r.proj.seg can replace r.proj.

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