[GRASS5] 5.4 release branch

[Glynn Clements]

Markus Neteler wrote:

> > Here is my first rough draft of what to put in the NEWS file for 5.4.0, 
> > additions and corrections welcome:
> > 
> > 
> > Raster I/O re-write incorporating support for files > 2GB (Glynn)
> 
> Probably it should become a flag for 'configure' (maybe that is already?)?

I'm not sure about the right way to implement this. Ideally, it should
only be the core raster I/O files which I changed which should be
using the large-file support, as the rest of GRASS won't handle large
files correctly.

One possibility is to make configure define a macro, e.g.
RASTER_LARGEFILE, in config.h, and have the files in question do:

	#include "config.h"
	#ifdef RASTER_LARGEFILE
	#define FILE_OFFSET_BITS 64
	#endif

before including any other headers. But that seems a bit messy.

> > Support for zlib compression in integer/CELL maps (Glynn)
> 
> How to activate it?

If the environment variable GRASS_INT_ZLIB exists, new compressed
rasters will be compressed using zlib instead of RLE compression. Such
rasters will have a "compressed" value of 2 in the cellhd file. 
Obviously, decompression is controlled by the raster's "compressed"
value, not the environment variable.

> Is that documented?

Not yet.

> > g.pnmcomp: Added (Glynn)
> 
> Is it documented?

No.

It's intended for internal use only, if at all. It composes a set of
PPM/PGM files (where a PGM file contains the alpha channel for a
specific PPM file) into a single PPM file.

The idea is to consider using it in d.m, in conjunction with the PNG
driver. d.m would render each layer as a PPM/PGM pair (the PNG driver
will generate these if $GRASS_PNGFILE ends in ".ppm" and
$GRASS_TRANSPARENT is "TRUE").

If the layer stack is changed (enabling or disabling layers, changing
the ordering), d.m would only need to re-compose the
(already-rendered) PPM/PGM files, which is much faster than
re-rendering everything using the d.* programs.

This assumes that d.m would be displaying the composed image itself
(in a Tk widget) rather than via XDRIVER.

> > r.colors new format for rules files (Hamish, Glynn)
> 
> Is there a possibility to make the parser (a function) list the
> available color files? Such as the 5.7 db.* tools list the available DB
> drivers?

Can you elaborate?

-- 
Glynn Clements <glynn.clements at virgin.net>