[GRASS5] GRASS 5.1 and new raster directory structure proposal

Markus Neteler neteler at itc.it
Mon Jan 20 02:46:06 EST 2003

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:

such as

such as

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:

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
  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,


More information about the grass-dev mailing list