Development

From GRASS-Wiki
Revision as of 14:11, 22 August 2006 by ⚠️Wegmann (talk | contribs) (→‎Plans: added GEM ideas from mail to dev ML)
Jump to navigation Jump to search


The GRASS GIS project is developed under the terms of the GNU General Public License (the GPL) in the open by volunteers the world over.

Resources for Developers

Communication

Documentation

Code

Source code quality control

GRASS and QGIS

GRASS License

Plans

Overview
Sandbox (ideas section)


GRASS add-on structure using GEM

(copy from e-mail to dev List)

The following options are a sum-up of ideas so that the GEM add-on structure plus svn(?) can be properly set-up.

Nomenclatur
  • main: path to GRASS-main code (restricted to GRASS-main developers)
  • add-on: path to additional function (moderated "public" develop.)
  • commands: well, single commands ...
  • packages: bunch of commands dealing with a certain issues


software constraints
  • migration to svn is necessary to have restricted/selective access for main and add-on


add-on manager (person)
  • an add-on manager who checks incoming commands/packages for their quality (code, help, man-pages)
  • a status for fresh commands would be good (fresh commands vs. "officially" accepted commands) -> how does R deal with it? Automated builds could be done on grass.itc.it along with a status page


GEM
  • packages installed via UI or CI via WWW or local
  • packages updated via UI or CI
  • packages afterwards permanently loaded in certain location/mapset and not in others
  • package removal from location/mapset


add-on structure

(I orientate myself on the R structure, because I am familiar with it and like it, if anybody else has different ideas, please feel free to discuss it)

  • setup of different packages for different topics (classif., hydro., landscape ecol., spatial model. etc. see below)
  • every command is assigned to a package, even the "old" one, just to keep the structure consistent (?) - assigned to package "base"?
  • r.*, v.*, i.* commands might be together in one package and installed simultaneously - no splitting between r./v./i. commands in separate packages
  • after loading in UI:

raster/package_name->command vector/package_name->command --> no merge inside "base" commands but in separate dir in UI

  • broad package topics for starting point; in the future further splitting might be necessary to keep it simple:
    • data handling
    • Geo-Statistics
    • GIS tasks
    • image classification
    • hydrology
    • spatial modelling
    • landscape ecology
    • fire modelling
    • bathymetry
    • data enhancement
    • ...

I would suggest to list all commands in the man pages with their package affiliation in brackets and not to list them only if package is loaded or in separate directory. An idea could be to assign 5 keywords to each command/man page from a list of key words (semi-automate?)

Linking GRASS to external languages

Related projects

  • JGrass - Java based frontend for GRASS incuding extended hydrological modelling tools
  • KerGIS - BSD-like licensed fork of GRASS 4.1.5
  • PROJ.4 - Cartographic Projections Library
  • GDAL - Geospatial Data Abstraction Library
  • QGIS- Quantum GIS
  • OSGeo- The Open Source Geospatial Foundation
  • FreeGIS.org - Interactive information base for the GIS Free Software world