GRASS 7 ideas collection: Difference between revisions

From GRASS-Wiki
Jump to navigation Jump to search
Line 86: Line 86:
* r.volume centroids parameter only makes a level one vector with no attribute table; module should be updated to GRASS 6 vector library)
* r.volume centroids parameter only makes a level one vector with no attribute table; module should be updated to GRASS 6 vector library)
* r.random should be split into 2 modules: one for generating a raster map with random points (alike v.random), and the other for sampling a raster map (alike v.what.rast). Vector functionality should be droped from r.random - a dupe of existing vector modules. -i and -z flags should be droped.
* r.random should be split into 2 modules: one for generating a raster map with random points (alike v.random), and the other for sampling a raster map (alike v.what.rast). Vector functionality should be droped from r.random - a dupe of existing vector modules. -i and -z flags should be droped.
* v.random -z: read zmin and zmax from region settings, drop zmin and zmax. I.e. treat Z coord same as X,Y.


==== Good coding practice ====
==== Good coding practice ====

Revision as of 16:45, 23 January 2011

Warning

Content to be moved to https://trac.osgeo.org/grass/wiki

 See also: http://trac.osgeo.org/grass/wiki/Grass7/NewFeatures

Maintenance of repository

For GRASS 7 development is used svn-trunk, for GRASS 6 development is used separated branch develbranch_6. 

  Planning is continued here: http://trac.osgeo.org/grass/wiki/Grass7Planning

Terminology

See GRASS 7 Terminology.

List of new features in GRASS 7 (already implemented)

See http://trac.osgeo.org/grass/wiki/Grass7/NewFeatures

API to access algorithms in modules

We need to better expose the "knowledge" which is contained at module level. We want to have it accessible via API, exposed in various programming languages such as C, Python, Perl, Java, ..

Update 1/2011: Python ctypes interface available

Raster

See also Replacement raster format.

Library


Raster map history:

  • In 7.0, the fields of the history structure are dynamically allocated. You have to use Rast_set_history() or Rast_format_history() to set fields. The the HIST_* constants have to be used.

Modules

rename

  • rename r.in.gdal to r.import - see discussion
  • rename r.out.gdal to r.export - see discussion
  • rename r.volume 'data' parameter to something more standard like 'input'

remove

see delta comment about r.out.tiff below, sometimes the simple stuff works best! --HB
Ditto.
  • remove r.resample and r.bilinear in favor of r.resamp.interp
TODO: double-check that r.resample is in fact fully replaced by 'r.resamp.interp's method=nearest'. ie check that an alternate useful method is not lost.
  • remove r.univar.sh; newly implemented r.univar features cover it done.
  • remove 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).
It might be worth keeping r.out.tiff! It makes a nice delta when things don't go well (eg QGIS bug#348) --HB
However: code duplication, maintenance overhead, user confussion (more entries in GUI, more manual pages, why are there modules doing the same?).
  • Remove remaining -v and -q flags for verbosity levels of modules.

Merge

while r.surf.idw will only output CELL maps, it is Very Fast. (or that is to say, r.surf.idw2 is Very Slow)
  • r.sum, r.average, r.median, have been removed, as equivalent functionality is available via r.statistics{,2,3}.
HB: eh? the options and algorithm are nothing alike.
MS: I meant that r.resamp.rst could be a subset of r.resamp.interp (yet another resampling algorithm next to nearest, bilinear, bicubic). I haven't considered that the number of rst options would make r.resamp.interp user interface much less clear. Maybe not such a good idea after all - user interface wise.
HB: just be careful that the GDAL version is as featureful and grid/cell center correct as the r.in.* versions. I suspect it might not be. r.in.wms needs further python rewrite with full XML and HTTP library support.
HB: why? they do two fundamentally different things, and both work quite nicely right now. One works in cell space, the other geographic space (especially for lat/lon).
MS: Right. The 2 modules do different things. But it would be usefull if r.grow supported distance in units and r.buffer in cells. Could both share same code for distance options?

fix

  • fix lseek() usage for Large File Support: see list of affected modules
  • fix the raster map history management (truncating long history, odd storage). It should work like for vector maps in GRASS 6.
  • r.volume centroids parameter only makes a level one vector with no attribute table; module should be updated to GRASS 6 vector library)
  • r.random should be split into 2 modules: one for generating a raster map with random points (alike v.random), and the other for sampling a raster map (alike v.what.rast). Vector functionality should be droped from r.random - a dupe of existing vector modules. -i and -z flags should be droped.
  • v.random -z: read zmin and zmax from region settings, drop zmin and zmax. I.e. treat Z coord same as X,Y.

Good coding practice

  • Input handling:
/* Define the different options */
input1               = G_define_standard_option(G_OPT_R_INPUT) ;
input1->key          = _("albedo");
input1->description  =_("Name of the Albedo map [0.0-1.0]");
input1->answer       =_("albedo");
input1->guisection   = _("Required");

In here you can find G_define_standard_option(G_OPT_R_INPUT) assuming already those: 

  input1->type       = TYPE_STRING;
  input1->required   = YES;
  input1->gisprompt  =_("old,cell,raster") ;

If your input is not required to run the module, you just create the following line: 

 input1->required   = NO;
  • In a similar way, metadata/history storage:
      G_short_history(result1, "raster", &history);
      G_command_history(&history);
      G_write_history(result1,&history);
  • This is the standard incantation, but I have to find timestamp(), and

more details metadata maybe like sensor type for a start, or source/origin of data... Can we make metadata having elements (history->processing, history->timestamp, history->source(or history->origin), etc?) then it could be filled up specifically.

  • Or color palettes application is nice:
/* Color table for biomass */
      G_init_colors(&colors);
      G_add_color_rule(0,0,0,0,1,255,255,255,&colors);
  • Changes (from Glynn):

I would prefer it if G_open_*_new() simply called G_fatal_error() themselves if an error occurred. It's not as if there's any reasonable alternative way to handle the error.

  • Changes:
     input = G_define_option(G_OPT_F(D?)_INPUT) ;
     input->key        =_("parameter");
     input->type       = TYPE_DOUBLE;
     input->required   = YES;
     input->gisprompt  =_("value, parameter");
     input->description=_("Value of the parameter");
     /*input->answer     =_("0.000");*/
     input->guisection = _("Required");

I could also think similarly for non-GRASS files actually (configuration files sometimes need to be loaded separately)

Vector

Radim's TODO list

Vector TODO list

  • Particularly important: "Keep topology and spatial index in file instead of in memory" --ML
  • v.in.ogr: split long boundaries to speed up topology cleaning. Implemented in GRASS 7, partial backport to GRASS 6.5 possible.
v.in.ogr speed comparison

Library

  • 2d 'vertical' vector data (e.g. Geologic Cross Sections)
  • implement transactions for geometry handling (esp. v.edit, v.digit and to avoid leftover files when a vector command fails)
  • Assume cat 0 as the first possible, instead of 1. GRASS has supported cat 0 since around 2005, but it hasn't been widely used. According to Radim, using cat 0 allows for exact mapping from OGR FID (which can be 0) to GRASS cat.
  • support for elliptical arcs, quadratic and cubic splines. Elliptical arcs or circular arcs are very common in Swiss survey data (Amtliche Vermessung)

Modules

rename

remove

merge

  • merge v.select and v.overlay
needs discussion, they are doing fundamentally different things --HB
See a feature request #506 in GForge.
see also v.rast.stats and v.what.rast.buffer addon

fix

  • 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 (done?, see also GSoC)
  • Rewrite vector labeling. Needs more placement control options (may be db field value based), label overlapping prevention would be also good. May be we could borrow some ideas from MapServer? (ongoing: v.label.sa)
  • v.what.vect - rename parameters "vector" to "map", "qvector" to "qmap"
  • v.type - change type= option to from= and to=.(code's already in there)

enhance

  • extend v.overlay to allow combination of all types (point, line, area)
  • v.category: add possibility to create new layer categories on the basis of a column in the table linked to an existing layer

General

Library

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

Modules

  • g.remove, g.mremove, g.rename, g.copy: don't allow for default datatype (which is currently raster) [1].
controversial, needs more discussion --HB
  • g.region
    • Glynn's notes - cleaning the print flags and new print= option
    • Support vector's 3rd dimension in g.region vect= [-a], [res=], like the 2d extents are (or should be) see trac #121

Database

Library

  • establish SQLite as default DBMI driver for vector attribute storage (DBF is too limited). done May 2008.

Modules

  • allow cross-mapset database access, i.e. parse the '@mapset' notation appended to vector names (requires access via possibly different DBMI drivers)

rename

  • rename db.in.ogr to db.import

Imagery

Page has been moved to Trac: http://trac.osgeo.org/grass/wiki/Grass7/ImageryLib

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

The page moved to Trac: http://trac.osgeo.org/grass/wiki/Grass7/DisplayLib

Postscript

Modules

ps.map

  • remove scale parameter
-> from the command line, not the map instruction

See also "New display architecture" comments above.

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.
less verbose: this is well underway in 6.3
Note warning and errors are already logged to GIS_ERROR_LOG (see variables.html)

Init shell and startup

  • .grassrc6 is not what you expect. It holds the g.gisenv GIS variables, it's not a shell script containing commands like .bashrc is.
Suggestion: We should change the name for 7.x. It isn't an "rc" file in the conventional sense.
Suggestion: make it even a $HOME/.grass7/ directory to store settings etc (e.g., from r.li and others)
  • It is asked to run GRASS in its own shell to avoid portability issues 1.
  • Eliminate Init.sh. Glynn explains on GRASS user ML: "Most of the environment can be set up through an e.g. /etc/env.d/grass script. The database, location and mapset can be set through g.mapset. The only slight subtlety is if you want multiple independent sessions, but that can be done with a fraction of the code in Init.sh."
  • Provide a mechanism (g.access option?) to enable r/w access for users in mapsets they don't own. So that it they don't need to hack lib/gis/mapset_msc.c. Glynn explains on GRASS user ML: "AFAICT, that restriction has been unnecessary ever since the lockfile was moved from the user's home directory to the mapset directory."
Actually, I (Glynn) no longer think it's that simple. If other users can create directories within your mapset, they can create directories which you cannot remove, and in which you cannot add, remove or modify files. And this is quite likely to happen: most users will have a umask of 0022 or worse, meaning that other users (i.e. you) cannot modify any files or directories which they create.

Data management

  • store vertical units on per-map base, using code from units software
Support for free form unit meta-data added in 6.3. I don't mind it as a guide, but we shouldn't be limited to units found in units. --HB
  • store vertical map datum on per-location base (GDAL/OGR needs the same enhancement)
This requires more discussion. I'm not sure it's a good idea to do this location-wide. --HB
On a per raster map basis done in 6.3 cvs.
  • add versioning for maps (to recover previous map versions)
see "v.info -h" ?

Time series

for example? r.rast4d

Visualization

  • better support for faces and kernels in libgis
not really Visualization, but....

CLI

Parameters standardization

Flags standardization

  • Get rid of 'quiet/verbose' flags, preparation in GRASS 6, e.g.:
    /* please, remove before GRASS 7 released */
    if(q->answer) {
        putenv("GRASS_VERBOSE=0");
        G_warning(_("The '-q' flag is superseded and will be removed "
            "in future. Please use '--quiet' instead"));
    }

GUI

  • Multiplatform
  • Fast, minimalist, number of windows reduced
  • Novice, ...., Expert profiles for the GUI (with reduced features), tailored for use cases, e.g. 3D models of a risk map,
  • link from application to the relevant wiki online support, so that non-programmers can contribute to GRASS support
  • compile wiki online content and help pages into a offline version of help pages for usage in GRASS without internet access.
  • Manageable also from command line via d.* modules
  • Facilitating easy development of custom GUI application based on GRASS
  • drop d.m √
  • drop gis.m √

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
  • Creating $HOME/.grass7 directory for √
    • Custom fonts
    • r.li and other modules temp. files
    • GEM addons installation √
    • Default path for custom scripts
    • Custom symbols and EPS fill patterns
    • Custom color maps
    • Add here new item...

User Wishes

This section is not really development related...

  • Create 3D animation w nviz showing GRASS 3D coolness. MarisN 12:00, 4 August 2006 (CEST)
  • here are some examples to get inspired (apparently that's already possible):
  • Convince the users to use ParaView [2] for sophisticated animations --huhabla 20:47, 14 August 2006 (CEST)
    • (Add support for Paraview in GDAL/OGR or add GDAL/OGR support in ParaView to read directly data from GRASS) see discussion
  • Or use VisIt software, it should be able to read GRASS maps directly via GDAL

Complete GRASS Test Suite

  • base a comprehensive test suite on Soeren's GRASS Test Suite
  • automated error checking on all modules to catch data corruption issues
Retrieved from "https://grasswiki.osgeo.org/w/index.php?title=GRASS_7_ideas_collection&oldid=12411"