$Id: TODO.txt,v 1.13.2.1 2003/03/16 12:25:16 glynn Exp $
TODO for GRASS GIS:
See ONGOING for ONGOING GRASS projects.
---------------------------------------------------------------------
Wishlist for GRASS 5
---------------------------------------------------------------------
- Fix the bugs described in BUGS
http://intevation.de/rt/webrt
---------------------------------------------------------------------
Modules which need to be updated to FP (raster floating point):
The following files are candidates as using the old
G_get_map_row() function which is deprecated!
Probably no updated is required, but G_get_c_raster_row() should
be used instead to avoid color and other problems.
-> question: shall all CELL, FCELL and DCELL be supported?
The prog.man states that DCELL is better than FCELL.
At time a wild mixture is used.
./display/d.profile/What.c
./display/d.rast.arrow/arrow.c
./display/d.rgb/cmd/main.c
./imagery/i.cca/cmd/transform.c
./imagery/i.class/draw_match.c
./imagery/i.class/readbands.c
./imagery/i.composite/compose.c
./imagery/i.fft/cmd/do_histogram.c
./imagery/i.fft/cmd/fftmain.c
./imagery/i.fft/cmd/ifftmain.c
./imagery/i.grey.scale/grey_scale.c
./imagery/i.ortho.photo/photo.2image/drawcell.c
./imagery/i.ortho.photo/photo.2target/drawcell.c
./imagery/i.ortho.photo/photo.rectify/perform.c
./imagery/i.ortho.photo/photo.rectify/rectify.c
./imagery/i.out.erdas/cmd/main.c
./imagery/i.pca/cmd/main.c
./imagery/i.points3/inter/draw_cell.c
./imagery/i.points3/inter/read_elev.c
./imagery/i.quantize/compose.c
./imagery/i.rectify3/cmd/perform.c
./imagery/i.rectify3/cmd/matrix.c
./imagery/i.rectify3/cmd/read_elev.c
./imagery/i.rectify3/inter/matrix.c
./imagery/i.rectify3/inter/perform.c
./imagery/i.rectify3/inter/read_elev.c
./imagery/i.rgb.his/cmd/getinput.c
./imagery/i.rgb.his/cmd/h2rmain.c
./imagery/i.rgb.his/cmd/r2hmain.c
./imagery/i.zc/cmd/main.c
./libes/rst_gmsl/interp_float/input2d.c
./libes/rst_gmsl/interp_float/ressegm2d.c
./mapdev/v.digit/eq.c
./mapdev/v.digit/drawcell.c
./mapdev/v.out.dxf/backup/cell.to.dat.c
./mapdev/v.out.dxf/cell.to.dat.c
./paint/Programs/p.map/cmd/SAVE/map.sf.c
./paint/Programs/p.map/cmd/mask_vctrs.c
./paint/Programs/p.map.new/cmd/mask_grid.c
./paint/Programs/p.map.new/cmd/mask_vctrs.c
./paint/p.vrml1.1/put_grid.c
./ps.map/ps.map/cmd/rast_plot.c
./raster/r.agnps50/hydro_tools/r.cn/Gcn.c
./raster/r.agnps50/hydro_tools/r.cn2/Gcn.c
./raster/r.agnps50/hydro_tools/r.weighted.cn/r.weighted.cn.c
./raster/r.agnps50/src_agnps_input_1/create_grid_map.c
./raster/r.agnps50/src_agnps_input_1/cell_num_id.c
./raster/r.agnps50/src_agnps_input_1/drain_num.c
./raster/r.agnps50/src_agnps_input_1/misc_routines.c
./raster/r.agnps50/src_agnps_input_1/slope_aspect.c
./raster/r.agnps50/src_agnps_input_2a/agnps_input.c
./raster/r.agnps50/src_agnps_input_2a/create_grid_map.c
./raster/r.agnps50/src_agnps_input_2a/cell_num_id.c
./raster/r.agnps50/src_agnps_input_2a/drain_num.c
./raster/r.agnps50/src_agnps_input_2a/misc_routines.c
./raster/r.agnps50/src_agnps_input_2a/slope_aspect.c
./raster/r.basins.fill/read_map.c
./raster/r.bilinear/main.c
./raster/r.binfer/engine.c
./raster/r.buffer/cmd/write_map.c
./raster/r.clump/cmd/clump.c
./raster/r.combine/cmd/r_rd_line.c
./raster/r.cross/cross.c
./raster/r.cross/renumber.c
./raster/r.grow/cmd/main.c
./raster/r.infer/cmd/run_maps.c
./raster/r.los/cmd/main.c
./raster/r.mask.points/cmd/main.c
./raster/r.mfilter/cmd/getrow.c
./raster/r.out.pov/cmd/main.c
./raster/r.out.tga/main.c
./raster/r.poly/cmd/io.c
./raster/r.random.cells/init.c
./raster/r.random.surface/calcsurf.c
./raster/r.random.surface/init.c
./raster/r.random.surface/save.c
./raster/r.rescale/cmd/get_range.c
./raster/r.rescale/inter/get_range.c
./raster/r.rescale.eq/cmd/get_stats.c
./raster/r.support/inter/histo.c
./raster/r.support/cmd/histo.c
./raster/r.surf.contour/cmd/bseg_read.c
./raster/r.surf.contour/cmd/cseg_read.c
./raster/r.surf.contour/cmd/main.c
./raster/r.surf.idw/cmd/main.c
./raster/r.surf.idw2/cmd/read_cell.c
./raster/r.surf.idw2/cmd/main.c
./raster/r.thin/cmd/io.c
./raster/r.volume/cmd/centroids.c
./raster/r.volume/cmd/main.c
./raster/r.water.outlet/main.c
./raster/r.weight/inter/execute.c
./raster/wildfire/src/r.ros/main.c
./raster/wildfire/src/r.spread/collect_ori.c
./raster/wildfire/src/r.spread/main.c
./raster/wildfire/src/r.spreadpath/main.c
./raster/r.fill.dir2/r.fill.dir/cmd/fill_dir.c
./sites/s.sample/nearest.c
./sites/s.surf.idw/cmd/main.c
./sites/s.surf.idw/cmd/read_cell.c
Further modules:
- i.points3:
update to FP
- r.water.outlet
- needs FP update
- r.random.surface
needs to be updated to GRASS 5 FP/NULL
(being worked on by ?)
- r.water.outlet:
needs to be updated to GRASS 5 FP/NULL
(being worked on by ?)
- r.watershed:
needs to be *partly* updated to GRASS 5 FP/NULL:
Helena Mitasova wrote:
Drainage map should be INT, there is no reason for it to be FP
because the program uses D8 algorithm, there are only 8 directions
of flow. only L and S factor could be output as FP (here they are
multiplied by 100) but I am not sure whether it is worth the effort
because they are not very good anyway.
(being worked on by ?)
---------------------------------------------------------------------
TODO cont'ed...
Configure:
- clean up make variables in head.in etc. Things like
XDRLIB = @XDRLIB@ @ZLIBINCPATH@ @ZLIBLIBPATH@ @ZLIB@ $(XEXTRALIBS)
are confusing. Probably requires modification of all Gmakefiles (600+ ?)
A good time to do this is with the new Makefile system.
--------------------------------------------------------------------
Regression test suite:
- see testsuite/TODO !
(Being worked on by Andreas Lange)
--------------------------------------------------------------------
Font selection:
- add truetype support (replace old font system). This is urgently required
for internationalization.
Suggestion: Use "FreeType" http://freetype.sourceforge.net
or, better: VFlib: http://typehack.aial.hiroshima-u.ac.jp/VFlib/
(Being worked on by ?)
---------------------------------------------------------------------
Multiple languages support:
- use "gettext" (.po files)
http://www.gnu.org/software/gettext/gettext.html
(Being worked on by ?)
---------------------------------------------------------------------
Libraries:
- new 3D vector format: eventually http://gts.sourceforge.net/ ??
(Being worked on by David D Gray, Radim Blazek)
- optri replacement:
detri (http://www.geocities.com/mucke/GeomDir/detri.html)?
or gts (http://gts.sourceforge.net/)?
(Being worked on by ?)
- TIN support: Probably use this library:
http://www.cs.cmu.edu/~quake/triangle.html
(Being worked on by David D. Gray)
- Metadata: improved support, probably write a GRASS daemon serving
the metadata for external applications like "R" statistics interface
(Being worked on by ?)
- Parallel CPU support
(Being worked on by ?)
- data entry field for location and mapset
are 14 characters long. should be more.
(Being worked on by ?)
---------------------------------------------------------------------
Package concept:
- split into packages: GRASS-CORE, GRASS-Raster, ...
(Being worked on by ?)
- reorganize directory structure
(Being worked on by Markus et al.)
see documents/new_directory_structure.txt
---------------------------------------------------------------------
Lock system:
Comment:
Some lockfiles have to be global, just think of the number of
graphic display pipes used or physical inputs devices.
So two ways from there to improve the situation:
Make the locking executables setgid or setuid.
(and have just one executable doing the locking.)
And/or use the /tmp directory.
Localise all global lockable resources.
(Unlikely to work.)
Bernhard
(Being worked on by Eric Miller, related to sockets)
-> perhaps the lock files could go into
/var/grass5/locks
would be o.k. for Linux, AT&T SVR4 compliant OS (HP-UX, OSF/1, etc.)
but NOT SGI.
- this might be related to a daemon serving a session key (see there).
(Being worked on by ?)
---------------------------------------------------------------------
Code merge:
- r.univar: write C implementation
- reduce the number of import/export modules. Add a parameter for the file
format (or auto-detection) instead of having tons of modules. r.in.gdal
is on the right way
compare:documents/new_directory_structure.txt for file list
- r.reclass/r.reclass.scs
- ...
It is important to reduce the number of modules (not to overwhelm the
users as done now)
---------------------------------------------------------------------
Monitor/Xdriver:
- Display current map scale in monitor window top line (set by
xwindows name?) - use d.scale -i implementation
---------------------------------------------------------------------
Modules:
- all modules:
There should be a warning if overwriting existing maps in scripted
mode (see: documents/parameter_proposal.txt)
-IMPORT/EXPORT modules:
They should read/write from current directory instead of subdirectory
in mapset.
v.in.shape/v.out.shape and m.in.e00 already meet this convention.
(Being worked on by ?)
- Implement new G_readsites_xyz function into
src.contrib/CERL/sites/s.surf.krig/read_sites.c
src.contrib/GMSL/g3d/src3d/sites/s.to.rast3/read_sites.c
src.contrib/GMSL/g3d/src3d/sites/s.vol.idw/read_sites.c
src.contrib/NPS/v.circle/cmd/readsites.c
src.contrib/PURDUE/s.medp/readsites.c
src.garden/grass.rim/s.db.rim/cmd/read_sites.c
src.garden/grass.rim/s.db.rim/inter/read_sites.c
src/raster/r.surf.idw2/cmd/read_sites.c
src/sites/s.kcv/readsite.c
src/sites/s.menu/Lib/read_sites.c
src/sites/s.normal/readz.c
src/sites/s.probplt/readz.c
src/sites/s.qcount/readsite.c
src/sites/s.sample/readsite.c
src/sites/s.surf.idw/cmd/read_sites.c
src/sites/s.sv/readsite.c
src/sites/s.univar/readsite.c
src/mapdev/v.bubble/v.bubble.c
src/sites/*
All these files/functions should be replaced by the function
G_readsites_xyz() function with attribute selection etc.
(being worked by Eric G. Miller)
- d.legend:
- For categorical maps with more than 10 classes, where user
discrimination among colors becomes difficult, there should be a flash
utility. Based on d.legend ... we should be able to click on any legend
box and have the corresponding class flash on the map (on-off sequence
with user defined color).
(Being worked on by ?)
- d.mon:
if monitor is already in use, the next higher one should be tried instead
of just printing an error (x0 busy -> open x1 etc.). This would be nice in
network usage of GRASS.
(Being worked on by ?)
- g.manual: change list of manual pages in g.manual
organized according to objects (vector files, raster files, ...)
not to "status" of module (which is even confused at time)
(Being worked on by ?)
- i.rectify
- option 1 to transform the data should be extended: GRASS should
calculate from the original rows/cols and the target coordinates
the optimal resolution for the image to be rectified (round to nearest
.5). Example: take orig rows/cols, take target east-west, north-south
cal. target resolution, rectify.
This may become option 3 in menu.
- nviz2.2
- Z axis scalable when displaying 3D sites
(Being worked on by ?)
- fix legend, scale and box drawings
(Being worked on by Bill Brown, Helena Mitasova)
- see:
./src.contrib/GMSL/NVIZ2.2/src/TODO
./src.contrib/GMSL/NVIZ2.2/TODO.linux
./src.contrib/GMSL/NVIZ2.2/TODO
- r.in.hdf/r.out.hdf
- update to HDF 5
-> eventuall r.in.gdal?
(Being worked on by ?)
- r.info
should also report statistics (min, max, mean, stddev, 1st
quartile, median, 3rd quartile and sum)
(merge function of r.univar into r.info)
(Being worked on by ?)
- r.line
r.line properly extracts geometry, but it doesn't attach
any label to the vector file generated. I've read the manual page, but
it doesn't speaks about attributes. In my application I also need
attributes.
(reported by: Andrea Aime <aaime@comune.modena.it>)
Comment from David:
The problem with the r.line issue is that it is not immediately obvious
what should be assigned as an attribute, because attribute (and
category) values will depend largely on what produces the lines and what
information you would expect to get out of it, and this will vary with
usage.
The results of r.watershed was an example you gave. Also you might want
to autodigitise a raster layer from a drawing package (eg. gimp - the
new gimp is quite good at this as it handles large image files better).
This can produce good results with some care, though I don't know how
scalable it is. Another option might be to extract features from a
scanned map based on colour, such as rivers or contours (untested). The
different usages here mean that we would need different 'Methods' as
options for data extraction I think.
- r.proj
Idea: r.proj could be used for easy map copying between locations:
Morten Hulden <morten@ngb.se> wrote:
item: The idea (you mentioned some messages ago) of allowing r.proj and
(v.proj) to do lonlat->lonlat conversions by just copying the files is
something that needs more planning:
* First, lonlat handling is not part of the routines that pro handles in
grass. Many modules (or the wrapper part in them) check for 99 (other
projections) before passing the task to the proj dependent routines. The
reason is that grass is a patchwork of band-aid when it comes to projection
routines. The original projections XY, UTM, LL are handled separately and
the wrapper will not pass these to proj. UTM could well be handled by proj,
but often is not, because, like LL, it is one of the 'original' projections
that were there before '99 other' were added. So, letting proj do LL->LL
handling would require rewriting the 'wrapper' part of each module. It
should be done eventually, but in connection with clearing up the messy
handling of projection in grass.
* Second, sometimes there is a need to project LL->LL with different spheroid
or datum, and in these cases a simple copy is not what we want. Only if
spheroid and datum are the same on the input and output side should a
straight copy be done, I think.
- r.proj/v.proj/s.proj:
add -l flag to list relevant files in source location (source of
projection), r.proj done.
- r.reclass.pg
write it
(Being worked on by)
- r.surf.distance: write it
this module would generate a distance surface (improved version of
r.buffer) containing continuously distances from a raster line/area
Meanwhile r.buffer generates defined buffers, we need continuous
distance values, too.
(Being worked on by)
- r3.mapcalc:
add option to read 2D cells. Could be very useful to generate
mask etc.
- r3.timestamp: write it
(Being worked on by "Pelizzari, Michael" <michael.pelizzari@lmco.com> )
- v.buffer: write it
(Being worked on by ?)
- s.patch: write it
To merge to multi-dim/multi-attr site files is pretty difficult
by scripts. A module would be good idea.
(Being worked on by ?)
- v.cutter
improve it, add category "transport" to new file
- v.digit:
add an optional circle our mouse cursor with radius of snapping threshold
for digitizing
(Being worked on by ?)
- v.slabel: write it:
v.alabel does bulk labeling of areas, v.llable does bulk labeling of line
features. But there is no module to bulk label point features (site
vectors in GRASS terminology). This function is needed if you want to
intersect point features with area features (point-in-polygon test).
- v.support:
- add segmentation for large files
- speed up v.build
(Being worked on by David D. Gray)
- tcltkgrass:
- Change the tcltkgrass code so that lists of choices appear as
a list instead of needing to use a push button to create the
list. For example when using d.rast we must click a "Raster"
button to get a list of raster files instead of having the
raster files appear automatically when we call the d.rast
module from the menu (edit gui.tcl)
(Being worked on by ?)
- add nice icons for mostly used commands
- generate module windows by parser.c/XML
- integrate src/tcltkgrass/todo/r_mapcalc.tcl (map calculator)
---------------------------------------------------------------------
PostgreSQL/ODBC support:
- don't store host/database in .grassrc5, but in location itself
Then you can keep the settings along with your database for
convenience
- store a username/password pair in a "secured" file (that is, a file
read/writeable *only* by the user that owns it). The ~/.grass5rc file
must be readable by others if you allow access to a dataset.
---------------------------------------------------------------------
Parser support: A few programs could use G_parser but don't.
g.version
m.in.stf1.tape
p.chart
p.labels
r.agnps50.run
r.agnps50.view
v.in.tig.lndmk
i.rectify
---------------------------------------------------------------------
Numerical Recipes: removal of code:
From ddgray@armadce.demon.co.uk Tue Sep 26 22:31:31 2000
The following references to Numerical Recipes was found.
Change 6/2001: NR functions moved src/libes/gmath/
Shortlist.
*r.proj -> r.bilinear also provides bilinear interpolation
*r.param.scale -> unused
*d.param.scale -> unused
Details.
r.proj: Makes reference to algorithm in cmd/bilinear.c, I will have to
check that it is not the same code. I think the author just used the
maths from the book.
r.surf.fractal: Uses NR algorithm for fft in fft.c. As above.
r.surf.gauss: Uses NR algorithm for Gaussian random generator. As above
r.surf.random: As for r.surf.gauss but uses linear random generator.
i.cca : *PROBLEM*. Although `based on' Numerical Recipes routines, the
authors considered it covered by NR's copyright. See comments in
i.cca/cmd/jacobi.c. This is an eigenvector routine so can be replaced.
Similar considerations apply to i.pca, i.zc, i.fft and i.shape (in
src.contrib/CERL). These use either eigsrt (a simple routine for sorting
eigensystems), or fourn (for fast fourier transforms). These are easy to
replace.
r.param.scale, d.param.scale: These contain considerable tracts of NR
stuff, including the NR data types. They will require more work to
replace.
It's difficult to know how much more NR stuff there is around, as the
last two in particular don't acknowledge the NR dependency.
Can I suggest moving the last two at least to src.nonGPL, so that we can
retain a working copy of the functions till the offending routines can
be replaced, as they would be in the slot held by the existing modules.
The other routines require only minor modifications, so we can patch
them all sometime during the freeze.
[done.]
Regards
David
---------------------------------------------------------------------
Further local TODO files:
./src/libes/coorcnv/TODO
./src/libes/dbmi/clients/TODO
./src/libes/dbmi/drivers/odbc/TODO
./src/libes/dbmi/drivers/sqlbase/TODO
./src/libes/dbmi/lib/TODO
./src/libes/ogsf/TODO
./src/mapdev/v.area/TODO
./src/mapdev/v.db.reclass/TODO
./src/mapdev/v.in.shape/TODO
./src/mapdev/v.out.shape/TODO
./src/mapdev/v.to.db/TODO
./src/mapdev/v.to.sites/TODO
./src/raster/r.agnps50/TODO
./src/raster/r.circle/TODO
./src/raster/r.random.surface/TODO
./src/raster/r.to.sites/TODO
./src/raster/r.water.outlet/TODO
./src/sites/s.to.rast/TODO
./src/sites/s.to.vect/cmd/TODO
./src/sites/s.datum.shift/TODO
./src/tcltkgrass/docs/TODO.txt
./src.contrib/GMSL/g3d/src3d/raster/r3.showdspf.sgi/TODO
./src.garden/answers/src.answers/raster/r.fill.dir/TODO
./src.garden/grass.java/TODO
./src.garden/grass.postgresql/v.in.shape.pg/TODO
./src.garden/grass.postgresql/TODO
./src/tcltkgrass/todo
./src/scripts/contrib/r.out.arctiff/TODO
---------------------------------------------------------------------
New GRASS help system concept:
Andreas Lange <Andreas.Lange@Rhein-Main.de>
Re: [GRASS5] keep g.help ?
I recently discovered that the GRASS man pages/help system contain a lot
of information that is not included in the html-pages, e. g. "Glossary
of GIS Terms" etc.
I think that the organization of the help system (topic and task
oriented rather than sorted by module name) is a lot better than the
html-system.
For the GRASS/GIS beginner the html-pages are very confusing, because
one does not know how to find a certain functionality.
I can imagine a html-based help system that starts from the opening
screen in tcltkgrass. It should be possible to integrate html-output (or
xml) into tcltkgrass in a manner that allows to navigate the
documentation.
But all that would require someone who can update the contents and the
structure of the help system from roff to html.
So my conclusion is: Keep it for grass5.0stable as it is.
For grass5.1 we should discuss how this can be improved.
---------------------------------------------------------------------
New GRASS Startup concept:
Markus Neteler wrote:
> Now a menu would appear with following items:
>
> (1) Open existing session (using Justins forthcoming session manager)
> (2) Define new location (using Justins forthcoming definition manager)
> (3) Import data from file/cdrom... (using Frank Warmerdams GDAL import
> module and others) and define location on-the-fly from data
> settings
>
> As (1) and (2) are generally nothing new (except the new graphical
> layout), (3) would be very welcome. Here a general change in GRASS
> import modules (raster, vector and sites) would be required. Like
> commercial GIS software GRASS should be capable of defining a location
> while importing external data *without* additional user input.
> Technically it's possible in my opinion. The import module would
> read the projection/coordinates parameters from the spatial data file,
> generate the DEFAULT_WIND and other files (look into "testgrass.sh" how
> this can be done by script), create the location and import the data.
> Especially for new users this is much more convenient.
Frank Warmerdam wrote:
>I do have a version of r.in.gdal now working that includes an optional
>location parameter. If provided it will initialize a new location on
>the basis of the extents, projection and units of the dataset being
>read. However, this only works with GDAL supported datasets, so it
>isn't entirely general.
>Perhaps g.region could have an additional option to extend the current
>region bounds based on a scan of all raster, and vector extents in the
>mapset (or location)?
---------------------------------------------------------------------
Datum support:
- upgrade r.proj, s.proj, v.proj
- first implement latest PROJ4 as shared library
(Being worked on by Frank Warmerdam)
---------------------------------------------------------------------
Implement gdchart for nice charts:
http://www.fred.net/brv/chart/
