[GRASS5] features needed for 6.2

[Glynn Clements]

Hamish wrote:

> Restructuring of the raster elements into a $MAPSET/raster/ dir means a
> break to GRASS 7.0. It makes sense that this should happen in
> combination with and at the same time as a revamp of the raster format
> itself. That way we only have to do the transition once.

I disagree. Switching the raster directory layout is much simpler than
a new raster format. With the former, it's clear what needs to be
done; it's just a matter of doing it.

> (otherwise we
> have GRASS 8.0, four times the backwards incompatibility ugliness, etc.)
> Glynn: If you were to take this on, how does Oct-Dec this year sound for
> starting work? "2007"? "2012"?

It isn't something which can be done to a timescale. The complexity is
in the design, not the implementation. Every now and then, I revisit
the idea. Hopefully, I'll come up with a workable design eventually,
but I have no idea when.

FWIW, my main goals for a new raster architecture are:

1. Tiled storage. It should be practical to create a single global
lat/lon location, read in all of the ETOPO30 DEMs, patch them together
into a single 43200 x 21600 map, and use it (currently, you have to
decompress an entire row even if you only use a small portion of it).

2. A new API which allows modules to treat a raster essentially as a
2D/3D array, without having to explicitly read rows or use the rowio
or segment libraries.

3. Compatibility. Both the row-oriented and array-model APIs would
need to work with both the old (row-based) and new (tiled) formats.

4. Efficiency.

Point 4 is the hard part.

Both raw and "cooked" (decoded and rescaled) data may need to be
cached (for modules like r.proj, r.cost) or not (for conventional
top-to-bottom, left-to-right processing).

The optimal rescaling algorithm depends upon whether you are scaling
up (every input cell is used, possibly duplicated) or down (some input
cells are ignored, those which are used are only used once), and
whether your are using linear, near-linear or random access.

The optimal block sizes and data formats (those used for storage and
those presented to the application) may vary between applications, yet
fixing those parameters at compile time will, in general, be more
efficient.

I don't want to hand-code optimal algorthims for all of the various
combinations of parameters, but I don't particularly want to
complicate the code by using machine-generated code (e.g. extensive
preprocessing or C++ templates) either.

> GUIs for r.digit*, i.points: If ready in the 4 weeks after 6.1.0 is
> released put it in for 6.2.0. If after that then wait until after 6.2.0.
> i.e. We shouldn't wait for it to mature before we can release 6.2.

There's no reason why Tcl/Tk versions can't sit alongside the existing
implementations. The R_get_location_with_* functions can't be removed
until GRASS is basically usable without them.

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