Wish List

[Craig Anderson]

Fellow GU/GP's:
	
	Current wish list entries are listed below, additions/modifications
to this list will be summarized next week.  This list is made from cuts of
user comments and thus represents the groups requests/views.

	If you have comments, please be sure to RE: Grass Wish List since
I sometimes only scan over other topics which may or may not apply to my
hardware/software configuration.

	Your comments are appreciated.  If you get two copies of this message, 
please ignore one of them since it is posted to both grassu-list and
grassp-list. 

NB..  In talking with CERL personnel at a recent conference in Breckenridge, 
Colorado, I was able do bet a better scope of how development of GRASS 
usually takes place.  In most cases CERL personnel are restricted to develop
additional features requrired by a paying user, ie.. some formal contract.  If
a general tool is developed from this work, it can be incorporated into GRASS,
but it appears that no open development is taking place in a broad sense.  It 
appears that the user communit is going to be more and more responsible for
their own development.  I for one am relearning C so I can get started on the
options needed right now (Fortran is somewhat of a hinderance in certain cases).

	On a good note though, a very nice visualization tool was demonstrated
by CERL personnel for 2.5 D visualization.  It was on a Silicon Graphics platform, but SUN is supposed to come up with the appropriate libs in the next
9 months or so at which time it will be ported to SUN platforms. 
	Another group here at CU Boulder had done some serious development on
a hydrologic tool which ties in to GRASS.  The user can specify from a myriad
of models and then automatically link appropriate routines.  Flags come up
on certain icons which require some input from the user to define paramaters
but it is VERY NICE and would be my first choice for additional model integration.  Release date on version 1.0 of this is 60-90 days down the road
according to the developers.  
	I also have the proceedings and as time allows, in depth reading will
blossom into additional ideas to be discussed here.

Craig
caa at noaacrd.colorado.edu

*****************************************************************************
	d.mon - it would be useful to be able to define a monitor window
at the same size as hardcopy output in order to more accurately create
maps.  It is a given that an approximate resize can be done manually but
this is not as exact as some people desire.  ** Possible fix via shell script.

	d.what.sites - an interactive query tool for displaying position and
attribute information about a site on the monitor.
	
	d.sites - with an option to display site labels on the display
monitor.
	
	g.list - provided with options to organise the mapbase (eg by
grouping reclassifications under their `parent') and to query it (eg
to find out what reclassifications exist of a given `parent'). This
should preferably work through some screen layout more gentle than the
current sea of names.
	
	g.remove/g.rename - should issue a warning before removing
or renaming `parents' of reclassified maps.
     	
	i.composite  An improvement to i.composite that allows it to assign
colors to the range of histogram values of a TM band, rather than
the actual values (an adaption of i.grey.scale?).  ERDAS features
this, and it produces cleaner visuals of imagery.

	p.map - add options to specify placement, type, size, etc. of
legends other than `colortable y'. Also north arrow, coordinate ticks,
etc. Add similar options to specify comment.  ** updated via new implementation
of p.map.new

 	ps.map - improved to allow for multiple panel printing
	
	ps.map - non integer line-width for printing and floating point
values for raster maps.

	r.average/mode/median with similiar syntax eg. base, value, output.

	r.import/r.export - menu-like tool to control the growing number of 
conversion tools contributed to grass.

	r.colors/d.colors - should be clear about what gets changed 
and why (in view of the recent mail about this) neither the display
nor the printer gets it right.

	s.to.rast - an imporoved version that creates raster map layer of a 
determined grid resolution with carry over of site attribute data.  It would
also be nice if there were options which could handle two points in one output
raster cell in different ways, (ie.. mean, max, min etc..)
	
	s.mask.what - a utility to extract points falling within a user specified raster/vector category/polygon (not necessarily rectangular) and putting those points lat/long/att into an ascii output file.

	v.import/v.export - similiar to r.import/r.export shown above.

	v.support - the option `category support' should support only
categories that are actually present in the map, so as to avoid having
to face pages of useless cats because you happen to have a cat `1666'
in the map.
	
v.cutter A version of v.cutter that simply uses the current
REGION as the 'cutting' template: sort of a "v.resample".
     
	v.report  A beefed up rewrite of the SCS contributed program,
v.report, that fixes peculiarities of the current program; in
particular, its reliance on a sequential  category file (currently, no
breaks in assigned attribute #'s allowed), and its faulty 'perimeter'
function.

     A vector/raster coincidence tool, or a vector line/polygon
coincidence tool; that would report the distance (length) of a
vector through a polygon/area, giving individual segments and an
accumulative total.  Also, a tool that would measure length of a vector
over elevation gains & losses, giving a TRUE(r) distance reading.

     A /dig_hist directory and associated files, accessible
through v.support, which carry the history of a vector map on to
the /hist directory when rasterized, and "cats" the history of 2
or more files when they are "patched" or otherwise combined in
vector or raster format.  A list of procedures performed, such a
"reclass of XXXXX" or "created by v.patch" would be attached to
the history in addition to being sent to the TITLE field.