[GRASS5] GRASS 5.1 and new raster directory structure proposal

[Markus Neteler]

Dear developers,

while the 5.1 vector architecture is sort of settled now, we may
want to have a look at a raster specific issue as well:
The raster file structure.

The 5.0 raster file structure differs from the G3D and the 5.1 vector
file structure. G3D and  5.1 vector store maps according to 
following scheme:

location/mapset/grid3/mapname/files
such as
	grid3/mapname/cell
	grid3/mapname/cellhd
	grid3/mapname/range
	grid3/mapname/cats

location/mapset/vector/mapname/files
such as
	vector/mapname/coor
	vector/mapname/head
	vector/mapname/sidx
	vector/mapname/topo

while the 5.0 raster files are spreaded over various subdirectories and
organized by name.

My proposal is to change the 5.0 raster file structure for 5.1.

A raster file organization similar to above structure by:
 maptype/mapname/files

offers following advantages:

- clean and "intuitive" file organization, all files in one place
  which simplifies map transfer from one location to another (if needed
  without reprojection etc), e.g. when working on a cluster

- simplified GIS/Rast library functions as files are stored in one place.
  Currently a rather complex mechanism is implemented to search the spreaded
  raster files belonging to one map, often in various mapsets.

- implementing the change for 5.1 does have minimal (no?) conflicts to
  the new vector modifications. And a delay to 5.3 is not recommended as the
  users may not want to change their data structures again.

- updating of an existing database to the new raster file storage scheme
  is simple as the maps are either linked into the new raster/ directory
  or moved or copied. In contrast to the new vector format no format
  changes are intended (just a new place for the files)

- raster/vector/G3D maps with same names are still possible

- during this change/cleanup the 'white space" issues could be fixed
  (especially for MS-Windows users) as relevant functions are touched

Potential disadvantages:

- at least some raster modules have to be modified which directly access
  file in the user's (current) mapset
  Comment: with exceptions such modules *should* use library functions to
           access files and should be cleaned anyway
- handling of 'colr2/' directory (user applies color table to map which
  is stored in another mapset) [1] and 'reclassed_to' file handling must be
  modified
  Comment: at least the reclassed_to' file handling was discussed earlier to
           have some disadvantages in the current implementation and might
           be updated/modified anyway

----------------------
[1] A 'colr2/' directory related suggestion from Glynn Clements:
> Rather than having a special-case mechanism which allows an alternate
> colour table to be "overlaid" onto an existing map (possibly in a
> different mapset), it would be preferable, IMHO, to create a
> "recolour" map. This would work like a reclass map; the "recolour" map
> would exist as an actual map as far as the user is concerned, but all
> of the data (except for the colour table) would be taken from the base
> map.
> 
> There would probably be other uses for such a mechanism (e.g. category
> labels, horizontally or vertically rescaled maps etc).

Hoping for a fruitful discussion,

 Markus