GRASS 7 ideas collection

Raster

Library

• Rewrite library from scratch. See suggestions

Modules

• Remove r.in.arc and r.out.arc, if a related bug in r.in.gdal is fixed. The integer/floating point detection for AAIGrid driver in GDAL was fixed after 1.3.2 release, so r.in.gdal and r.out.gdal should be enough now.

• 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

Vector

Modules

• rename v.mkgrid to v.grid

• Remove doubled units in v.to.db GUI

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

General

Library

• Add support for planetary bodies reference systems

Modules

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

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

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

• 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

Parser

• "Add another semantic meaning to the parser system for a type safe enumerated list" (Cedric's words commenting the bug that v.type doesn't allow for selecting input and output type in GUI

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

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)
• Easy development of custom GUI application based on GRASS

• Python?
• WxWidgets?
• Qt4

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