[GRASS-dev] Re: 7.x Status Update (Glynn Clements)

[Glynn Clements]

Michael Barton wrote:

> > IOW, a combination of a GUI front-end to r.colors and a replacement
> > for d.colors.
> >
> >> d.extend - It would be nice to get this functionality with g.region
> >> rast=map,map,map vect=map,map,map
> >
> > Don't we have that already?
> 
> Last time I checked, you could do g.region rast=map,map,map OR  
> g.region vect=map,map,map, but not g.region rast=map,map vect=map,map

Ah.

> Has this been enhanced to allow for simultaneous raster/vector specs?

No, but it would be quite straightforward to change it.

At present, the various options are processed in sequence, with no
mutual exclusion. Whichever one is processed last overrides the
others.

It would be simple enough to change it so that the various options are
merged, with the end result being the union (or, optionally,
intersection) of all of the individual regions.

IIRC, the way that the various printing options are handled is due for
an overhaul also.

> >> **d.font - This is used in the GUI to set the screen font.
> >
> > No it isn't; it doesn't work with immediate rendering, as there is no
> > persistence of state between d.* commands. Immediate rendering uses
> > the GRASS_FONT and GRASS_ENCODING environment variables.
> 
> It is used to get the list of available fonts (from fontcap) to  
> present to the user in a list. Is there another way to get this list?

No. However, d.font still compiles okay (there just isn't any point in
using it other than with -l/-L), so I've re-enabled it.

> > This one should ideally be available as a d.* command. The main
> > obstacles are the use of the mouse to indicate transects, and the
> > extensive use of frames. Neither of those are fundamental issues; it
> > should be feasible to cannibalise d.profile into a non-interactive
> > module.
> 
> This could probably be replicated as a command line python script  
> using MatPlotLib. The same code could be wrapped into the GUI to give  
> identical appearance with and without GUI.

I was about to ask how you would extract the cell values along the
transect, but then I discovered r.profile.

However, I note that read_rast() allocates a new row buffer for every
point, and never frees it, so there's a pretty significant memory leak
there.

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