Difference between revisions of "GRASS 7 ideas collection"

From GRASS-Wiki
Jump to: navigation, search
(Modules)
(Modules)
Line 46: Line 46:
 
* add 'where=' to v.to.rast (why wait for GRASS 7 ??)
 
* add 'where=' to v.to.rast (why wait for GRASS 7 ??)
 
* implement Douglas-Peucker generalization ([http://www.ngdc.noaa.gov/mgg/shorelines/data/gshhs/version1.2/gshhs_dp.c C code file])to substitute prune tool of v.clean (why wait for GRASS 7 ??)
 
* implement Douglas-Peucker generalization ([http://www.ngdc.noaa.gov/mgg/shorelines/data/gshhs/version1.2/gshhs_dp.c C code file])to substitute prune tool of v.clean (why wait for GRASS 7 ??)
 +
* Rewrite vector labeling. Needs more placement control options (may be db field value based), label overlaping prevention would be also good. May be we could borrow some ideas from MapServer?
  
 
== General ==
 
== General ==

Revision as of 23:29, 15 February 2007

Raster

Library

Modules

  • Remove the code from r.info that makes it print projection information - we have g.region and g.proj for that. Moreover, r.info always prints a bogus (zone 0) information in non-UTM locations, which is confussing. See a bug report.
  • fix the raster map history management (truncating long history, odd storage). It should work like for vector maps in GRASS 6.
  • dispose r.resample and r.bilinear in favor of r.resamp.interp
  • merge r.surf.idw and r.surf.idw2
  • drop r.univar.sh; newly implemented r.univar features cover it
  • drop r.univar.sh; newly implemented r.univar features cover it
  • r.sum, r.mode, r.median, r.average, r.statistics, r.univar, r.univar2 - maybe they can be reduced to just r.statistics and r.univar? See RT #1848 and a thread on the GRASS dev list
  • Dispose r.out.tiff. New C r.out.gdal should cover all it's option now (doublecheck!). See RT #3680 (starting with date Sun, Nov 26 2006 14:54:23).
  • Remove remaining -v and -q flags for verbosity levels of modules.

Vector

Library

Modules

  • Fix the Column 'cat_' already exists (duplicate name) in v.in.ogr. Maybe by creating columns cat_1, cat_2 etc. each time a Grass vector is exported to shapefile and imported back to Grass?
  • write Vect_map_exists() and implement in g.remove and v.digit -n (why wait for GRASS 7 ??)
  • add '-d' dissolve to v.reclass
  • add 'where=' to v.to.rast (why wait for GRASS 7 ??)
  • implement Douglas-Peucker generalization (C code file)to substitute prune tool of v.clean (why wait for GRASS 7 ??)
  • Rewrite vector labeling. Needs more placement control options (may be db field value based), label overlaping prevention would be also good. May be we could borrow some ideas from MapServer?

General

Library

  • Add support for planetary bodies reference systems
  • Add new partial differential equation (PDE) library with OpenMP support

Modules

  • g.remove, g.mremove, g.rename, g.copy: don't allow for default datatype (which is currently raster) [1].
  • g.region

Database

Library

Modules

Imagery

Library

Do merge of image libraries:

  • A)
    • lib/imagery/: standard lib, in use (i.* except for i.points3, i.rectify3)
    • imagery/i.ortho.photo/libes/: standard lib, in use (i.ortho.photo, photo.*)
  • B)
    • lib/image3/: never finished improvement which integrated the standard lib and the ortho lib. Seems to provide also ortho rectification for satellite data (i.points3, i.rectify3)

Modules

  • merge of i.points, i.vpoints, i.points3
  • merge of i.rectify and i.rectify3
  • addition of new resampling algorithms such as bilinear, cubic convolution (take from r.proj?)
  • add other warping methods (maybe thin splines from GDAL?)
  • implement/finish linewise ortho-rectification of satellite data
  • Depreciate tape functions in next major revision of GRASS and create a tape module that accomplishes tape access.

Raster3D

Library

  • renaming of all G3D library functions to fulfil the grass coding standard
  • extent/rewrite documentation
  • localisation support (why wait for GRASS 7 ??)

Modules

  • report and support modules like r3.stats, r3.support
  • voxel -> vector (isosurfaces ...) and vector -> voxel (lines, faces, volumes) conversion modules
  • module for 3d Kriging interpolation based on vector points
  • a GRASS-Python/VTK visualisation/manipulation tool

Display

Modules

  • d.font etc.
    • Huidae Cho merged d.text.freetype and d.text into d.text.new; drop them and rename d.text.new into d.text
    • merge d.font and d.font.freetype too
  • d.vect
    • consolidate parameter names (attrcol, wcolumn, rgb_column)

Postscript

Modules

  • ps.map
    • remove scale parameter
    • rename sizecol to sizecolumn (remove the given warning)

Parser

  • Making GRASS modules be less verbose. Use --verbose flag and GRASS_VERBOSE environment variable. All output (G_message, G_percetn, G_warning) should go to GRASS_LOG file which could be grassdata/location/mapset/.grass.log by default.

Data management

  • store vertical units on per-map base, using code from units software
  • store vertical map datum on per-location base (GDAL/OGR needs the same enhancement)
  • add versioning for maps (to recover previous map versions)

Time series

Visualization

...

CLI

Fix the parameters and flags. Make it a concept. See proposal in GRASS 5 documents/parameter_proposal.txt

GUI

  • Multiplatform
  • Fast
  • Small on monitor
  • Number of window reduction
  • Managable from command line via d.* modules (which will have to be rewritten too)
  • Facilitating easy development of custom GUI application based on GRASS

Conceptual changes

  • File organization in binaries:
    • the grass etc dir is a mess... module should maintain arch-deps and arch-indep things in different paths -- frankie at #grass irc
    • it's basically a FHS violation, i dunno if it is reported by lintian, anyway /usr/lib/grass should be used for arch-deps data, not for mixed stuff -- frankie at #grass irc