$Id: TODO.txt,v 1.13 2002/01/22 04:50:47 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: - there is no facility to place the legend exactly on the screen and also control the size of the text and boxes d.frames is not adequate..finer control is needed - 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 ) 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 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" ) - 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 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/