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. 
*****************************************************************************
 
New NB(s):

	A recent discussion with a colleague indicated that there was to 
be some sort of a steering committe meeting or something along those lines 
in the near future at some site in Fort Collins, CO.  Dates are supposed to
be in early November, I will call tomorrow and find out as much as possible
and then post additional information here.

	We seem to finally (3 weeks semi dead in the water) be up and running
Solaris 2.2 on our 690's.  Problem was that S 2.2 did not support some older
hardware so we ended up replacing both CPU's and motherboards.  If your 
organization is running something similiar to this and intends to upgrade
to S 2.2 or 2.3, post a note here, (some time and headaches may be saved).

Old NB(s):

	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.vect - options to make points (P) larger.

	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. Better yet, Parents should list
all their children and require an affirmative "yes" (all three letters) prior
to deletion/modification.  Information could be generated and stored in
parent when a r.reclass operation is initiated.
     	
	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.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.
	
	r.import/r.export - menu-like tool to control the growing number of 
conversion tools contributed to grass.
	
	r. report - options to generate output for (La)TeX and troff.  The
output could then be directly read into a document without much additional
editing

	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..) *** possibly 
updated in 4.2.
	
	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.

	FLOATING POINT VALUES FOR RASTER MAPS and not only integer values.  
There is a vast amount of float data out there, and int manipulations are
not always appropriate.

     	Dynamic resizability of display windows; Erase and automatic
redrawing of display windows when window size is altered by the user.

	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. 

     	Additional projection capabilites when defining a location would
be a nice touch, specifically requested would be something to handle
an oblique stereographic projection.  

	XDRIVER possible rework/rewrite to increase speed of functions
over existing/new networks.  Theoretically an X display program should make
full use of whatever hardware is available (ie.. 8/24 bid displays). 
Hopefully fifo's could be eliminated and communication could be similiar to
any other X program.  (Possible problem related to Solaris 2.2, 2.3 may prove
to run faster when installed in the near future, notes to follow as they 
become available.

	G_distance (lat1,long1,lat2,long2) library function to calculate
azimuth and perhaps some related functions. A to B (geodesic) as well as 
some definition about typical linear distance measuring issues.

	Man pages for monitor and paint drivers, describing their operation
in greater detail.

	Beginners Manual from Martijn van Leusen ( :sorry Martijn, I just 
couldn't resist :->)   )