[GRASS5] GRASS 5.1 and new raster directory structure proposal
neteler at itc.it
Mon Jan 20 02:46:06 EST 2003
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
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
- 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)  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
 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
> 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