GRASS-Wiki - User contributions [en]

Development GEM

2006-08-22T14:19:36Z

⚠️Wegmann:

===GRASS add-on structure using GEM===

(copy from e-mail to dev List)

The following options are a sum-up of ideas concerning the GEM repository 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?)

Development

2006-08-22T14:18:35Z

⚠️Wegmann: moved GEM to new page with link

Development GEM

2006-08-22T14:15:04Z

⚠️Wegmann: moved GEM explanation to this page

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

Development

2006-08-22T14:11:49Z

⚠️Wegmann: /* Plans */ added GEM ideas from mail to dev ML

__TOC__

The GRASS GIS project is developed under the terms of the [http://www.gnu.org/copyleft/gpl.html GNU General Public License] (the GPL) [http://grass.ibiblio.org/devel/index.php in the open] by [http://grass.ibiblio.org/community/index.php volunteers] the [http://mapserver.gdf-hannover.de/grassusers/map.phtml world over].

=== Resources for Developers ===

==== Communication ====
* You can contact GRASS folks in [[How to participate in IRC communication|IRC]]
* [http://grass.itc.it/mailman/listinfo/grass-dev Developers mailing list]

==== Documentation ====
* [http://grass.itc.it/devel/index.php#prog GRASS Programming Manual]
* [[GRASS Programming Howto]] (partially outdated)
* [[Gis Concepts]] and how they are implemented in GRASS
* [[GRASS Debugging]]
* '''Code submission standards''':
** [http://grass.itc.it/grass61/source/SUBMITTING C language coding standards]
** [http://grass.itc.it/grass61/source/SUBMITTING_SCRIPTS Shell script coding standards]
** [http://grass.itc.it/grass61/source/SUBMITTING_TCLTK Tcl/Tk script coding standards]

==== Code ====
* [http://grass.ibiblio.org/devel/cvs.php CVS server] | [http://freegis.org/cgi-bin/viewcvs.cgi/ GRASS WebCVS interface] browsable source code repository
* [http://intevation.de/rt/webrt?q_queue=grass GRASS bug and wish tracking system]
* [[GRASS AddOns]] (User contributions)

==== Source code quality control ====
* [http://cia.navi.cx/stats/project/GRASS CIA commit bot] for realtime monitoring along with [http://grass.itc.it/mailman/listinfo/grass-commit grass-commit] mailing list (showing the diff's)
* [http://grass.itc.it/mailman/listinfo/grass-qa Code Quality Control System]
* [http://web.soccerlab.polymtl.ca/grass-evolution/grass-browsers/grass-index-en.html GRASS Software Evolution code analysis]
* [http://www-pool.math.tu-berlin.de/~soeren/grass/GRASS_TestSuite/ GRASS Test Suite] a small test suite for GRASS, the current html output is available [http://www-pool.math.tu-berlin.de/~soeren/grass/GRASS_TestSuite/html/ here] and with memory check [http://www-pool.math.tu-berlin.de/~soeren/grass/GRASS_TestSuite/html_memcheck/ here]

=== GRASS and QGIS ===

* [http://wiki.qgis.org/qgiswiki/BuildingWindowsBinaryOnLinux Building QGIS/GRASS Windows Binary On Linux] (using MinGW)
* [http://wiki.qgis.org/qgiswiki/Adding_New_Tools_to_the_GRASS_Toolbox Adding New Tools to the GRASS Toolbox]

=== GRASS License ===

* [http://en.wikipedia.org/wiki/Gpl WikiPedia entry discussing the GPL]

=== Plans ===

===== Overview =====

* [[Release Roadmap]]
* [http://grass.ibiblio.org/devel/roadmap.php Development Roadmap] ''(needs freshening)''
* [[GRASS Module Porting List]] (check here if you don't find a certain command in GRASS 6.0)
* [[GRASS ToDo List]] (overview of GRASS related community projects)
* [http://freegis.org/cgi-bin/viewcvs.cgi/grass6/doc/vector/TODO?rev=HEAD&content-type=text/vnd.viewcvs-markup GRASS 6-CVS Vector TODO]

===== Sandbox (ideas section) =====

* [[GRASS 7 ideas collection]]
* [[GRASS GUI]] development
* [http://wgbis.ces.iisc.ernet.in/grdss/index.php GRDSS (Geographic Resources Decision Support System)]
* Ideas on a [[replacement raster format]] specification
* add support (at least storage!) of vertical datum and units
* Discussion on [[Development Specs]] for standardized messages

=====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 ===
* [http://mpa.itc.it/markus/grass61progman/swig/ GRASS-SWIG interface]: generic interface to various languages
* [[GRASS and PHP]]
* [[GRASS and Python]]
* [[GRASS and Shell]]: Starting and running GRASS from a script
* [http://grass.itc.it/mailman/listinfo/grass-abm Integration of GRASS with JAVA based agent based modeling (ABM)]
* [http://www.hydrologis.com/html/jgrass/jgrass_en.html JAVAGRASS]

=== Related projects ===

* [http://www.hydrologis.com/html/jgrass/jgrass_en.html JGrass] - Java based frontend for GRASS incuding extended hydrological modelling tools
* [http://www.kergis.com/en/index.html KerGIS] - BSD-like licensed fork of GRASS 4.1.5

* [http://proj.maptools.org PROJ.4] - Cartographic Projections Library
* [http://www.gdal.org GDAL] - Geospatial Data Abstraction Library
* [http://www.qgis.org QGIS]- Quantum GIS

* [http://www.osgeo.org OSGeo]- The Open Source Geospatial Foundation
* [http://freegis.org FreeGIS.org] - Interactive information base for the GIS Free Software world

[[Category:Development]]