[GRASS-dev] 6.4rc1

Glynn Clements glynn at gclements.plus.com
Fri Dec 19 08:50:40 EST 2008


Hamish wrote:

> > > I also added to the list nviz_cmd module. I am not
> > > sure about its name. Any ideas?
> > >
> > > nviz.cmd
> > 
> > I remember votes for d.3d and votes again this proposal.
> > Any consensus before rc1?
> 
> my 0c vote is for d.3d [for the d.* purists: could the outputted png be
> used in the GUI display?].   

That depends upon whether the module honours GRASS_PNGFILE,
GRASS_RENDER_IMMEDIATE, GRASS_WIDTH, GRASS_HEIGHT, etc.

E.g. if the GUI selects output to mmap()d BMP files or X Pixmaps, will
the module honour that settting? If it doesn't, it isn't a display
module.

BTW, note that g.pnmcomp only works with PPM/PGM files, not PNG.

> maybe m.out.3d? shrug
> 
> the user is interested in what the module does, not which engine is used
> in the background to do it.

Sure. So long as the module honours all of the various environment
variables (particularly those related to output format), it doesn't
matter how it goes about it. But the chances are that anything which
doesn't use the raster library won't honour those variables. Writing
out a PNG file isn't much use if the GUI is expecting the output to be
placed in PPM/PGM files or in an X Pixmap.

In the worst case, you could write a d.* module which reads an image
file then draws it using R_scaled_raster etc. For vector formats,
that's going to produce sub-standard results compared to native
rendering, but at least the output will end up where it's expected.

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


More information about the grass-dev mailing list