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

[Glynn Clements]

Morten Hulden wrote:

> > A tile-based cache will work for all practical cases; you just need to
> > ensure that the cache is large enough. In practice, this means that
> > you need enough space for all of the tiles corresponding to a single
> > output row.
> > 
> > Even in the worst (practical) cases, you will only need memory
> > proportional to the size (width or height) of the source map, rather
> > than its area.
> > 
> >> Hmm... I guess this is what you mean with performance 
> >> overhead.
> > 
> > No. I was referring specifically to the design of the segment library,
> > in particular:
> > 
> > 1. Tiles can be any size. The size isn't fixed at compile time, and
> > isn't constrained to powers of two, so you have to perform two
> > division/remainder operations to convert an (x,y) pair to a segment
> > number and offset. If you use powers of two, you only need to use
> > shift/mask operations, which are faster; using a fixed power of two
> > would be faster still.
> > 
> > 2. Each cell lookup requires a function call. It may be more efficient
> > to implement the "fast path" (where the requested cell is already in
> > memory) as a macro.
> 
> What about splitting the output area into temporary smaller chunks and 
> using r.proj's built-in cropping of the input map, then r.patching the 
> chunks into a larger output map?

I would expect that to be less efficient than importing the input map
into a tile cache, as you will end up reading each portion of the
input map multiple times.

You can minimise that problem to some extent by segmenting the output
map vertically (i.e. into horizontal bands), but unless the projection
is [pseudo-]cylindrical, you will still have some overlap.

That still leaves the r.patch overhead.

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