Difference between revisions of "GRASS 7 ideas collection"

From GRASS-Wiki
Jump to: navigation, search
(Parser: Making modules be less verbose)
Line 106: Line 106:
* Number of window reduction
* Number of window reduction
* Managable from command line via d.* modules (which will have to be rewritten too)
* Managable from command line via d.* modules (which will have to be rewritten too)
* Easy development of custom GUI application based on GRASS
* [[GRASS and Python|Python]]?
* [[GRASS and Python|Python]]?

Revision as of 03:26, 25 October 2006




  • 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




  • rename v.mkgrid to v.grid
  • 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 ??)



  • Add support for planetary bodies reference systems


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






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)


  • 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



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


  • 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



  • 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


  • 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)




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


  • Multiplatform
  • Fast
  • Small on monitor
  • Number of window reduction
  • Managable from command line via d.* modules (which will have to be rewritten too)
  • 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