[GRASS-dev] Re: [GRASS-user] problems using r.proj with large
morten at untamo.net
Thu Dec 14 04:56:13 CET 2006
Glynn Clements 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
> 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?
Of course, this can be done manually even now, but since most of the
code is already in place, it could be a relatively easy solution.
> Gerald Nelson wrote:
> Is there any possibility that r.proj could become a front end for gdalwarp; essentially doing the steps I did manually behind the scenes?
I guess one reason people still want to use r.proj is because the output
maps will be aligned and have exactly the same resolution as the current
grid, and thus be available for further analysis together with other
maps of the location with the tools that require all maps to have same
The scopes of gdalwarp and r.proj are slightly different.
More information about the grass-dev