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 <[EMAIL PROTECTED]> _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev