GRASS-Wiki - User contributions [en]

Team

2014-03-27T16:10:09Z

⚠️Jachym: Jachym updates

The GRASS GIS project is an international team effort with scientists and developers participating from various fields. Below is a list of the current team.

All general queries concerning GRASS should be addressed to the respective [http://grass.osgeo.org/support/mailing-lists/ GRASS mailing lists]. If you miss yourself or somebody else on the lists below, please feel free to edit this Wiki page or send mail to the [http://lists.osgeo.org/mailman/listinfo/grass-dev GRASS developers mailing list].
__TOC__
== Current contributors to the development of the GRASS code ==

In alphabetical order; see for example [http://www.ohloh.net/p/grass_gis/contributors here] for contribution statistics.

{| class="wikitable sortable" border="1" style="margin: 1em auto 1em auto; text-align:left"
| width=200px | [[Image:Grasslogo vector small.png|100px|center]]
| '''Anna Kratochvílová''': GRASS 7 wxGUI development, Prague, CZ, mail: [http://lists.osgeo.org/mailman/listinfo/grass-dev GRASS developers mailing list]

|-
| [[Image:benjamin.png|100px|center|center]]
| '''Benjamin Ducke''': extension manager, spatial statistics, archaeological applications, predictive modelling Location: Berlin, Germany, mail: [http://lists.osgeo.org/mailman/listinfo/grass-dev GRASS developers mailing list]

|-
| [[Image:Grasslogo vector small.png|100px|center]]
| '''Glynn Clements''': core development, UK, mail: [http://lists.osgeo.org/mailman/listinfo/grass-dev GRASS developers mailing list ]

|-
| [[Image:hamish.jpg|100px|center]]
| '''Hamish Bowman''': Development of display, PostScript, raster, and GPS modules as well as general sanitation of the code, help, and web pages. Location: Department of Marine Science, University of Otago. Dunedin, New Zealand mail: hamish_b AT yahoo com [http://hamish.bowman.googlepages.com/grassfiles http://hamish.bowman.googlepages.com/grassfiles]

|-
| [[Image:helena.jpg|100px|center]]
| '''Helena Mitasova''': surface and volume modeling and analysis (RST modules), topographic analysis, hydrologic and erosion modelling, assistance with visualization, working with students on new module development, testing, and bug fixing Location: Raleigh, North Carolina, USA, mail: [http://lists.osgeo.org/mailman/listinfo/grass-dev GRASS developers mailing list ][http://www4.ncsu.edu/~hmitaso/ http://www4.ncsu.edu/~hmitaso/]

|-
| [[Image:hellik.png|100px|center]]
| '''Helmut Kudrnovsky''': [http://grass.osgeo.org/grass64/binary/mswindows/native/ winGRASS packaging],german translation, Austria, mail: [http://lists.osgeo.org/mailman/listinfo/grass-dev GRASS developers mailing list]

|-
| [[Image:lucadelu.png|100px|center]]
| '''Luca Delucchi''': Python GRASS development (GUI and Modules), Documentation, Italian Translation, Location: Trento (Italy), mail: [http://lists.osgeo.org/mailman/listinfo/grass-dev GRASS developers mailing list]

|-
| [[Image:Maris_nartiss.jpg|100px|center]]
| '''[[user:MarisN|Maris Nartiss]]''': Tcl/TK GUI development, Latvia, mail: [http://lists.osgeo.org/mailman/listinfo/grass-dev GRASS developers mailing list]

|-
| [[Image:Grasslogo vector small.png|100px|center]]
| '''Markus Metz''': GRASS 7 development, massive data processing, vector library, Italy + Germany, mail: [http://lists.osgeo.org/mailman/listinfo/grass-dev GRASS developers mailing list]

|-
| [[Image:markus.jpg|100px|center]]
| '''Markus Neteler''': various contributions, coordination, main Web site and mailing lists maintenance, Location: Trento, Italy, mail: [http://lists.osgeo.org/mailman/listinfo/grass-dev GRASS developers mailing list], IRC Nick: markusN [http://www.grassbook.org/neteler/ http://www.grassbook.org/neteler/]

|-
| [[Image:mlanda.png|100px|center]]
| '''Martin Landa''': various contributions, vector engine improvements, [[wxGUI]], Location: Prague, Czech Republic Mail: landa.martin AT gmail.com Homepage: [http://geo.fsv.cvut.cz/~landa http://geo.fsv.cvut.cz/~landa]

|-
| [[Image:michael.jpg|100px|center]]
| '''Michael Barton ''': GRASS native GUI development Location: Tempe, Arizona, USA mail: [http://lists.osgeo.org/mailman/listinfo/grass-dev GRASS developers mailing list ][http://www.public.asu.edu/~cmbarton/ http://www.public.asu.edu/~cmbarton/]

|-
| [[Image:Grasslogo vector small.png|100px|center]]
| '''Moritz Lennert''': display tools, mail: [http://lists.osgeo.org/mailman/listinfo/grass-dev GRASS developers mailing list]

|-
| [[Image:Grasslogo vector small.png|100px|center]]
| '''Soeren Gebbert''': improvements of [http://www-pool.math.tu-berlin.de/~soeren/grass/ 3D functionality] mail: [http://lists.osgeo.org/mailman/listinfo/grass-dev GRASS developers mailing list]

|-
| [[Image:Grasslogo vector small.png|100px|center]]
| '''Stepan Turek''': GRASS 7 wxGUI development, Prague, CZ, mail: [http://lists.osgeo.org/mailman/listinfo/grass-dev GRASS developers mailing list]

|-
| [[Image:Grasslogo vector small.png|100px|center]]
| '''Vaclav Petras''': GRASS 7 wxGUI development, Prague, CZ, mail: [http://lists.osgeo.org/mailman/listinfo/grass-dev GRASS developers mailing list]

|-
| [[Image:Grasslogo vector small.png|100px|center]]
| '''William Kyngesburye''': [http://www.kyngchaos.com/software:grass/ Mac OS X packaging], USA, mail: [http://lists.osgeo.org/mailman/listinfo/grass-dev GRASS developers mailing list]

|-
| [[Image:Grasslogo vector small.png|100px|center]]
| '''Yann Chemin''': image processing, mail: [http://lists.osgeo.org/mailman/listinfo/grass-dev GRASS developers mailing list]

|-
| [[Image:Grasslogo vector small.png|100px|center]]
| '''''your name''': what-you-do, Location: xyz, mail: [http://lists.osgeo.org/mailman/listinfo/grass-dev GRASS developers mailing list], link: ''

|}

== Former or currently inactive developers ==

(in alphabetical order)

{| class="wikitable sortable" border="1" style="margin: 1em auto 1em auto; text-align:left"
| width=200px | [[Image:Grasslogo vector small.png|100px|center]]
| '''Bob Covill''' Role: visualization, mail: [http://lists.osgeo.org/mailman/listinfo/grass-dev GRASS developers mailing list ]

|-
| [[Image:Grasslogo vector small.png|100px|center]]
| '''Brad Douglas''' Role: bug fixing, code portability, imagery modules Location: Fremont, California, USA, IRC Nick: bdouglas, mail: rez AT touchofmadness com

|-
| [[Image:cedric.jpg|100px|center]]
| '''Cedric Shock''' Role: user interface enhancements, debugging Location: Eugene, Oregon, USA, mail: [http://lists.osgeo.org/mailman/listinfo/grass-dev GRASS developers mailing list], [http://www.shockfamily.net/cedric/ http://www.shockfamily.net/cedric/]

|-
| [[Image:DaveSampson.png|100px|center]]
| '''Dave Sampson''' Role: tutorials, data sets & public data licensing, GRASS map gallery, Ottawa Chapter of OSGeo, Location: Ottawa, Ontario, Canada, mail: samper.d at gmail dot com [http://davidsampson.ca/ http://davidsampson.ca]

|-
| [[Image:Grasslogo vector small.png|100px|center]]
| '''Huidae Cho''' Role: bug fixing, hydrologic modeling (TOPMODEL modules), DXF modules, FreeType support. Location: Fairfax, Virginia, USA mail: grass4u AT gmail com, IRC Nick: grass4u [http://geni.ath.cx/ http://geni.ath.cx]

|-
| [[Image:jachym.png|100px|center]]
| '''Jachym Cepicky''' Role: bug fixing, support of 3D vectors, tester and translator, UI developer, Czech Republic, mail: jachym.cepicky AT gmail.com [http://les-ejk.cz/ http://les-ejk.cz/]

|-
| [[Image:Grasslogo vector small.png|100px|center]]
| '''Jaroslav Hofierka''' Role: development of modules for solar irradiation, flow routing, surface and volume modelling and analysis (RST modules), hydrologic and erosion modelling, assistance with visualization Location: Presov, Slovakia, mail: [http://lists.osgeo.org/mailman/listinfo/grass-dev GRASS developers mailing list ]

|-
| [[Image:maciek.png|100px|center]]
| '''Maciej Sieczka''' Role: power user, testing Location: Wroclaw, Poland, mail: msieczka AT sieczka.org [http://www.sieczka.org/ http://www.sieczka.org]

|-
| [[Image:Grasslogo vector small.png|100px|center]]
| '''Marco Pasetti''' Role: Microsoft Windows native binary port of GRASS Location: Brescia, Italy, mail: [http://lists.osgeo.org/mailman/listinfo/grass-dev GRASS developers mailing list], link: [http://grass.osgeo.org/grass64/binary/mswindows/native/ WinGRASS Project Homepage]

|-
| [[Image:Grasslogo vector small.png|100px|center]]
| '''Paul Kelly''' Role: Proj integration, mail: [http://lists.osgeo.org/mailman/listinfo/grass-dev GRASS developers mailing list ]

|-
| [[Image:radim.jpg|100px|center]]
| '''Radim Blazek''' Role: DBMI, vector engine core developer, Location: Trento, Italy till 2006, mail: [http://lists.osgeo.org/mailman/listinfo/grass-dev GRASS developers mailing list]

|-
| [[Image:scott.jpg|100px|center]]
| '''Scott Mitchell''' Role: tutorial and documentation development, web site maintenance, Ottawa User's Group, OSGeo Journal News and Events Editor Location: Ottawa, Ontario, Canada, mail: [http://lists.osgeo.org/mailman/listinfo/grass-web GRASS web site maintenance mailing list] [http://www.carleton.ca/~smitch http://www.carleton.ca/~smitch]

|}

== The following institutions are currently supporting the GRASS-Project ==

Please see our [http://grass.osgeo.org/donations/ GRASS sponsoring] page.

And a ''thank-you'' to:

* the many people who have contributed in the past
* the various users who have contributed bug reports and tested unstable GRASS versions;
* all the sites (and the people behind them) that provide mirrors for the GRASS web pages.

GRASS Propaganda

2008-02-13T08:33:53Z

⚠️Jachym: /* Debian GRASS */

Unofficial GRASS Banners, wallpapers and other art.

See also [[Promotional material]]

= Wallpapers =
Make your own GIS desktop!

==== Debian GRASS ====
This wallpaper is based on one old Debian wallpaper.
[[Image:Debian073-grass.jpg]]

File:Debian073-grass.jpg

2008-02-13T08:33:03Z

⚠️Jachym: GRASS Wallpaper based on old Debian one.

GRASS Wallpaper based on old Debian one.

Screenshot suggestions

2007-10-04T12:14:11Z

⚠️Jachym: /* Web Services */

Please put suggestions for screenshots to go onto the main website on this page. You can post URLs or [[Special:Upload|upload images]] directly to the wiki.

'''Note that all screenshots are to be licensed under the [http://creativecommons.org/ Creative Commons] [http://creativecommons.org/licenses/by-sa/2.5/ Attribution ShareAlike 2.5] License.'''

Here is the new work-in-progress screenshots page:
* http://grass.itc.it/screenshots/

Stuff still to merge & places to draw from:
* Old screenshots from the website [grass6?/screenshots/]
** http://freegis.org/cgi-bin/viewcvs.cgi/web/grass60/screenshots/
** http://freegis.org/cgi-bin/viewcvs.cgi/web/grass61/screenshots/
** http://freegis.org/cgi-bin/viewcvs.cgi/web/grass63/screenshots/
* stuff in the main website images/ dir (mostly GRASS 5 shots)
** http://freegis.org/cgi-bin/viewcvs.cgi/web/images/
* Screenshots from http://www.osgeo.org/grass/
* The wiki image [[Special:Log/upload|upload log]]
* Old GRASSNews and OSGeo journal articles
* Scans of old GRASS-Clippings articles?

Subcategories are:
== User Interface ==

=== Startup screen ===

* Mapset picker
* Define new location by EPSG & custom params
* Markus has some on the [[FOSS4G2007 IntegrationShowcase]] wiki page

=== TclTk GUI ===

* GUI and tools in action

=== wxPython interface ===

* GIS manager
* module window

== Platforms ==

=== Linux ===
=== Mac ===
=== Windows ===
=== Handhelds ===

== Raster map operations ==

-

== Vector map operations ==

-

== Image Processing ==

* clustering
* sat img edge detection (Markus posted one recently)
* i.landsat.rgb trials (from Hamish's website)
?

== Remote Sensing and LIDAR ==

=== Satellite Data ===
MODIS, Quickbird, etc, I thought to put some sites/vector points stuff here too. Maybe split that out into its own category?

=== LIDAR and Sonar Data ===
* Jockey's Ridge
* gdalwarping of sidescan sonar track?

=== Sites (point) data ===
* where to put this?

== 3D Visualization ==

* NVIZ, r3.out.vtk, ...
* MARS MOLA data (Hamish has one)

== Cartography ==
(aim for publication quality)

* ps.map, nice PS,PNG driver renders
** I do not know, if it suits, but this I got some time ago with pure ps.map [[http://wwwold.fle.czu.cz/~jachym/img/grass/krkonose_prehledka.jpg]]
* (TODO) Post ps.map instructions for the Norway geo map to the ps.map example page on the wiki.

== Web Services ==

* Markus's PHP earthquake map
* Jachym's contibutions
** PyWPS
** The new one
** There is a lot of the stuff
*** http://www.bnhelp.cz/mapserv/pokusy/OpenLayers/jachym/openlayers/examples/wps.html
*** http://pywps.ominiverdi.org - more stuff
*** http://www.bnhelp.cz/mapserv/pokusy/openlayers/bonifacio
* r.in.wms

== Modeling and Statistics ==
''this sections needs a better title''

* Dylan's Speafish bugsites cluster plot
* Some R variograms etc

== Animations ==

=== 2D MPEGs ===
(r.out.mpeg et al)

* old MPEG-1 canyon fly through
* Bob Covill had some ETOPO5 world bathymetry fly throughs

=== 3.5 and 4D ===

* moving NVIZ cutting planes

== More sections? ==

Feel free to suggest something.

Screenshot suggestions

2007-10-04T12:12:05Z

⚠️Jachym: some screenshot added

Please put suggestions for screenshots to go onto the main website on this page. You can post URLs or [[Special:Upload|upload images]] directly to the wiki.

'''Note that all screenshots are to be licensed under the [http://creativecommons.org/ Creative Commons] [http://creativecommons.org/licenses/by-sa/2.5/ Attribution ShareAlike 2.5] License.'''

Here is the new work-in-progress screenshots page:
* http://grass.itc.it/screenshots/

Stuff still to merge & places to draw from:
* Old screenshots from the website [grass6?/screenshots/]
** http://freegis.org/cgi-bin/viewcvs.cgi/web/grass60/screenshots/
** http://freegis.org/cgi-bin/viewcvs.cgi/web/grass61/screenshots/
** http://freegis.org/cgi-bin/viewcvs.cgi/web/grass63/screenshots/
* stuff in the main website images/ dir (mostly GRASS 5 shots)
** http://freegis.org/cgi-bin/viewcvs.cgi/web/images/
* Screenshots from http://www.osgeo.org/grass/
* The wiki image [[Special:Log/upload|upload log]]
* Old GRASSNews and OSGeo journal articles
* Scans of old GRASS-Clippings articles?

Subcategories are:
== User Interface ==

=== Startup screen ===

* Mapset picker
* Define new location by EPSG & custom params
* Markus has some on the [[FOSS4G2007 IntegrationShowcase]] wiki page

=== TclTk GUI ===

* GUI and tools in action

=== wxPython interface ===

* GIS manager
* module window

== Platforms ==

=== Linux ===
=== Mac ===
=== Windows ===
=== Handhelds ===

== Raster map operations ==

-

== Vector map operations ==

-

== Image Processing ==

* clustering
* sat img edge detection (Markus posted one recently)
* i.landsat.rgb trials (from Hamish's website)
?

== Remote Sensing and LIDAR ==

=== Satellite Data ===
MODIS, Quickbird, etc, I thought to put some sites/vector points stuff here too. Maybe split that out into its own category?

=== LIDAR and Sonar Data ===
* Jockey's Ridge
* gdalwarping of sidescan sonar track?

=== Sites (point) data ===
* where to put this?

== 3D Visualization ==

* NVIZ, r3.out.vtk, ...
* MARS MOLA data (Hamish has one)

== Cartography ==
(aim for publication quality)

* ps.map, nice PS,PNG driver renders
** I do not know, if it suits, but this I got some time ago with pure ps.map [[http://wwwold.fle.czu.cz/~jachym/img/grass/krkonose_prehledka.jpg]]
* (TODO) Post ps.map instructions for the Norway geo map to the ps.map example page on the wiki.

== Web Services ==

* Markus's PHP earthquake map
* Jachym's contibutions
** PyWPS
** The new one
* r.in.wms

== Modeling and Statistics ==
''this sections needs a better title''

* Dylan's Speafish bugsites cluster plot
* Some R variograms etc

== Animations ==

=== 2D MPEGs ===
(r.out.mpeg et al)

* old MPEG-1 canyon fly through
* Bob Covill had some ETOPO5 world bathymetry fly throughs

=== 3.5 and 4D ===

* moving NVIZ cutting planes

== More sections? ==

Feel free to suggest something.

Screenshot suggestions

2007-10-04T12:10:34Z

⚠️Jachym: /* Cartography */

Please put suggestions for screenshots to go onto the main website on this page. You can post URLs or [[Special:Upload|upload images]] directly to the wiki.

'''Note that all screenshots are to be licensed under the [http://creativecommons.org/ Creative Commons] [http://creativecommons.org/licenses/by-sa/2.5/ Attribution ShareAlike 2.5] License.'''

Here is the new work-in-progress screenshots page:
* http://grass.itc.it/screenshots/

Stuff still to merge & places to draw from:
* Old screenshots from the website [grass6?/screenshots/]
** http://freegis.org/cgi-bin/viewcvs.cgi/web/grass60/screenshots/
** http://freegis.org/cgi-bin/viewcvs.cgi/web/grass61/screenshots/
** http://freegis.org/cgi-bin/viewcvs.cgi/web/grass63/screenshots/
* stuff in the main website images/ dir (mostly GRASS 5 shots)
** http://freegis.org/cgi-bin/viewcvs.cgi/web/images/
* Screenshots from http://www.osgeo.org/grass/
* The wiki image [[Special:Log/upload|upload log]]
* Old GRASSNews and OSGeo journal articles
* Scans of old GRASS-Clippings articles?

Subcategories are:
== User Interface ==

=== Startup screen ===

* Mapset picker
* Define new location by EPSG & custom params
* Markus has some on the [[FOSS4G2007 IntegrationShowcase]] wiki page

=== TclTk GUI ===

* GUI and tools in action

=== wxPython interface ===

* GIS manager
* module window

== Platforms ==

=== Linux ===
=== Mac ===
=== Windows ===
=== Handhelds ===

== Raster map operations ==

-

== Vector map operations ==

-

== Image Processing ==

* clustering
* sat img edge detection (Markus posted one recently)
* i.landsat.rgb trials (from Hamish's website)
?

== Remote Sensing and LIDAR ==

=== Satellite Data ===
MODIS, Quickbird, etc, I thought to put some sites/vector points stuff here too. Maybe split that out into its own category?

=== LIDAR and Sonar Data ===
* Jockey's Ridge
* gdalwarping of sidescan sonar track?

=== Sites (point) data ===
* where to put this?

== 3D Visualization ==

* NVIZ, r3.out.vtk, ...
* MARS MOLA data (Hamish has one)

== Cartography ==
(aim for publication quality)

* ps.map, nice PS,PNG driver renders
** I do not know, if it suits, but this I got some time ago with pure ps.map http://wwwold.fle.czu.cz/~jachym/img/grass/krkonose_prehledka.jpg
* (TODO) Post ps.map instructions for the Norway geo map to the ps.map example page on the wiki.

== Web Services ==

* Markus's PHP earthquake map
* Jachym's contibutions
** PyWPS
** The new one
* r.in.wms

== Modeling and Statistics ==
''this sections needs a better title''

* Dylan's Speafish bugsites cluster plot
* Some R variograms etc

== Animations ==

=== 2D MPEGs ===
(r.out.mpeg et al)

* old MPEG-1 canyon fly through
* Bob Covill had some ETOPO5 world bathymetry fly throughs

=== 3.5 and 4D ===

* moving NVIZ cutting planes

== More sections? ==

Feel free to suggest something.

GRASS 7 ideas collection

2007-05-22T05:18:28Z

⚠️Jachym: /* Conceptual changes */

== Raster ==

=== Library ===

* Split libgis into G_() part and Rast_() part
* Rewrite library from scratch. See [http://grass.itc.it/pipermail/grass-dev/2006-August/025025.html suggestions]
* Insert 'vertical' 2d rasters (e.g. [http://woodshole.er.usgs.gov/project-pages/longislandsound/images/Ghist_square2.jpg geophysical survey data])
* [http://freegis.org/cgi-bin/viewcvs.cgi/grass/gips/gip-0002.txt?rev=HEAD&content-type=text/vnd.viewcvs-markup GRASS raster "live links" via GDAL]

=== Modules ===

* Remove r.in.arc and r.out.arc, '''if''' a [http://intevation.de/rt/webrt?serial_num=4897 related bug in r.in.gdal] is fixed. The [http://bugzilla.remotesensing.org/show_bug.cgi?id=1071 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 [http://intevation.de/rt/webrt?serial_num=3054 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

* r.sum, r.mode, r.median, r.average, r.statistics, r.univar, r.univar2 - maybe they can be reduced to just r.statistics and r.univar? See [http://intevation.de/rt/webrt?serial_num=1848 RT #1848] and a [http://grass.itc.it/pipermail/grass-dev/2006-November/027665.html thread on the GRASS dev list]

* Dispose r.out.tiff. New C r.out.gdal should cover all it's option now (doublecheck!). See [http://intevation.de/rt/webrt?serial_num=3680 RT #3680] (starting with date Sun, Nov 26 2006 14:54:23).

* Remove remaining -v and -q flags for verbosity levels of modules.

* fix lseek() usage for Large File Support: see [http://grass.itc.it/pipermail/grass-dev/2006-December/028231.html list of affected modules]

* r.resamp.rst: make resolution management identical to the other modules

== Vector ==
=== Library ===
* 2d 'vertical' vector data (e.g. [http://sofia.usgs.gov/publications/maps/florida_geology/Txsectionbh.jpg Geologic Cross Sections])
* implement transactions for geometry handling (esp. v.edit, v.digit and to avoid leftover files when a vector command fails)

=== Modules ===

* rename v.mkgrid to v.grid
* merge v.select and v.overlay
* Remove [http://intevation.de/rt/webrt?serial_num=3600 doubled units in v.to.db GUI]

* Fix the [http://intevation.de/rt/webrt?serial_num=3623 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 ([http://www.ngdc.noaa.gov/mgg/shorelines/data/gshhs/ C code file])to substitute prune tool of v.clean (why wait for GRASS 7 ??)
* Rewrite vector labeling. Needs more placement control options (may be db field value based), label overlaping prevention would be also good. May be we could borrow some ideas from MapServer?
* v.what.vect - rename parameters "vector" to "map", "qvector" to "qmap"
* drop v.univar.sh; newly implemented v.univar features cover it

== General ==
=== Library ===
* Add support for planetary bodies reference systems
* Add new partial differential equation (PDE) library with OpenMP support

=== Modules ===

* g.remove, g.mremove, g.rename, g.copy: don't allow for default datatype (which is currently raster) [http://intevation.de/rt/webrt?serial_num=3009].
* g.region
** [http://grass.itc.it/pipermail/grassuser/2007-February/038337.html Glynn's notes] - cleaning the print flags and new <tt>print=</tt> option

== Database ==
=== Library ===
=== Modules ===

== 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
* Depreciate tape functions in next major revision of GRASS and create a tape module that accomplishes tape access.

== 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 ===
* d.font etc.
** 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
* d.vect
** consolidate parameter names (attrcol, wcolumn, rgb_column)

== Postscript ==
=== Modules ===
* ps.map
** remove scale parameter
** rename sizecol to sizecolumn (remove the given warning)

== Parser ==

* "Add another semantic meaning to the parser system for a type safe enumerated list" (Cedric's words commenting the bug that [http://intevation.de/rt/webrt?serial_num=2969 '''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 [http://www.gnu.org/software/units/ units] software
* store vertical map datum on per-location base (GDAL/OGR needs the same [http://lists.maptools.org/pipermail/gdal-dev/2005-October/006857.html enhancement])
* add versioning for maps (to recover previous map versions)

== Time series ==

* Implement better [[Time series in GRASS]] support (series of satellite data etc)

== Visualization ==

...

== CLI ==

Fix the parameters and flags. Make it a concept. See proposal in GRASS 5 [http://freegis.org/cgi-bin/viewcvs.cgi/grass/documents/parameter_proposal.txt?rev=HEAD&content-type=text/vnd.viewcvs-markup 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)
* Facilitating easy development of custom GUI application based on GRASS

* [[GRASS and Python|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 -- <cite> frankie at #grass irc</cite>
** 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 -- <cite> frankie at #grass irc</cite>
* Creating $HOME/.grass directory for
** Custom fonts
** R.li and other modules temp. files
** Gem addons installation
** Default path for custom scripts
** Add here new item

[[Category:Development]]
[[Category:Release Roadmap]]

AddOns

2007-03-22T16:44:48Z

⚠️Jachym: /* Raster add-ons */

This page contains references to user contributions and add-ons (the original GRASS GIS software can be downloaded [http://grass.itc.it/download/index.php here]).

__TOC__

==Copyright and licensing information==

''Please be sure to include copyright and licensing information in the header comments of your code so that others may know how they can use, extend, modify, and redistribute your work.''

e.g. at the top of a shell script:
<pre>
#!/bin/sh
############################################################################
#
# MODULE: v.in.e00
#
# AUTHOR(S): Markus Neteler, Otto Dassau
#
# PURPOSE: Import E00 data into a GRASS vector map
# Imports single and split E00 files (.e00, .e01, .e02 ...)
#
# COPYRIGHT: (c) 2004, 2005 GDF Hannover bR, http://www.gdf-hannover.de
#
# This program is free software under the GNU General Public
# License (>=v2). Read the file COPYING that comes with GRASS
# for details.
#
#############################################################################
#
# REQUIREMENTS:
# - avcimport: http://avce00.maptools.org

[script follows]
</pre>

==Shell script coding standards==

Please have a look at our [http://grass.itc.it/grass63/source/SUBMITTING_SCRIPTS Shell script coding standards] before submitting here.

==Miscellaneous Add-ons==

* [http://bambi.otago.ac.nz/hamish/grass/utm_which_zone.sh utm_which_zone.sh] is a shell script to determine UTM zone from Lat/Lon input. Requires [http://www.octave.org Octave] to be installed. A shell-only version is [http://dcalvelo.free.fr/grass/utm_which_zone_sh.sh available] which only requires awk. '''Authors''': Hamish Bowman (Octave part), Markus Neteler (shell script wrapper), Daniel Calvelo (sh+awk version)

* Perl scripts for converting data forth and back between Excel files and PostgreSQL: [http://dcalvelo.free.fr/grass/pg2xls.pl pg2xls.pl] reads data from PostgreSQL and produces an excel workbook; [http://dcalvelo.free.fr/grass/xls2sql.pl xls2sql.pl] reads excel files and outputs SQL statements to be fed into an RDBMS. Both scripts need modules from [http://www.cpan.org CPAN], especially [http://search.cpan.org/dist/Spreadsheet-ParseExcel/ Spreadsheet::ParseExcel] for xls2sql.pl and [http://search.cpan.org/~tmtm/Spreadsheet-WriteExcel-FromDB Spreadsheet::WriteExcel::FromDB] and its dependencies for pg2sql.pl. Check the source headers for more info. '''Authors:''' Daniel Calvelo (xls2sql.pl), Markus Neteler (pg2xls.pl)

* [http://dream.lrrl.arch.tu-muenchen.de/~wqual/perl/dbf2sql.tgz dbf2sql] is a Perl script for translating dbf-tables into a sql-command. dbf-tables are read using dbfdump-command from dbd-xbase-perl module ([http://search.cpan.org/~janpaz/DBD-XBase-0.241/ dbd::xbase] and [http://search.cpan.org/~jv/Getopt-Long-2.35/lib/Getopt/Long.pm getopt::long] have to be installed from CPAN first). There are problems, if the last column of the table contains characters. Suggestions for improvements welcome! '''Author:'''Wolfgang Qual

* [http://www.igc.usp.br/pessoais/guano/downloads/azimuth2.c azimuth2.c] is a small C program to calculate the azimuth and length of vector lines exported by GRASS-GIS as ASCII files (like this: v.out.ascii input=vector output=ascii format=standard). It is useful for create rose diagrams of lineament maps. Improvements on the original code after suggestions by Örs Téglásy, Hungary. '''Author:''' Carlos Henrique Grohmann

==GRASS 5.x==

===Vector add-ons for GRASS 5===

* See here: http://grass.itc.it/download/addons.php

===Raster add-ons for GRASS 5===

* See here: http://grass.itc.it/download/addons.php

* [http://www.valledemexico.ambitiouslemon.com/gwmodelling.html r.gmtg] The groundwater modelling tool for grass. A module to use MODFLOW within GRASS. '''Author''': Jaime Carrera

==GRASS 6.x==

===Vector add-ons===

* [http://geni.ath.cx/grass/v.out.gmt v.out.gmt] is a shell script that exports a polygon vector file into GMT xy file. psbasemap code was copied from Hamish's r.out.gmt. '''Author:''' Huidae Cho, Hamish Bowman, Dylan Beaudette

* [http://www.pois.org/florian/downloads/grass/v.strahler.tgz v.strahler] is a module that calculates the Strahler Order for all lines of a given dendritic network. '''Author:''' Florian Kindl. Available via SVN: svn co https://grasssvn.itc.it/svn/grassaddons/trunk/grassaddons/v.strahler

* [http://svg.cc/grass/index.html v.out.svg] is a module that exports SVG notation along with optional attribute data directly from GRASS 6.x vector layers. Now part of grass63-cvs. '''Author:''' Klaus Förster

* [http://les-ejk.cz/programs/ v.trees3d] is a module for making 3D trees from input vector point file. '''Author:''' Jachym Cepicky

* [http://www.public.asu.edu/~cmbarton/files/grass_scripts/v.lda v.lda] is a shell script for calculating Ian Johnson's (U. Sidney) Local Density Analysis values to measure clustering of point data at different neighborhood radii. There is an option to create a simple line graph of the results. There have been reports of problems creating the line graph on Cygwin installations of GRASS. '''Author:''' Michael Barton

* [http://www.public.asu.edu/~cmbarton/files/grass_scripts/v.append v.append] is a shell script combining two vector files AND their associated attribute tables. The vector files should be of the same type and, for best results, should have identically formatted attribute tables. '''Author:''' Michael Barton

* [http://www.shockfamily.net/cedric/grass/v.group v.group] generates a new vector map with the same geometry as an existing map. The new map has categories and a table based on grouping by the values in certain columns of the existing map's table. The values in these columns are preserved in the table for the new map. It's like a v.reclass that preserves data. '''Author:''' Cedric Shock

* [http://bambi.otago.ac.nz/hamish/grass/v.out.ascii.db v.out.ascii.db] is a shell script for exporting vector point data coordinates and selected attribute columns to either a file or to the console. '''Author:''' Hamish Bowman

* [http://les-ejk.cz/programs v.rasterbounds] is a shell script for creating polygon-vector file of rasterfile boundaries. The best version of GRASS is 6.1+. If you are using GRASS < 6.1, you have to be in the same mapset as your raster maps are from. '''Author:''' Jachym Cepicky

* [http://www.clubwebcanada.ca/twiens/v.sample.buffer.tgz v.sample.buffer] is a shell script that samples rasters in buffers of a specified size around features in a specified vector file. Sampling results are added as attributes to the vector file. This script was designed for sampling vegetation indices and DEM derived attributes for bird point counts. Sampling results can be one or more basic statistics such as mean, range, max, etc. '''Author:''' Trevor Wiens

* [http://www.gfosservices.it/materiale_didattico/moduli/grass_kriging.tar.gz v.variogram] is a script that create an omnidirectional experimental semi-variogram. This scripts require R-statistics software installed on your machine. Now the script is updated to run on spgrass6 >= 0.3 and sp >= 0.9 [http://grass.itc.it/pipermail/statsgrass/2006-October/000455.html reply]. '''Author:''' Ivan Marchesini, Pierluigi De Rosa.

* [http://www.gfosservices.it/materiale_didattico/moduli/grass_kriging.tar.gz v.surf.krige] is a script that do a surface interpolation from vector point data by Kriging method. The interpolated value of a cell is determined by using an omnidirectional variogram model fitted starting from model parameter given by user shown from the experimental semi variogram produced by v.variogram. The script can perform also the Leave-One-out cross validation to test the variogram model "fitted by eye" and an automatic fitted variogram model. The cross validation helps the user to choose the best variogram model to interpolate own data. '''Author:''' Pierluigi De Rosa.

* [http://ngeo.de/grassstuff/v.lmeasure v.lmeasure] and [http://ngeo.de/grassstuff/v.revlmeasure v.revlmeasure] are two perl scripts that place equidistant vector points along a given arbitrary vector line starting from the beginning or end of the vector line, respectively. Resulting vector points are labeled with the distance from origin. '''Author:''' Mats Schuh

* [http://david.p.finlayson.googlepages.com/v.swathwidth v.swathwidth] creates a vector map representing the sea bottom coverage of a multibeam (swath) sonar survey. '''Author:''' David Finlayson

* [http://kufaya.googlepages.com/v.flip.zip v.flip] flips the direction of selected vector lines. '''Author:''' Maciej Sieczka

* [http://phygeo7.geo.uni-augsburg.de/gis2/scripts/v.digatt v.digatt] (shell script) Interactively assign numeric table attributes to series of vector objects. It is meant to be effective by avoiding to type in the attribute value for all single objects again and again. The user is prompted for typing in an attribute value which is assigned to all objects selected by mouseclick afterwards. Next the display is redrawn after updating the table column. Zooming allows to change the region before the old value can be reused or a new one can be typed in (or copied by mouse from another object) in order to assign it to the next series of objects etc. It is tested not very extensively yet. Therefore better work with a copy of your map and consider using v.digit or d.what.vect -e alternatively. [http://phygeo7.geo.uni-augsburg.de/gis2/scripts/v.digatt.png screenshot]. '''Author:''' Andreas Philipp

* [http://k153-85.fsv.cvut.cz/cgi-bin/viewcvs.cgi/grass6/vector/v.in.gama/ v.in.gama] converts [http://www.gnu.org/software/gama/ GNU GaMa] XML output file to a GRASS vector map layer. '''Author:''' Martin Landa

* [http://kufaya.googlepages.com/v.breach.zip v.breach] creates vector maps of lines and points of continously lowering elevation down the input watercourses, based on the input raster DEM. '''Author:''' Maciej Sieczka

* [http://kufaya.googlepages.com/v.line.center.zip v.line.center] creates a points vector map with each point located in the middle of the length of one input vector line. '''Author:''' Maciej Sieczka

===Raster add-ons===

* [http://www.igc.usp.br/pessoais/guano/downloads/r.roughness r.roughness] is a shell script to calculate the surface roughness of a DEM, using r.surf.area and v.surf.rst. (for GRASS versions 6.1 and above)
* [http://www.igc.usp.br/pessoais/guano/downloads/r.roughness60 r.roughness60] - for GRASS versions 6.0.X '''Author:''' Carlos Henrique Grohmann

* [http://les-ejk.cz/programs/grass/r.gauss.tgz r.gauss] is Gaussian and Laplacian of Gaussian filter for GRASS. It is written in C language. '''Author:''' Jachym Cepicky

* [http://les-ejk.cz/programs/grass/r.mlv.tgz r.mlv] is Mean of least variance filter for GRASS. It is an edge-preserving (or even edge-enhacing) filter, which should serve for removing additive noise from images. It is written in C language. '''Author:''' Jachym Cepicky

* [http://les-ejk.cz/programs/grass/r.bilateral.tgz r.bilateral] Bilateral filter is an edge-preserving filter, which combines domain and range filtering. It is written in C language. '''Author:''' Jachym Cepicky

* [http://les-ejk.cz/programs/zc.pl Zero crossing] is a simple Perl script, finds the ,,zero crossings`` from the Laplacian of Gaussian filter (see above). It is really very simple, the edges don't need to be really on that pixel, where they are detected, no interpolation is performed. '''Author:''' Jachym Cepicky

'''Usage:'''
zc.pl -i input -o output |r.mapcalc

* [http://les-ejk.cz/programs/local_max.pl Local maxima] is a Perl script for <code>r.mapcalc</code>. It detects local maxima of the image. '''Author:''' Jachym Cepicky

'''Usage:'''
local_maxima.pl -i input -o output -s matrix_size|r.mapcalc

* [http://bambi.otago.ac.nz/hamish/grass/r.out.gmt r.out.gmt] is a GRASS script for exporting a GRASS raster map into a [[http://www.soest.hawaii.edu/gmt/ GMT]] grid file. It also creates a GMT color table from the data and can generate some GMT commands for plotting a postscript file. (code is experimental, but functional) see also http://169.237.35.250/~dylan/grass_user_group/#GMT_and_GRASS-overview '''Authors:''' Hamish Bowman, Dylan Beaudette

* [http://geni.ath.cx/grass/r.out.gmt yet another r.out.gmt] is a modified version of Hamish's r.out.gmt. Added options for title, xlabel, ylabel, comment, and map width. Removed any settings that can be changed by gmtset for more flexibility. '''Author:''' Hamish Bowman, Huidae Cho, Dylan Beaudette

* [http://bambi.otago.ac.nz/hamish/grass/r.pack r.pack] and [http://bambi.otago.ac.nz/hamish/grass/r.unpack r.unpack] are two GRASS scripts for transfering raster maps to another computer as a single file. '''Author:''' Hamish Bowman

* [http://bambi.otago.ac.nz/hamish/grass/dominant_dir.m dominant_dir.m] and [http://bambi.otago.ac.nz/hamish/grass/calc_terraflow_dir.m calc_terraflow_dir.m] are two Matlab scripts for determining the dominant flow direction from a r.terraflow MFD map and converting into a GRASS aspect map for use with d.rast.arrow, etc. '''Author:''' Hamish Bowman

* [http://www-pool.math.tu-berlin.de/~soeren/grass/modules/ r.in.onearth] for download and import satellite images direct from the NASA onearth WMS server into GRASS. '''Author:''' Soeren Gebbert

* [http://les-ejk.cz/files/programs/grass/r.in.wms.tgz r.in.wms] for download and import maps direct from WMS servers into GRASS. This script is written in Python Programming language. '''Author:''' Jachym Cepicky

* [http://www.shockfamily.net/cedric/grass/r.tileset r.tileset] generates a list of tiles and sizes in a source projection that cover the region in the current database with appropriate resolution. The size of individual tiles can be constrained. Only tiles intersecting the current region are returned. These tilings are appropriate for requesting data from another projection to meet the specifications of the current region. For example, it could be used to generate tile requests to a latitude / longitude WMS server like this <code>r.tileset -w sourceproj="+init=epsg:4326"</code>. '''Author:''' Cedric Shock

* [ftp://gsca.nrcan.gc.ca/outgoing/Patton/Grass/Scripts/r.csr.tar.bz2 r.csr] integrates several Grass programs to produce colored, shaded-relief rasters in one step. Accepts single or multiple elevation/bathymetry maps as input; optionally will fill data holidays with 3x3 median filter, multiple times, if required; can apply color maps from a) input raster, b) another raster in MAPSET, or c) from a rules file; otherwise, rainbow colorbar is applied. Output colored, shaded-relief rasters can optionally be exported to tiff format and archived using tar with gzip/bzip2 compression if appropriate flags are given. Shading parameters can be modified, though useful defaults are given. '''Author:''' Eric Patton

* [ftp://gsca.nrcan.gc.ca/outgoing/Patton/Grass/Scripts/r.fragment.tar.bz2 r.fragment] fragments a raster into a user-defined set of smaller tiles according to an input number of rows and columns. Optionally, a null value threshold can be set to filter out candidate tiles that would have a large percentage of null cells. '''Author:''' Eric Patton

* [http://david.p.finlayson.googlepages.com/r.eucdist r.eucdist] creates a raster map estimating the euclidean distance from known cells. '''Author:''' David Finlayson

* [http://david.p.finlayson.googlepages.com/r.smoothpatch r.smoothpatch] creates a composite of two rasters using a distance-weighted average across the transition to smooth the edges. '''Author:''' David Finlayson

* [http://www.faunalia.it/download/r_li/ r.li] is a more flexible and faster replacement of the old r.le. '''''Moved into 6.3-CVS'''''. '''Authors:''' Claudio Porta, Davide Spano, Serena Pallecchi, [http://www.faunalia.it Faunalia]

* [http://kufaya.googlepages.com/r.surf.nnbathy.zip r.surf.nnbathy] interpolates a surface from a raster input using the [http://www.marine.csiro.au/~sakov/ nn] natural neighbor interpolation library. Provides triangulation, Sibson natural neighbor interpolation and non-Sibsonian interpolation. '''Author:''' Maciej Sieczka

* The GRASS Image Processing Environment (GIPE) has USLE, Energy-balance and radiance-reflectance correction models. '''Author:''' Yann Chemin (unless specified otherwise). It is available by anonymous reading through this command (thanks Markus!): 
svn co https://grasssvn.itc.it/svn/grassaddons/trunk/grassaddons grassaddons/gipe
 
- r.usler creates USLE R factor (Rainfall erosivity) from annual precipitations.
It has 4 methods, Morgan, Roose, Foster and El-Swaify to choose from.
'''Authors:''' Natalia Medvedeva and Yann Chemin 
- r.uslek creates USLE K factor (soil erodibility) from sand, clay, silt fractions
and organic matter fraction. Based on USDA 1951 (p209) quoted in FAO World Soil CD,
and from some generic [soil class+OM] to K conversion table. 
- r.albedo creates Albedo. Albedo is the shortwave surface reflectance in the range
of 0.3-3 micro-meters. This module takes Modis, Aster, Landsat or AVHRR individual
surface reflectance bands to calculate Albedo. This module is a precursor to r.sun
or any Energy-Balance related processing. 
- r.eb.* are a set of 10+ GRASS modules that together perform the main functions of
the SEBAL model (Bastiaanssen, 1995). Those functions include (but are not limited to)
Soil heat flux, sensible heat flux, net radiation, evaporative fraction at satellite
overpass, diurnal actual evapotranspiration, momentum roughness length, etc. These
modules are also part of any Energy-Balance related processing. 
- r.evapo.potrad creates diurnal Potential evapotranspiration assuming all net radiation
becomes ET, according to SEBAL model (Bastiaanssen, 1995). This module also has a flag for
diurnal net radiation as required by SEBAL in r.eb.eta. 
- r.vi creates a given Vegetation index from a list of 13 of them, most of them only
requiring Red and NIR. Updated to accept all types of input data.
'''Authors:''' Baburao Kamble and Yann Chemin 
- r.vi.mpi is the mpi verion for cluster GRASS GIS education (no speed up here!).
'''Author:''' Shamim Akhter 
- r.dn2ref.l7, r.dn2ref.ast create top of atmosphere reflectance for Landsat 7ETM+ and
ASTER. These modules also have a flag for radiance output. Updated r.dn2ref.l7 to read .met
calibration file. 
- r.dn2full.l7 is an attempt to get all bands of Landsat7 calibrated and corrected to
either reflectance or temperature, reads only the .met file. 
- r.dn2potrad.l7] is an attempt to get ET potential from DN of Landsat 7 (Careful! No
Atmospheric correction!). 
- r.biomass creates biomass growth map from fPAR, lightuse efficiency, water availability
(or evap.fraction), Lat, doy and tsw.

* r.boxcount and r.boxcount.sh calculate the fractal dimension for a given map. These are versions for grass6 of [http://www.ucl.ac.uk/~tcrnmar/ Mark Lake's modules] for grass43. '''Authors:''' Mark Lake, grass6 port: Florian Kindl. Available via SVN: svn co https://grasssvn.itc.it/svn/grassaddons/trunk/grassaddons

===General add-ons===

* [http://www.nature-consult.de/dassau/g.laptop/g.laptop.sh g.laptop.sh] is an interactive shell script to extract raster and vector data from current Location into a new one. Data can be copied or extracted in current or original resolution and region extend. This script was written to extract smaller parts of a GRASS location to be able to present them on a laptop without the necessity to transfer huge data. Maps do not have to be in the same mapset. '''Author:''' Otto Dassau

* '''''Readline completion''''' for GRASS commands under the bash shell: [http://www.sorokine.info/grass-complete/ grass-complete] won't clutter the environment but needs to be installed; [http://dcalvelo.free.fr/grass/grass_rlcompleter.sh grass_rlcompleter.sh] needs almost no installation but will pollute the environment. Grass-Complete currently requires Bash version 2.05 for proper install. '''Author:''' Alexandre Sorokine (grass-complete), Daniel Calvelo (grass_rlcompleter.sh)
 

=== Imagery add-ons ===

* i.atcorr: Atmospheric Correction using Christo Zietsman's implementation of 6s code in C/C++. Available in SVN: 
svn co https://grasssvn.itc.it/svn/grassaddons/trunk/grassaddons grassaddons/gipe
 '''Author:''' Christo Zietsman

* [http://bambi.otago.ac.nz/hamish/grass/gdal/i.warp61 i.warp61] is a shell script that will use gdalwarp to rectify a raw input image using thin plate splines. The map should be imported into GRASS with r.in.gdal and GCPs set with i.points. Input is the raw image (GeoTIFF, JPEG, etc). Output is a GeoTIFF in the imagery group's target location's map projection. Requires a recent (early 2006) version of GRASS 6.1, or newer. '''Author:''' Hamish Bowman
 

=== Display add-ons ===

==== [[IconSymbols]] ====
* [[IconSymbols|Symbols]] which can be used with ''d.vect, d.graph'', and ''ps.map''.

==== Modules ====

* [http://bambi.otago.ac.nz/hamish/grass/d.frame.quarter d.frame.quarter] is a shell script that will split the display into four quadrants using ''d.frame''. Individual frames are named ''uno, dos, tres, cuatro'', and ''full_screen''. '''Author:''' Hamish Bowman

* [ftp://gsca.nrcan.gc.ca/outgoing/Patton/Grass/Scripts/d.hyperlink.tar.bz2 d.hyperlink] is an interactive shell script that allows the viewing of hyperlinked images from a vector's attribute table in an external image viewer. Queries can be made via SQL statements or interactive mouse-clicking. The attribute table must be pre-populated with a column containing the image to link the vector to; the user also specifies the image folder in the current MAPSET where the images are located. The script currently supports gimp, Eye of Gnome, gthumb, gpdf, and Inkscape image viewers. '''Author: '''Eric Patton

* [http://www.ornl.gov/sci/gist/software/grass/ pd-GRASS]: Parallel Display for GRASS GIS '''Author:''' Alex Sorokine

* [http://bambi.otago.ac.nz/hamish/grass/d.region.box d.region.box] is a shell script that quickly displays a box around the current region. '''Author:''' Hamish Bowman

* [http://bambi.otago.ac.nz/hamish/grass/d.stations d.stations] is a shell script that quickly displays vector points (or sites for GRASS 5.4 and below). '''Author:''' Hamish Bowman

* [http://bambi.otago.ac.nz/hamish/grass/d.varea d.varea] is a shell script that quickly displays vector areas. '''Author:''' Hamish Bowman

===Postscript add-ons===

* [http://les-ejk.cz/programs/grass/ps.atlas ps.atlas] is a shell script that makes more maps on current region according to input *.psmap file. General map can be stored as vector file. The resulting *.eps maps can be automatically converted to *.pdf files. '''Author:''' Jachym Cepicky

* [[ps.map scripts|ps.map samples/templates]]

==== [[AreaFillPatterns]] ====
* Hatches for ps.map's vareas

===GRASS and UMN Mapserver===

* [http://www.mail-archive.com/mapserver-users@lists.umn.edu/msg00086.html See interesting posting]

[[Category:Community]]
[[Category:Development]]
[[Category:Documentation]]
[[Category:Installation]]

GRASS 6.2 Feature Plan

2007-03-12T09:00:14Z

⚠️Jachym: /* WONTFIX? Later? */

== GRASS 6.2.x feature plan ==

There is the release branch for 6.2.x, see details at [http://grass.itc.it/devel/cvstags.php CVS: tags and branches]. A release branch is considered as "frozen", only bugfixes can be done.

=== GRASS 6.2.0 ===

In general 6.2 does not deviate too much from the 6.1.0 to avoid a major delay.

==== Beta0 ====

(never released)

<strike> 
* unlimited number of raster map (r.patch, r.series etc) (Glynn)
* several MinGW fixes for native MS-Windows support (Glynn)
* several fixes for MS-Windows/Cygwin support (Huidae)
* no hardcoded ARCH for Python-SWIG (Markus)
* vector/lidar: added missing includes (Markus)
* g.region b>t bug fixed (Martin)
* GRASS_PAGER (Glynn)
* r.mapcalc rand() (Glynn)
* tcl i18n install fix (Markus)
* LOCALE awk fixes to some scripts (Markus)
* SUN compilation fixes (Glynn)
* user docs fixes (Maciek)
* r.bilinear: Read/write maps as DCELL; Remove +0.5 from result (Glynn)
* NVIZ height update to avoid scene jump (Bob)
* Add the new v.lidar.* tools (needed for FOSS4G2006) (Roberto A. + Markus)
* lidar and simwe compilation issues on MacOSX fixed (William)
* Makefile cleanup for extra libraries (lidar, simwe, lrs) (Glynn + Markus)
* keywords backported from 6.3-CVS (Markus)
* renamed dbmi driver html files to include 'grass-' to avoid package conflicts (Markus)
</strike>

==== Beta 1 ====
<strike>
* v.digit: split icons into two rows for 800x600 screens (backport) (Michael, Hamish)
* gis.m fixes (Michael)
* v.proj: treat z as ellipsoidal height (Paul)
</strike>

==== Beta 2 ====
<strike>
* g.proj compile fix (Markus)
* NVIZ: Tk8.5 fix (Markus)
</strike>

==== Beta 3 ====
<strike>
* docs improvements (Eric, Trevor, Moritz, Michael)
* v.digit cosmetics (Hamish)
* v.outlier: parameter fix (markus)
* NVIZ: off-screen rendering fix for broken openGL drivers
* grass-xterm-wrapper: simplified for broken gnome-terminal (markus)
* rename v.bspline to v.surf.bspline for consistency
* further gis.m fixes (moritz, michael, cho)
* d.barscale segfault fix (hamish)
* d.grid segfault fix (hamish)
* d.graph segfault fix (hamish)
* r.buffer, r.what: docs fixes (hamish)
* added v.centroids and v.dissolve scripts (hamish)
* Czech translation updated (Martin)
* nviz: off-screen fixes (Glynn)
</strike>

==== RC1 ====

<strike>
* d.vect.thematic -s fixes (michael)
* Vietnamese translation (Bui Huu Manh)
* reverted Pbuffer changes in NVIZ (Brad)
* projection codes updated to EPSG 6.11 (Markus)
* g.region zoom= off by one error (Glynn)
* fix hardcoded Helvetica tcl fonts to a single file setting (in $GISBASE/etc/gtcltk/options.tcl) (michael)
</strike>

==== RC2 ====

<strike>
* r.random on MacOSX (Glynn)
* document improvements (various)
* v.in.ogr: check valid output filename (Brad)
* various r.le fixes (Hamish)
* MinGW fix (Radim)
</strike>

==== RC3 ====

<strike>
* r.le.setup fixes (Glynn, Hamish)
* default color map range (bug #5212) (Glynn)
* fix v.digit/toolbox.tcl for tcl8.3 (Hamish)
* update to EPSG 6.11.1 (Markus)
* close GRASS after creating new location from file (Markus)
* Fine tune intro text when launching GRASS in text mode (Paul)
* gis.m zooming in mapcanvas.tcl (Michael)
* missing Polish EPSG codes
* initial Arabic translation (Alaa Masoud)
</strike>

==== Final 6.2.0 ====
(released 31 Oct 2006)

<strike>
* continued Polish translation (Artur Niescior)
* r.watershed slowliness due to long color tables (C. Ehlschlaeger)
* gis.m broken for Tcl/Tk 8.3 (Hamish, Michael)
* test gis.m
* write impressive [http://grass.itc.it/announces/announce_grass620.html press release] (best done in [http://grass.itc.it/devel/cvs.php#web CVS Web])
** also prepare the short [http://grass.itc.it/announces/abstract_grass620.txt abstract] version.
** HB: I did some work on this the other day, of course it can always be better!
</strike>

=== 6.2.1 ===

==== 6.2.1RC1 ====
(released 6 Dec. 2006)

''Bugs:''
<strike>
* gis.m fixes for geo rectifier (Michael)
* gis.m zoom fixes (Michael)
* install of include files problem on Solaris (Glynn)
* Handle non-standard ETRS_1989 datum name (Paul)
* d.histogram: clear just the current frame, not the full screen (Hamish)
* i.group: fix subgroup listing (Hamish)
* ps.map: broken for named paper sizes (Hamish, Glynn)
* gis.m: meaningful error messages on startup (Michael)
* v.db.select: fix SQL where= option error (Hamish)
* Add module r.to.rast3elev
* crash v.in.ogr with gcc4.1.x and non-C locale (Andrey Kiselev)
* v.in.db: with where="condition" it copies the entire attribute table (Martin)
</strike>

==== Final 6.2.1 ====
(released 12 Dec. 2006)

* [http://grass.itc.it/grass62/source/ Download source code]
* [http://grass.itc.it/grass62/source/snapshot/ Download source code diff's to 6.2.0]
: (to be changed to 6.2.1 diffs? HB: can we have both? include binary file changes? [diff -a?])

Bugs:
<strike>
* d.frame: bugfix: make -l list map names flag work (Hamish)
* Latvian translation update: Maris Nartiss
</strike>

[http://grass.itc.it/announces/announce_grass621.html press release] ([http://grass.itc.it/announces/abstract_grass621.txt abstract])

=== 6.2.2 ===
''This version has not yet been released''

==== 6.2.2-cvs ====

===== Fixed =====
* <strike>DB bug</strike> (Radim) '''[please expand]'''

* <strike>r.proj bilinear: Fix interpolation expression (row/column were swapped)</strike> (Glynn)
: [http://www.zen87603.zen.co.uk/proj-old.png old version] vs. [http://www.zen87603.zen.co.uk/proj-new.png new version]

* <strike>Allow r.profile data from stdin</strike> (Hamish)
* <strike>Slovakia Hermannskogel datum (bug #5396)</strike> (Jaro Hofierka/Dr. Klobusiak/Martin)
* <strike>ps.map: Fix map scaling when map projection is not measured in meters</strike> (Hamish)
* <strike>r.tileset: Fix break due to platform specific units parsing; Requires Bash</strike> (Hamish)
* <strike>added missing SQL TIME support for DBF driver </strike> (Markus)
* <strike>2 bugs in v.build.polylines [http://intevation.de/rt/webrt?serial_num=4247 #4247] [http://intevation.de/rt/webrt?serial_num=4249 #4249]</strike> (MartinL)

===== TODO =====

''Bugs:''
* backport false easting/northing test from lib/gis/
* backport ogsf fix
* remove "let" bashisms from d.vect.thematic

''Enhancements:''
* backport in EPSG code search tool from CVS/HEAD
: see [http://freegis.org/cgi-bin/viewcvs.cgi/grass6/lib/init/Attic/epsg_option.tcl.in lib/init/epsg_option.tcl.in] versions 1.11 - 1.15

''Final details:''

* Generate inter-release ChangeLog:
gzip -d ChangeLog_6.2.1.gz
cp ChangeLog_6.2.1 ChangeLog_6.2.0-6.2.1
vi ChangeLog_6.2.0-6.2.1
# /6.2.0 release
# j (down a line)
# 50000dd
# :wq
gzip ChangeLog_6.2.0-6.2.1

* Prepare release announcement and blurb

=== WONTFIX? Later? ===

* r.out.gdal region sensitive (backport new r.out.gdal from CVS HEAD?) -- We can just take enhanced shell version from CVS HEAD (r.out.gdal.sh) --[[User:Jachym|Jachym]] 10:00, 12 March 2007 (CET)

* NVIZ volume problem (test with slovakia3d dataset) - sometimes it works
** HB: fails from command line; ok if the volume added within NVIZ ([http://intevation.de/rt/webrt?serial_num=4725 bug #4725]) G_warning() message suggesting a work-around added to 6.2 release branch.

* r.distance null distance
** This is in 6.3 and will be tested

=== Releases ===
* [http://grass.itc.it/grass62/source/snapshot/ Source code Snapshot]
* 6.2.0beta1 released 28 August 2006
* 6.2.0beta2 released 30 August 2006
* 6.2.0beta3 released 18 September 2006
* 6.2.0RC1 released 26 September 2006
* 6.2.0RC2 released 6 October 2006
* 6.2.0RC3 released 24 October 2006
* 6.2.0 released 31 October 2006
* 6.2.1 released 12 December 2006

[[Category:Development]]
[[Category:Release Roadmap]]

GRASS GUI

2007-03-02T17:25:03Z

⚠️Jachym: /* Graphical toolkit choise */

= Graphical toolkit choise =

http://www.wxwidgets.org/wiki/index.php/WxWidgets_Compared_To_Other_Toolkits

== Sourceforge.net statistics ==
http://sourceforge.net/softwaremap/trove_list.php

* Projects using Python as programming language: 6217
* Projects using '''GTK+''': 1328
* Projects using '''GTK+''' graphical library and Python programming language: 348
* Projects using '''GTK+''' graphical library and Python programming language and '''OpenGL''': 7
* Projects using '''wxWidgets''': 880
* Projects using '''wxWidgets''' graphical library and Python programming language: 360
* Projects using '''wxWidgets''' graphical library and Python programming language and '''OpenGL''': 4

= wxPython GUI =

* Generic [[GRASS and Python]] wiki page

=== General GUI Design ===
''''' Move into [[GRASS_GUI#Components|Components]] section below '''''

==== User's point of view ====
* GUI has multiple map displays
* Each map display has several buttons for basic functions
** Zooming and Paning
** Data Quering
* Each map display will be able to fire up pop-up toolbar with more complicated and not-so-often-used display functions (substitutions for d.measure, d.profile, d.text, ...)
* Each map display will be able to fire up pop-up toolbar with v.digit substitution
* Monitors can be started from the command line and from the GIS Manager
* Monitors must be able to display following types of layers
** GRASS Raster
** GRASS Vector
** GDAL Raster
** GDAL Vector
** WMS Layer from remote server
** WCS and WFS layers too
** Text layers
** Graphics layers
** Grid
** Image layers
** ...
* GIS Manager is tool for
** Monitors management and monitor content management
** Layer look management
** Modules starting (from integrated command line or menu)
** Displaying output from modules (G_message, G_warning, G_fatal_error, G_percent)
* GIS Manager must be able to save and restore session
* There should be default session file, which will be loaded by default ones GRASS is started with -gui parameter
* Georectification tool should be part of new GUI. It should be special type of monitor with added GCP function
* Map Composer should be part of the new GUI. This tool should generate configuration files for hardcopy maps. The configuration files should be either ps.map files or maybe SVG

==== Coder's point of view ====
NOTE: As I have no coders background, sorry for inept formulated thoughts. --[[User:Jachym|Jachym]] 09:13, 2 February 2007 (CET)

List of suggested classes and their purpose.

* '''Layer''' -- Raster, vector, WMS, whatever layer
** '''Attributes''' -- Attributes are depending on layer type, but there are also common attributes marked with prefix "l_" (for 'layer'):
*** l_type -- vector, raster, wms, text, graph, ...
*** l_mapfile -- renderd ppm file
*** l_maskfile -- pgm file with layer's alpha channel
*** l_active -- layer is active, will be rendered only if True
*** l_hidden - layer is hidden, will be allways rendered
*** l_opacity - layer opacity [0-1]
** '''Methods'''
*** Render -- runs d.* and similar commands for making content of l_mapfile

* '''Map''' -- Set of layers renderd to single PNG image, ready to display in Map display frame
** '''Attributes'''
*** Width -- map width
*** Height -- map height
*** Region -- Region boundaries and resolution
*** Layers -- Array of ''Layer''s displayed in this "map"
*** MapFile -- path to resulting PNG file with rendered map
** '''Methods'''
*** AddRasterLayer -- Adds GRASS-raster layer to list of layers
*** AddVectorLayer -- Adds GRASS-vector layer to list of layers
*** Add...Layer -- Adds some type of layer (wms, wfs, text, ...) to list of layers
*** GetListOfLayers -- Returns array of layers (''active, hidden, type'')
*** Render -- Creates final PNG image and stores it's path to ''MapFile''

''TSW Comment: perhaps it would be simpler to have AddLayer and pass the type as a parameter. Automatic would be nice, but since it is possible for vector and raster files to have the same name, this wouldn't work. Another option to consider would be to use AddLayer as a base class AddLayerRaster, ... as subclasses. This would make things more modular and theoretically at least, easier to maintain and develop.''

''JC Comment: I made separate functions for raster and vector, because of their attributes are completely different. There should be also AddWMSLayer etc. functions. IMHO it does not matter, if we have general AddLayer with parameter layer_type, or separate functions for all layer types.''

* '''DigitToolbar''' -- Pop-up toolbar with digitising functions
* '''DisplayToolBar''' -- Pop-up toolbar with substitution of other d.* modules

* '''MapDisplay''' -- Frame (in [http://wiki.wxpython.org/index.cgi/Frequently_Asked_Questions#head-829eea79fe17c04c65c00a7dc0bffa69f2473167 wxWidgets terminology]) with embed toolbar for zooming and paning and maybe data quering and pop-up toolbar for substitution of other d.* modules (d.path, d.profile, ...)
NOTE: This section should be completed
** '''Attributes'''
*** Width
*** Height
*** Mouse -- mouse actions, movements, presed buttons etc.
*** Map -- ''Map'' class
** ''Methods'' -- just very coarse definition
*** Zoom -- for zooming and paning
*** DrawBox -- For box drawing
*** DrawLine -- For line drawing
*** DrawPoint -- for points drawing

* '''GisManager''' -- GIS Manager frame
** '''Attributes'''
*** Displays -- array with map displayes
** '''Methods'''
*** AddDisplay -- Creates new map display
*** AddLayer -- Adds layer of defined type
*** EditLayer -- Opens pop-up window with layer attributes definition
*** ExecuteCommand -- Executes module from command line or menu

* '''GCPDisplay''' -- Special type of MapDisplay with tool for setting GCPs
* '''HCPDisplay''' -- Special type of MapDisplay with tools for creating configuration files for hardcopy maps

=== Used tools ===
wxPython seems to be the best tool for "new generation gui", because of it's multiplatformity and native look&feel on various platforms.

* [http://www.poromenos.org/tutorials/python 10 minute Python tutorial] for programmers of other languages

=== Where to get it ===
Jachym suggests to move the development to GRASS-Addons subversion repository, until it is "mature enough". Subversion enables for example to rename files, which could be useful. Current version can be found at https://grasssvn.itc.it/grasssvn/grassaddons/trunk/grassaddons/gui/#_trunk_grassaddons_gui_ and downloaded with command

svn co https://grasssvn.itc.it/svn/grassaddons/trunk/grassaddons/gui

Write access to the GRASS-Addons SVN is managed by Markus Neteler.

=== Layout Concepts ===

==== Screenshots with proposed shapes ====

{| class="wikitable" style="text-align:center;" border="1"
| [[Image:Gism.png]] || [[Image:Gism2.jpeg]]
|-
| The wxGlade definition file is avaliable [https://grasssvn.itc.it/grasssvn/grassaddons/trunk/grassaddons/gui/gism.wxg in the subversion repository] || Another proposal by Michael Barton
|}

==== Discussion / Comments ====

If the goal is to move toward a single command line interface integrated into the GUI, perhaps we should use the shape of a terminal window as the the shape of the new GIS manager. In this way the layers tree could appear next to the layer attributes in the same way the currently gis.m displays the layer attributes below the tree. The downside to this is having space on the desktop.

Another possibility would be to link the command window to the map display in the shape of an xterm, in this way the gis manager could have a profile shape by default that could easily fit onto a single screen for those without multiple display systems. Another possibility that might be desirable is to be able to 'tear off' the command window separately or link it to either the GIS manager tree or the display window.

It appears in the screen shots that multiple command windows are being considered (1 per map). In some ways this is potentially quite elegant especially if they are set up as separate sessions altogether so we wouldn't need to use win override. What we do encounter is issues related to multiple users which are non-trivial. Still as the layout suggest this it may be worth considering the impact of this, although the current solution in gis.m is probably the best for now.

=== GUI History ===
'''[http://www.public.asu.edu/~cmbarton/files/grass_wxpython/ Link to wxPython prototype GUI for GRASS 6]'''

'''Update 18:02, 14 August 2006 (CEST) '''New version implements double buffered drawing to fix display issues on Debian, including flickering why panning and display being erased by overlaying windows. Output to PNG file added. Better looking zoom rectangles.

'''*****The wxPython code is moving to the GRASS CVS. You should look for the newest versions there. Volunteers to help with the new GUI are welcomed!*****''' [[User:Cmbarton|Cmbarton]]

'''Update 00:50, 9 August 2006 (CEST) '''New version will run directly from GRASS prompt with new startup script. Now put gism.py and associated files into $GISBASE/etc/gmwxp and add a new script (gm.wxp) to the $GISBASE/scripts folder. Then simply type gm.wxp& from the GRASS command prompt to get the new prototype wxPython GUI for GRASS. See instructions in today's package update. [[User:Cmbarton|Cmbarton]]

'''Update 23:59, 7 August 2006 (CEST) '''New version with nearly complete raster menu by Yann Chemin. [[User:Cmbarton|Cmbarton]]

'''Update 19:02, 7 August 2006 (CEST)'''I just uploaded a new version of gism.py and related files. I'll keep an archive and so am changing the link to go to the folder rather than the file itself so I won't have to keep changing the link. This update includes the following changes:
*The biggest change in wrapping in grassgui.py. This provides autogenerated wxPython GUI dialogs for all grass commands.
This can now be called from the command console (just type in the command name with no arguments as you do now) or the
prototype menus. I updated grassgui.py to current wxPython syntax (mostly) and added methods to make it callable from
other modules.
*Methods added to gism.py and grassgui.py that automatically restart them with pythonw for the Mac
--[[User:Cmbarton|Cmbarton]] 19:02, 7 August 2006 (CEST)

Initial development has begun on the next generation UI for GRASS. wxPython is the leading contender for a platform in which to continue development of the GRASS GUI. wxPython is a Python implementation of the well known wxWidgets (formerly wxWindows) interface development platform for C++. An initial demonstration was developed by Jachym Cepicky to show the possibility of controling GRASS via wxPython. A second generation prototype has been completed, building on Jachym's work. It is available for testing and further development at link above.
--[[User:Cmbarton|Cmbarton]] 07:15, 4 August 2006 (CEST)

== Components ==

=== Core GIS manager ===
* name? (does it even need one?)

=== Module GUIs ===
* Generate from XML --interface-description or new --wxpython switch?

=== Startup GUI ===
* for picking mapset etc

=== New location GUI ===
* Wizard for creating new location & region.
:see QGIS's one

=== Cartography: GUI front end for ps.map ===

* This is a cartographic composer, intended to be a stand alone hardcopy plot generator. It is not meant to be a '''Print''' button for the maps currently displayed in the GIS manager, that will need it own controls.

* The GUI will prepare a semi-WYSIWYG + tree menu controls which can write a ps.map control file, and then run ps.map to create PostScript and PDF output directly. Loading a ps.map control file is harder and can happen later.

* For a start at a Tcl/Tk composer see gui/tcltk/d.m/print.tcl

* Start with most important mapping instructions
** paper
** scale
** maploc
** rast
** vects
** grids
** scalebar
** mapinfo
** text labels

==== Outputs ====

* ps.map instructions file
* PostScript file [ps.map instructions tmp file]
* lpr [PostScript tmp file]
* PDF File (pstopdf? ps2pdf? GNU Ghostscript?) [PostScript tmp file]

==== Inputs ====

* Ability to load in saved ps.map scripts. I consider this to be a low priority, deal with it after map creation is fully functional. Start with scripts saved using the GUI, after that is working expand to load any ps.map instructions file.

=== Georectifier ===
* Should be a simple port of Michael's tcltk Georectifier for gis.m

=== Digitizer ===

==== Vector ====

* Rewrite v.digit. Replace r.digit (r.in.poly format isn't far from v.in.ascii standard format)
* v.edit?
* Integrate d.rast.edit, d.rast.num functionality in another tool?
* We can use QGIS's digitizer in the interim.
* When to drop v.digit?

==== Raster ====
* r.digit (merge with v.digit?)
* d.rast.edit
: Idea: get cell center coords and new values from GUI interaction, then pass those through r.in.xyz, and r.patch the new values over the top of the old map.

* merge with Georectifier? (i.points, i.vpoints)

==== Ortho photos ====
* To replace i.ortho.photo and friends

= Tcl/Tk GUI =
Screenshots: http://grass.itc.it/grass61/screenshots/index.php

===Draft GUI design specifications===

* See attached file

===Summary of 2005 discussions on next generation UI for GRASS===

* Attached file gives a distillation of several months of emails on the GRASS developers list. It includes a series of desired design features and specifications, along with supporting quotes.

===Compiled emails from 2005 discussions on next generation UI for GRASS===

* Attached file compiles all (or all that I could find) of the late 2005 emails on the GRASS developers list discussing proposed specifications for a next generation GRASS GUI. It is a series of rtm files that group the discussions according to a series of topics.

GRASS GUI

2007-03-02T17:24:39Z

⚠️Jachym: /* Sourceforge.net statistics */

= Graphical toolkit choise =
== Sourceforge.net statistics ==
http://sourceforge.net/softwaremap/trove_list.php

* Projects using Python as programming language: 6217
* Projects using '''GTK+''': 1328
* Projects using '''GTK+''' graphical library and Python programming language: 348
* Projects using '''GTK+''' graphical library and Python programming language and '''OpenGL''': 7
* Projects using '''wxWidgets''': 880
* Projects using '''wxWidgets''' graphical library and Python programming language: 360
* Projects using '''wxWidgets''' graphical library and Python programming language and '''OpenGL''': 4

http://www.wxwidgets.org/wiki/index.php/WxWidgets_Compared_To_Other_Toolkits

= wxPython GUI =

* Generic [[GRASS and Python]] wiki page

=== General GUI Design ===
''''' Move into [[GRASS_GUI#Components|Components]] section below '''''

==== User's point of view ====
* GUI has multiple map displays
* Each map display has several buttons for basic functions
** Zooming and Paning
** Data Quering
* Each map display will be able to fire up pop-up toolbar with more complicated and not-so-often-used display functions (substitutions for d.measure, d.profile, d.text, ...)
* Each map display will be able to fire up pop-up toolbar with v.digit substitution
* Monitors can be started from the command line and from the GIS Manager
* Monitors must be able to display following types of layers
** GRASS Raster
** GRASS Vector
** GDAL Raster
** GDAL Vector
** WMS Layer from remote server
** WCS and WFS layers too
** Text layers
** Graphics layers
** Grid
** Image layers
** ...
* GIS Manager is tool for
** Monitors management and monitor content management
** Layer look management
** Modules starting (from integrated command line or menu)
** Displaying output from modules (G_message, G_warning, G_fatal_error, G_percent)
* GIS Manager must be able to save and restore session
* There should be default session file, which will be loaded by default ones GRASS is started with -gui parameter
* Georectification tool should be part of new GUI. It should be special type of monitor with added GCP function
* Map Composer should be part of the new GUI. This tool should generate configuration files for hardcopy maps. The configuration files should be either ps.map files or maybe SVG

==== Coder's point of view ====
NOTE: As I have no coders background, sorry for inept formulated thoughts. --[[User:Jachym|Jachym]] 09:13, 2 February 2007 (CET)

List of suggested classes and their purpose.

* '''Layer''' -- Raster, vector, WMS, whatever layer
** '''Attributes''' -- Attributes are depending on layer type, but there are also common attributes marked with prefix "l_" (for 'layer'):
*** l_type -- vector, raster, wms, text, graph, ...
*** l_mapfile -- renderd ppm file
*** l_maskfile -- pgm file with layer's alpha channel
*** l_active -- layer is active, will be rendered only if True
*** l_hidden - layer is hidden, will be allways rendered
*** l_opacity - layer opacity [0-1]
** '''Methods'''
*** Render -- runs d.* and similar commands for making content of l_mapfile

* '''Map''' -- Set of layers renderd to single PNG image, ready to display in Map display frame
** '''Attributes'''
*** Width -- map width
*** Height -- map height
*** Region -- Region boundaries and resolution
*** Layers -- Array of ''Layer''s displayed in this "map"
*** MapFile -- path to resulting PNG file with rendered map
** '''Methods'''
*** AddRasterLayer -- Adds GRASS-raster layer to list of layers
*** AddVectorLayer -- Adds GRASS-vector layer to list of layers
*** Add...Layer -- Adds some type of layer (wms, wfs, text, ...) to list of layers
*** GetListOfLayers -- Returns array of layers (''active, hidden, type'')
*** Render -- Creates final PNG image and stores it's path to ''MapFile''

''TSW Comment: perhaps it would be simpler to have AddLayer and pass the type as a parameter. Automatic would be nice, but since it is possible for vector and raster files to have the same name, this wouldn't work. Another option to consider would be to use AddLayer as a base class AddLayerRaster, ... as subclasses. This would make things more modular and theoretically at least, easier to maintain and develop.''

''JC Comment: I made separate functions for raster and vector, because of their attributes are completely different. There should be also AddWMSLayer etc. functions. IMHO it does not matter, if we have general AddLayer with parameter layer_type, or separate functions for all layer types.''

* '''DigitToolbar''' -- Pop-up toolbar with digitising functions
* '''DisplayToolBar''' -- Pop-up toolbar with substitution of other d.* modules

* '''MapDisplay''' -- Frame (in [http://wiki.wxpython.org/index.cgi/Frequently_Asked_Questions#head-829eea79fe17c04c65c00a7dc0bffa69f2473167 wxWidgets terminology]) with embed toolbar for zooming and paning and maybe data quering and pop-up toolbar for substitution of other d.* modules (d.path, d.profile, ...)
NOTE: This section should be completed
** '''Attributes'''
*** Width
*** Height
*** Mouse -- mouse actions, movements, presed buttons etc.
*** Map -- ''Map'' class
** ''Methods'' -- just very coarse definition
*** Zoom -- for zooming and paning
*** DrawBox -- For box drawing
*** DrawLine -- For line drawing
*** DrawPoint -- for points drawing

* '''GisManager''' -- GIS Manager frame
** '''Attributes'''
*** Displays -- array with map displayes
** '''Methods'''
*** AddDisplay -- Creates new map display
*** AddLayer -- Adds layer of defined type
*** EditLayer -- Opens pop-up window with layer attributes definition
*** ExecuteCommand -- Executes module from command line or menu

* '''GCPDisplay''' -- Special type of MapDisplay with tool for setting GCPs
* '''HCPDisplay''' -- Special type of MapDisplay with tools for creating configuration files for hardcopy maps

=== Used tools ===
wxPython seems to be the best tool for "new generation gui", because of it's multiplatformity and native look&feel on various platforms.

* [http://www.poromenos.org/tutorials/python 10 minute Python tutorial] for programmers of other languages

=== Where to get it ===
Jachym suggests to move the development to GRASS-Addons subversion repository, until it is "mature enough". Subversion enables for example to rename files, which could be useful. Current version can be found at https://grasssvn.itc.it/grasssvn/grassaddons/trunk/grassaddons/gui/#_trunk_grassaddons_gui_ and downloaded with command

svn co https://grasssvn.itc.it/svn/grassaddons/trunk/grassaddons/gui

Write access to the GRASS-Addons SVN is managed by Markus Neteler.

=== Layout Concepts ===

==== Screenshots with proposed shapes ====

{| class="wikitable" style="text-align:center;" border="1"
| [[Image:Gism.png]] || [[Image:Gism2.jpeg]]
|-
| The wxGlade definition file is avaliable [https://grasssvn.itc.it/grasssvn/grassaddons/trunk/grassaddons/gui/gism.wxg in the subversion repository] || Another proposal by Michael Barton
|}

==== Discussion / Comments ====

If the goal is to move toward a single command line interface integrated into the GUI, perhaps we should use the shape of a terminal window as the the shape of the new GIS manager. In this way the layers tree could appear next to the layer attributes in the same way the currently gis.m displays the layer attributes below the tree. The downside to this is having space on the desktop.

Another possibility would be to link the command window to the map display in the shape of an xterm, in this way the gis manager could have a profile shape by default that could easily fit onto a single screen for those without multiple display systems. Another possibility that might be desirable is to be able to 'tear off' the command window separately or link it to either the GIS manager tree or the display window.

It appears in the screen shots that multiple command windows are being considered (1 per map). In some ways this is potentially quite elegant especially if they are set up as separate sessions altogether so we wouldn't need to use win override. What we do encounter is issues related to multiple users which are non-trivial. Still as the layout suggest this it may be worth considering the impact of this, although the current solution in gis.m is probably the best for now.

=== GUI History ===
'''[http://www.public.asu.edu/~cmbarton/files/grass_wxpython/ Link to wxPython prototype GUI for GRASS 6]'''

'''Update 18:02, 14 August 2006 (CEST) '''New version implements double buffered drawing to fix display issues on Debian, including flickering why panning and display being erased by overlaying windows. Output to PNG file added. Better looking zoom rectangles.

'''*****The wxPython code is moving to the GRASS CVS. You should look for the newest versions there. Volunteers to help with the new GUI are welcomed!*****''' [[User:Cmbarton|Cmbarton]]

'''Update 00:50, 9 August 2006 (CEST) '''New version will run directly from GRASS prompt with new startup script. Now put gism.py and associated files into $GISBASE/etc/gmwxp and add a new script (gm.wxp) to the $GISBASE/scripts folder. Then simply type gm.wxp& from the GRASS command prompt to get the new prototype wxPython GUI for GRASS. See instructions in today's package update. [[User:Cmbarton|Cmbarton]]

'''Update 23:59, 7 August 2006 (CEST) '''New version with nearly complete raster menu by Yann Chemin. [[User:Cmbarton|Cmbarton]]

'''Update 19:02, 7 August 2006 (CEST)'''I just uploaded a new version of gism.py and related files. I'll keep an archive and so am changing the link to go to the folder rather than the file itself so I won't have to keep changing the link. This update includes the following changes:
*The biggest change in wrapping in grassgui.py. This provides autogenerated wxPython GUI dialogs for all grass commands.
This can now be called from the command console (just type in the command name with no arguments as you do now) or the
prototype menus. I updated grassgui.py to current wxPython syntax (mostly) and added methods to make it callable from
other modules.
*Methods added to gism.py and grassgui.py that automatically restart them with pythonw for the Mac
--[[User:Cmbarton|Cmbarton]] 19:02, 7 August 2006 (CEST)

Initial development has begun on the next generation UI for GRASS. wxPython is the leading contender for a platform in which to continue development of the GRASS GUI. wxPython is a Python implementation of the well known wxWidgets (formerly wxWindows) interface development platform for C++. An initial demonstration was developed by Jachym Cepicky to show the possibility of controling GRASS via wxPython. A second generation prototype has been completed, building on Jachym's work. It is available for testing and further development at link above.
--[[User:Cmbarton|Cmbarton]] 07:15, 4 August 2006 (CEST)

== Components ==

=== Core GIS manager ===
* name? (does it even need one?)

=== Module GUIs ===
* Generate from XML --interface-description or new --wxpython switch?

=== Startup GUI ===
* for picking mapset etc

=== New location GUI ===
* Wizard for creating new location & region.
:see QGIS's one

=== Cartography: GUI front end for ps.map ===

* This is a cartographic composer, intended to be a stand alone hardcopy plot generator. It is not meant to be a '''Print''' button for the maps currently displayed in the GIS manager, that will need it own controls.

* The GUI will prepare a semi-WYSIWYG + tree menu controls which can write a ps.map control file, and then run ps.map to create PostScript and PDF output directly. Loading a ps.map control file is harder and can happen later.

* For a start at a Tcl/Tk composer see gui/tcltk/d.m/print.tcl

* Start with most important mapping instructions
** paper
** scale
** maploc
** rast
** vects
** grids
** scalebar
** mapinfo
** text labels

==== Outputs ====

* ps.map instructions file
* PostScript file [ps.map instructions tmp file]
* lpr [PostScript tmp file]
* PDF File (pstopdf? ps2pdf? GNU Ghostscript?) [PostScript tmp file]

==== Inputs ====

* Ability to load in saved ps.map scripts. I consider this to be a low priority, deal with it after map creation is fully functional. Start with scripts saved using the GUI, after that is working expand to load any ps.map instructions file.

=== Georectifier ===
* Should be a simple port of Michael's tcltk Georectifier for gis.m

=== Digitizer ===

==== Vector ====

* Rewrite v.digit. Replace r.digit (r.in.poly format isn't far from v.in.ascii standard format)
* v.edit?
* Integrate d.rast.edit, d.rast.num functionality in another tool?
* We can use QGIS's digitizer in the interim.
* When to drop v.digit?

==== Raster ====
* r.digit (merge with v.digit?)
* d.rast.edit
: Idea: get cell center coords and new values from GUI interaction, then pass those through r.in.xyz, and r.patch the new values over the top of the old map.

* merge with Georectifier? (i.points, i.vpoints)

==== Ortho photos ====
* To replace i.ortho.photo and friends

= Tcl/Tk GUI =
Screenshots: http://grass.itc.it/grass61/screenshots/index.php

===Draft GUI design specifications===

* See attached file

===Summary of 2005 discussions on next generation UI for GRASS===

* Attached file gives a distillation of several months of emails on the GRASS developers list. It includes a series of desired design features and specifications, along with supporting quotes.

===Compiled emails from 2005 discussions on next generation UI for GRASS===

* Attached file compiles all (or all that I could find) of the late 2005 emails on the GRASS developers list discussing proposed specifications for a next generation GRASS GUI. It is a series of rtm files that group the discussions according to a series of topics.

GRASS GUI

2007-03-02T16:53:46Z

⚠️Jachym: /* Sourceforge.net statistics */

= Graphical toolkit choise =
== Sourceforge.net statistics ==
http://sourceforge.net/softwaremap/trove_list.php

* Projects using Python as programming language: 6217
* Projects using '''GTK+''': 1328
* Projects using '''GTK+''' graphical library and Python programming language: 348
* Projects using '''GTK+''' graphical library and Python programming language and '''OpenGL''': 7
* Projects using '''wxWidgets''': 880
* Projects using '''wxWidgets''' graphical library and Python programming language: 360
* Projects using '''wxWidgets''' graphical library and Python programming language and '''OpenGL''': 4

= wxPython GUI =

* Generic [[GRASS and Python]] wiki page

=== General GUI Design ===
''''' Move into [[GRASS_GUI#Components|Components]] section below '''''

==== User's point of view ====
* GUI has multiple map displays
* Each map display has several buttons for basic functions
** Zooming and Paning
** Data Quering
* Each map display will be able to fire up pop-up toolbar with more complicated and not-so-often-used display functions (substitutions for d.measure, d.profile, d.text, ...)
* Each map display will be able to fire up pop-up toolbar with v.digit substitution
* Monitors can be started from the command line and from the GIS Manager
* Monitors must be able to display following types of layers
** GRASS Raster
** GRASS Vector
** GDAL Raster
** GDAL Vector
** WMS Layer from remote server
** WCS and WFS layers too
** Text layers
** Graphics layers
** Grid
** Image layers
** ...
* GIS Manager is tool for
** Monitors management and monitor content management
** Layer look management
** Modules starting (from integrated command line or menu)
** Displaying output from modules (G_message, G_warning, G_fatal_error, G_percent)
* GIS Manager must be able to save and restore session
* There should be default session file, which will be loaded by default ones GRASS is started with -gui parameter
* Georectification tool should be part of new GUI. It should be special type of monitor with added GCP function
* Map Composer should be part of the new GUI. This tool should generate configuration files for hardcopy maps. The configuration files should be either ps.map files or maybe SVG

==== Coder's point of view ====
NOTE: As I have no coders background, sorry for inept formulated thoughts. --[[User:Jachym|Jachym]] 09:13, 2 February 2007 (CET)

List of suggested classes and their purpose.

* '''Layer''' -- Raster, vector, WMS, whatever layer
** '''Attributes''' -- Attributes are depending on layer type, but there are also common attributes marked with prefix "l_" (for 'layer'):
*** l_type -- vector, raster, wms, text, graph, ...
*** l_mapfile -- renderd ppm file
*** l_maskfile -- pgm file with layer's alpha channel
*** l_active -- layer is active, will be rendered only if True
*** l_hidden - layer is hidden, will be allways rendered
*** l_opacity - layer opacity [0-1]
** '''Methods'''
*** Render -- runs d.* and similar commands for making content of l_mapfile

* '''Map''' -- Set of layers renderd to single PNG image, ready to display in Map display frame
** '''Attributes'''
*** Width -- map width
*** Height -- map height
*** Region -- Region boundaries and resolution
*** Layers -- Array of ''Layer''s displayed in this "map"
*** MapFile -- path to resulting PNG file with rendered map
** '''Methods'''
*** AddRasterLayer -- Adds GRASS-raster layer to list of layers
*** AddVectorLayer -- Adds GRASS-vector layer to list of layers
*** Add...Layer -- Adds some type of layer (wms, wfs, text, ...) to list of layers
*** GetListOfLayers -- Returns array of layers (''active, hidden, type'')
*** Render -- Creates final PNG image and stores it's path to ''MapFile''

''TSW Comment: perhaps it would be simpler to have AddLayer and pass the type as a parameter. Automatic would be nice, but since it is possible for vector and raster files to have the same name, this wouldn't work. Another option to consider would be to use AddLayer as a base class AddLayerRaster, ... as subclasses. This would make things more modular and theoretically at least, easier to maintain and develop.''

''JC Comment: I made separate functions for raster and vector, because of their attributes are completely different. There should be also AddWMSLayer etc. functions. IMHO it does not matter, if we have general AddLayer with parameter layer_type, or separate functions for all layer types.''

* '''DigitToolbar''' -- Pop-up toolbar with digitising functions
* '''DisplayToolBar''' -- Pop-up toolbar with substitution of other d.* modules

* '''MapDisplay''' -- Frame (in [http://wiki.wxpython.org/index.cgi/Frequently_Asked_Questions#head-829eea79fe17c04c65c00a7dc0bffa69f2473167 wxWidgets terminology]) with embed toolbar for zooming and paning and maybe data quering and pop-up toolbar for substitution of other d.* modules (d.path, d.profile, ...)
NOTE: This section should be completed
** '''Attributes'''
*** Width
*** Height
*** Mouse -- mouse actions, movements, presed buttons etc.
*** Map -- ''Map'' class
** ''Methods'' -- just very coarse definition
*** Zoom -- for zooming and paning
*** DrawBox -- For box drawing
*** DrawLine -- For line drawing
*** DrawPoint -- for points drawing

* '''GisManager''' -- GIS Manager frame
** '''Attributes'''
*** Displays -- array with map displayes
** '''Methods'''
*** AddDisplay -- Creates new map display
*** AddLayer -- Adds layer of defined type
*** EditLayer -- Opens pop-up window with layer attributes definition
*** ExecuteCommand -- Executes module from command line or menu

* '''GCPDisplay''' -- Special type of MapDisplay with tool for setting GCPs
* '''HCPDisplay''' -- Special type of MapDisplay with tools for creating configuration files for hardcopy maps

=== Used tools ===
wxPython seems to be the best tool for "new generation gui", because of it's multiplatformity and native look&feel on various platforms.

* [http://www.poromenos.org/tutorials/python 10 minute Python tutorial] for programmers of other languages

=== Where to get it ===
Jachym suggests to move the development to GRASS-Addons subversion repository, until it is "mature enough". Subversion enables for example to rename files, which could be useful. Current version can be found at https://grasssvn.itc.it/grasssvn/grassaddons/trunk/grassaddons/gui/#_trunk_grassaddons_gui_ and downloaded with command

svn co https://grasssvn.itc.it/svn/grassaddons/trunk/grassaddons/gui

Write access to the GRASS-Addons SVN is managed by Markus Neteler.

=== Layout Concepts ===

==== Screenshots with proposed shapes ====

{| class="wikitable" style="text-align:center;" border="1"
| [[Image:Gism.png]] || [[Image:Gism2.jpeg]]
|-
| The wxGlade definition file is avaliable [https://grasssvn.itc.it/grasssvn/grassaddons/trunk/grassaddons/gui/gism.wxg in the subversion repository] || Another proposal by Michael Barton
|}

==== Discussion / Comments ====

If the goal is to move toward a single command line interface integrated into the GUI, perhaps we should use the shape of a terminal window as the the shape of the new GIS manager. In this way the layers tree could appear next to the layer attributes in the same way the currently gis.m displays the layer attributes below the tree. The downside to this is having space on the desktop.

Another possibility would be to link the command window to the map display in the shape of an xterm, in this way the gis manager could have a profile shape by default that could easily fit onto a single screen for those without multiple display systems. Another possibility that might be desirable is to be able to 'tear off' the command window separately or link it to either the GIS manager tree or the display window.

It appears in the screen shots that multiple command windows are being considered (1 per map). In some ways this is potentially quite elegant especially if they are set up as separate sessions altogether so we wouldn't need to use win override. What we do encounter is issues related to multiple users which are non-trivial. Still as the layout suggest this it may be worth considering the impact of this, although the current solution in gis.m is probably the best for now.

=== GUI History ===
'''[http://www.public.asu.edu/~cmbarton/files/grass_wxpython/ Link to wxPython prototype GUI for GRASS 6]'''

'''Update 18:02, 14 August 2006 (CEST) '''New version implements double buffered drawing to fix display issues on Debian, including flickering why panning and display being erased by overlaying windows. Output to PNG file added. Better looking zoom rectangles.

'''*****The wxPython code is moving to the GRASS CVS. You should look for the newest versions there. Volunteers to help with the new GUI are welcomed!*****''' [[User:Cmbarton|Cmbarton]]

'''Update 00:50, 9 August 2006 (CEST) '''New version will run directly from GRASS prompt with new startup script. Now put gism.py and associated files into $GISBASE/etc/gmwxp and add a new script (gm.wxp) to the $GISBASE/scripts folder. Then simply type gm.wxp& from the GRASS command prompt to get the new prototype wxPython GUI for GRASS. See instructions in today's package update. [[User:Cmbarton|Cmbarton]]

'''Update 23:59, 7 August 2006 (CEST) '''New version with nearly complete raster menu by Yann Chemin. [[User:Cmbarton|Cmbarton]]

'''Update 19:02, 7 August 2006 (CEST)'''I just uploaded a new version of gism.py and related files. I'll keep an archive and so am changing the link to go to the folder rather than the file itself so I won't have to keep changing the link. This update includes the following changes:
*The biggest change in wrapping in grassgui.py. This provides autogenerated wxPython GUI dialogs for all grass commands.
This can now be called from the command console (just type in the command name with no arguments as you do now) or the
prototype menus. I updated grassgui.py to current wxPython syntax (mostly) and added methods to make it callable from
other modules.
*Methods added to gism.py and grassgui.py that automatically restart them with pythonw for the Mac
--[[User:Cmbarton|Cmbarton]] 19:02, 7 August 2006 (CEST)

Initial development has begun on the next generation UI for GRASS. wxPython is the leading contender for a platform in which to continue development of the GRASS GUI. wxPython is a Python implementation of the well known wxWidgets (formerly wxWindows) interface development platform for C++. An initial demonstration was developed by Jachym Cepicky to show the possibility of controling GRASS via wxPython. A second generation prototype has been completed, building on Jachym's work. It is available for testing and further development at link above.
--[[User:Cmbarton|Cmbarton]] 07:15, 4 August 2006 (CEST)

== Components ==

=== Core GIS manager ===
* name? (does it even need one?)

=== Module GUIs ===
* Generate from XML --interface-description or new --wxpython switch?

=== Startup GUI ===
* for picking mapset etc

=== New location GUI ===
* Wizard for creating new location & region.
:see QGIS's one

=== Cartography: GUI front end for ps.map ===

* This is a cartographic composer, intended to be a stand alone hardcopy plot generator. It is not meant to be a '''Print''' button for the maps currently displayed in the GIS manager, that will need it own controls.

* The GUI will prepare a semi-WYSIWYG + tree menu controls which can write a ps.map control file, and then run ps.map to create PostScript and PDF output directly. Loading a ps.map control file is harder and can happen later.

* For a start at a Tcl/Tk composer see gui/tcltk/d.m/print.tcl

* Start with most important mapping instructions
** paper
** scale
** maploc
** rast
** vects
** grids
** scalebar
** mapinfo
** text labels

==== Outputs ====

* ps.map instructions file
* PostScript file [ps.map instructions tmp file]
* lpr [PostScript tmp file]
* PDF File (pstopdf? ps2pdf? GNU Ghostscript?) [PostScript tmp file]

==== Inputs ====

* Ability to load in saved ps.map scripts. I consider this to be a low priority, deal with it after map creation is fully functional. Start with scripts saved using the GUI, after that is working expand to load any ps.map instructions file.

=== Georectifier ===
* Should be a simple port of Michael's tcltk Georectifier for gis.m

=== Digitizer ===

==== Vector ====

* Rewrite v.digit. Replace r.digit (r.in.poly format isn't far from v.in.ascii standard format)
* v.edit?
* Integrate d.rast.edit, d.rast.num functionality in another tool?
* We can use QGIS's digitizer in the interim.
* When to drop v.digit?

==== Raster ====
* r.digit (merge with v.digit?)
* d.rast.edit
: Idea: get cell center coords and new values from GUI interaction, then pass those through r.in.xyz, and r.patch the new values over the top of the old map.

* merge with Georectifier? (i.points, i.vpoints)

==== Ortho photos ====
* To replace i.ortho.photo and friends

= Tcl/Tk GUI =
Screenshots: http://grass.itc.it/grass61/screenshots/index.php

===Draft GUI design specifications===

* See attached file

===Summary of 2005 discussions on next generation UI for GRASS===

* Attached file gives a distillation of several months of emails on the GRASS developers list. It includes a series of desired design features and specifications, along with supporting quotes.

===Compiled emails from 2005 discussions on next generation UI for GRASS===

* Attached file compiles all (or all that I could find) of the late 2005 emails on the GRASS developers list discussing proposed specifications for a next generation GRASS GUI. It is a series of rtm files that group the discussions according to a series of topics.

GRASS GUI

2007-03-02T16:53:06Z

⚠️Jachym: Comparing graphical toolkits from, sourceforge.net

= Graphical toolkit choise =
== Sourceforge.net statistics ==
http://sourceforge.net/softwaremap/trove_list.php

Projects using Python as programming language: 6217
Projects using '''GTK+''': 1328
Projects using '''GTK+''' graphical library and Python programming language: 348
Projects using '''GTK+''' graphical library and Python programming language and '''OpenGL''': 7
Projects using '''wxWidgets''': 880
Projects using '''wxWidgets''' graphical library and Python programming language: 360
Projects using '''wxWidgets''' graphical library and Python programming language and '''OpenGL''': 4

= wxPython GUI =

* Generic [[GRASS and Python]] wiki page

=== General GUI Design ===
''''' Move into [[GRASS_GUI#Components|Components]] section below '''''

==== User's point of view ====
* GUI has multiple map displays
* Each map display has several buttons for basic functions
** Zooming and Paning
** Data Quering
* Each map display will be able to fire up pop-up toolbar with more complicated and not-so-often-used display functions (substitutions for d.measure, d.profile, d.text, ...)
* Each map display will be able to fire up pop-up toolbar with v.digit substitution
* Monitors can be started from the command line and from the GIS Manager
* Monitors must be able to display following types of layers
** GRASS Raster
** GRASS Vector
** GDAL Raster
** GDAL Vector
** WMS Layer from remote server
** WCS and WFS layers too
** Text layers
** Graphics layers
** Grid
** Image layers
** ...
* GIS Manager is tool for
** Monitors management and monitor content management
** Layer look management
** Modules starting (from integrated command line or menu)
** Displaying output from modules (G_message, G_warning, G_fatal_error, G_percent)
* GIS Manager must be able to save and restore session
* There should be default session file, which will be loaded by default ones GRASS is started with -gui parameter
* Georectification tool should be part of new GUI. It should be special type of monitor with added GCP function
* Map Composer should be part of the new GUI. This tool should generate configuration files for hardcopy maps. The configuration files should be either ps.map files or maybe SVG

==== Coder's point of view ====
NOTE: As I have no coders background, sorry for inept formulated thoughts. --[[User:Jachym|Jachym]] 09:13, 2 February 2007 (CET)

List of suggested classes and their purpose.

* '''Layer''' -- Raster, vector, WMS, whatever layer
** '''Attributes''' -- Attributes are depending on layer type, but there are also common attributes marked with prefix "l_" (for 'layer'):
*** l_type -- vector, raster, wms, text, graph, ...
*** l_mapfile -- renderd ppm file
*** l_maskfile -- pgm file with layer's alpha channel
*** l_active -- layer is active, will be rendered only if True
*** l_hidden - layer is hidden, will be allways rendered
*** l_opacity - layer opacity [0-1]
** '''Methods'''
*** Render -- runs d.* and similar commands for making content of l_mapfile

* '''Map''' -- Set of layers renderd to single PNG image, ready to display in Map display frame
** '''Attributes'''
*** Width -- map width
*** Height -- map height
*** Region -- Region boundaries and resolution
*** Layers -- Array of ''Layer''s displayed in this "map"
*** MapFile -- path to resulting PNG file with rendered map
** '''Methods'''
*** AddRasterLayer -- Adds GRASS-raster layer to list of layers
*** AddVectorLayer -- Adds GRASS-vector layer to list of layers
*** Add...Layer -- Adds some type of layer (wms, wfs, text, ...) to list of layers
*** GetListOfLayers -- Returns array of layers (''active, hidden, type'')
*** Render -- Creates final PNG image and stores it's path to ''MapFile''

''TSW Comment: perhaps it would be simpler to have AddLayer and pass the type as a parameter. Automatic would be nice, but since it is possible for vector and raster files to have the same name, this wouldn't work. Another option to consider would be to use AddLayer as a base class AddLayerRaster, ... as subclasses. This would make things more modular and theoretically at least, easier to maintain and develop.''

''JC Comment: I made separate functions for raster and vector, because of their attributes are completely different. There should be also AddWMSLayer etc. functions. IMHO it does not matter, if we have general AddLayer with parameter layer_type, or separate functions for all layer types.''

* '''DigitToolbar''' -- Pop-up toolbar with digitising functions
* '''DisplayToolBar''' -- Pop-up toolbar with substitution of other d.* modules

* '''MapDisplay''' -- Frame (in [http://wiki.wxpython.org/index.cgi/Frequently_Asked_Questions#head-829eea79fe17c04c65c00a7dc0bffa69f2473167 wxWidgets terminology]) with embed toolbar for zooming and paning and maybe data quering and pop-up toolbar for substitution of other d.* modules (d.path, d.profile, ...)
NOTE: This section should be completed
** '''Attributes'''
*** Width
*** Height
*** Mouse -- mouse actions, movements, presed buttons etc.
*** Map -- ''Map'' class
** ''Methods'' -- just very coarse definition
*** Zoom -- for zooming and paning
*** DrawBox -- For box drawing
*** DrawLine -- For line drawing
*** DrawPoint -- for points drawing

* '''GisManager''' -- GIS Manager frame
** '''Attributes'''
*** Displays -- array with map displayes
** '''Methods'''
*** AddDisplay -- Creates new map display
*** AddLayer -- Adds layer of defined type
*** EditLayer -- Opens pop-up window with layer attributes definition
*** ExecuteCommand -- Executes module from command line or menu

* '''GCPDisplay''' -- Special type of MapDisplay with tool for setting GCPs
* '''HCPDisplay''' -- Special type of MapDisplay with tools for creating configuration files for hardcopy maps

=== Used tools ===
wxPython seems to be the best tool for "new generation gui", because of it's multiplatformity and native look&feel on various platforms.

* [http://www.poromenos.org/tutorials/python 10 minute Python tutorial] for programmers of other languages

=== Where to get it ===
Jachym suggests to move the development to GRASS-Addons subversion repository, until it is "mature enough". Subversion enables for example to rename files, which could be useful. Current version can be found at https://grasssvn.itc.it/grasssvn/grassaddons/trunk/grassaddons/gui/#_trunk_grassaddons_gui_ and downloaded with command

svn co https://grasssvn.itc.it/svn/grassaddons/trunk/grassaddons/gui

Write access to the GRASS-Addons SVN is managed by Markus Neteler.

=== Layout Concepts ===

==== Screenshots with proposed shapes ====

{| class="wikitable" style="text-align:center;" border="1"
| [[Image:Gism.png]] || [[Image:Gism2.jpeg]]
|-
| The wxGlade definition file is avaliable [https://grasssvn.itc.it/grasssvn/grassaddons/trunk/grassaddons/gui/gism.wxg in the subversion repository] || Another proposal by Michael Barton
|}

==== Discussion / Comments ====

If the goal is to move toward a single command line interface integrated into the GUI, perhaps we should use the shape of a terminal window as the the shape of the new GIS manager. In this way the layers tree could appear next to the layer attributes in the same way the currently gis.m displays the layer attributes below the tree. The downside to this is having space on the desktop.

Another possibility would be to link the command window to the map display in the shape of an xterm, in this way the gis manager could have a profile shape by default that could easily fit onto a single screen for those without multiple display systems. Another possibility that might be desirable is to be able to 'tear off' the command window separately or link it to either the GIS manager tree or the display window.

It appears in the screen shots that multiple command windows are being considered (1 per map). In some ways this is potentially quite elegant especially if they are set up as separate sessions altogether so we wouldn't need to use win override. What we do encounter is issues related to multiple users which are non-trivial. Still as the layout suggest this it may be worth considering the impact of this, although the current solution in gis.m is probably the best for now.

=== GUI History ===
'''[http://www.public.asu.edu/~cmbarton/files/grass_wxpython/ Link to wxPython prototype GUI for GRASS 6]'''

'''Update 18:02, 14 August 2006 (CEST) '''New version implements double buffered drawing to fix display issues on Debian, including flickering why panning and display being erased by overlaying windows. Output to PNG file added. Better looking zoom rectangles.

'''*****The wxPython code is moving to the GRASS CVS. You should look for the newest versions there. Volunteers to help with the new GUI are welcomed!*****''' [[User:Cmbarton|Cmbarton]]

'''Update 00:50, 9 August 2006 (CEST) '''New version will run directly from GRASS prompt with new startup script. Now put gism.py and associated files into $GISBASE/etc/gmwxp and add a new script (gm.wxp) to the $GISBASE/scripts folder. Then simply type gm.wxp& from the GRASS command prompt to get the new prototype wxPython GUI for GRASS. See instructions in today's package update. [[User:Cmbarton|Cmbarton]]

'''Update 23:59, 7 August 2006 (CEST) '''New version with nearly complete raster menu by Yann Chemin. [[User:Cmbarton|Cmbarton]]

'''Update 19:02, 7 August 2006 (CEST)'''I just uploaded a new version of gism.py and related files. I'll keep an archive and so am changing the link to go to the folder rather than the file itself so I won't have to keep changing the link. This update includes the following changes:
*The biggest change in wrapping in grassgui.py. This provides autogenerated wxPython GUI dialogs for all grass commands.
This can now be called from the command console (just type in the command name with no arguments as you do now) or the
prototype menus. I updated grassgui.py to current wxPython syntax (mostly) and added methods to make it callable from
other modules.
*Methods added to gism.py and grassgui.py that automatically restart them with pythonw for the Mac
--[[User:Cmbarton|Cmbarton]] 19:02, 7 August 2006 (CEST)

Initial development has begun on the next generation UI for GRASS. wxPython is the leading contender for a platform in which to continue development of the GRASS GUI. wxPython is a Python implementation of the well known wxWidgets (formerly wxWindows) interface development platform for C++. An initial demonstration was developed by Jachym Cepicky to show the possibility of controling GRASS via wxPython. A second generation prototype has been completed, building on Jachym's work. It is available for testing and further development at link above.
--[[User:Cmbarton|Cmbarton]] 07:15, 4 August 2006 (CEST)

== Components ==

=== Core GIS manager ===
* name? (does it even need one?)

=== Module GUIs ===
* Generate from XML --interface-description or new --wxpython switch?

=== Startup GUI ===
* for picking mapset etc

=== New location GUI ===
* Wizard for creating new location & region.
:see QGIS's one

=== Cartography: GUI front end for ps.map ===

* This is a cartographic composer, intended to be a stand alone hardcopy plot generator. It is not meant to be a '''Print''' button for the maps currently displayed in the GIS manager, that will need it own controls.

* The GUI will prepare a semi-WYSIWYG + tree menu controls which can write a ps.map control file, and then run ps.map to create PostScript and PDF output directly. Loading a ps.map control file is harder and can happen later.

* For a start at a Tcl/Tk composer see gui/tcltk/d.m/print.tcl

* Start with most important mapping instructions
** paper
** scale
** maploc
** rast
** vects
** grids
** scalebar
** mapinfo
** text labels

==== Outputs ====

* ps.map instructions file
* PostScript file [ps.map instructions tmp file]
* lpr [PostScript tmp file]
* PDF File (pstopdf? ps2pdf? GNU Ghostscript?) [PostScript tmp file]

==== Inputs ====

* Ability to load in saved ps.map scripts. I consider this to be a low priority, deal with it after map creation is fully functional. Start with scripts saved using the GUI, after that is working expand to load any ps.map instructions file.

=== Georectifier ===
* Should be a simple port of Michael's tcltk Georectifier for gis.m

=== Digitizer ===

==== Vector ====

* Rewrite v.digit. Replace r.digit (r.in.poly format isn't far from v.in.ascii standard format)
* v.edit?
* Integrate d.rast.edit, d.rast.num functionality in another tool?
* We can use QGIS's digitizer in the interim.
* When to drop v.digit?

==== Raster ====
* r.digit (merge with v.digit?)
* d.rast.edit
: Idea: get cell center coords and new values from GUI interaction, then pass those through r.in.xyz, and r.patch the new values over the top of the old map.

* merge with Georectifier? (i.points, i.vpoints)

==== Ortho photos ====
* To replace i.ortho.photo and friends

= Tcl/Tk GUI =
Screenshots: http://grass.itc.it/grass61/screenshots/index.php

===Draft GUI design specifications===

* See attached file

===Summary of 2005 discussions on next generation UI for GRASS===

* Attached file gives a distillation of several months of emails on the GRASS developers list. It includes a series of desired design features and specifications, along with supporting quotes.

===Compiled emails from 2005 discussions on next generation UI for GRASS===

* Attached file compiles all (or all that I could find) of the late 2005 emails on the GRASS developers list discussing proposed specifications for a next generation GRASS GUI. It is a series of rtm files that group the discussions according to a series of topics.

Development Specs

2007-02-28T09:00:50Z

⚠️Jachym: /* Verbosity levels */

== Systematic Approach ==
* Collect all possible error states from functions
* assign error codes for macros?

* G_option() parameters (like output->description = ("Path to resulting ASCII file");)

== How should Errors/Warnings/Messages be formatted ==
* strings < >
* numbers [ ]

== Macros to be defined for C library ==
* MSG_RASTER_NOT_FOUND_IN_MAPSET - "Raster map <%s> not found in <%s>"
* MSG_CANNOT_OPEN_RASTER - "Failed opening raster map <%s>"
* MSG_CANNOT_OPEN_FILE - Cannot open file <%s>

== Parameters and flags ==

Fix the parameters and flags. Make it a concept. See proposal in GRASS 5 [http://freegis.org/cgi-bin/viewcvs.cgi/grass/documents/parameter_proposal.txt?rev=HEAD&content-type=text/vnd.viewcvs-markup documents/parameter_proposal.txt]

== Verbosity levels ==

;Abstract concept

{|
|-
|standard || 3 || PERMSG_MODE || print progress and messages
|-
|standard || 2 || MESSAGE_MODE || print only messages
|-
|brief || 1 || PERCENT_MODE || print only progress information
|-
|silent but not mute || 0 || QUIET_MODE || print nothing (but ERR and WAR)
|-
|mute || 2>&1 > /dev/null
|-
|}

;Proposal

* module output (should be "parsable") is not controlled by GRASS_VERBOSE [use fprintf (stdout, ...)]
* silent
** only warnings and fatal errors are printed
* brief
** all G_percent() and selected G_message() (especially connected to progress information, up to the programmer ??)
* standard
** all G_percent() and selected G_message()
* verbose
** all G_percent() + G_message()

;Modification

* remove verbose level → standard == all G_percent () + G_messages()
* move some messages to G_debug()

GRASS SoC Ideas 2007

2007-02-27T17:33:31Z

⚠️Jachym:

GRASS related ideas for the [http://wiki.osgeo.org/index.php/Google_Summer_of_Code Google Summer of Code] 2007:

* carry on the work on r.li --[[User:Cavallini|Cavallini]] 14:37, 27 February 2007 (CET)
* better implement PostGIS support
* integrate GDAL as part of GRASS raster library
* integrate OGR as part of GRASS vector library

=== See also ===

* [http://wiki.osgeo.org/index.php/Google_Summer_of_Code OSGeo involvement Google Summer of Code]

[[Category:Development]]

GRASS GUI

2007-02-09T10:29:52Z

⚠️Jachym: /* Coder's point of view */

= wxPython GUI =
=== General GUI Design ===
''''' Move into [[GRASS_GUI#Components|Components]] section below '''''

==== User's point of view ====
* GUI has multiple map displays
* Each map display has several buttons for basic functions
** Zooming and Paning
** Data Quering
* Each map display will be able to fire up pop-up toolbar with more complicated and not-so-often-used display functions (substitutions for d.measure, d.profile, d.text, ...)
* Each map display will be able to fire up pop-up toolbar with v.digit substitution
* Monitors can be started from the command line and from the GIS Manager
* Monitors must be able to display following types of layers
** GRASS Raster
** GRASS Vector
** GDAL Raster
** GDAL Vector
** WMS Layer from remote server
** WCS and WFS layers too
** Text layers
** Graphics layers
** Grid
** Image layers
** ...
* GIS Manager is tool for
** Monitors management and monitor content management
** Layer look management
** Modules starting (from integrated command line or menu)
** Displaying output from modules (G_message, G_warning, G_fatal_error, G_percent)
* GIS Manager must be able to save and restore session
* There should be default session file, which will be loaded by default ones GRASS is started with -gui parameter
* Georectification tool should be part of new GUI. It should be special type of monitor with added GCP function
* Map Composer should be part of the new GUI. This tool should generate configuration files for hardcopy maps. The configuration files should be either ps.map files or maybe SVG

==== Coder's point of view ====
NOTE: As I have no coders background, sorry for inept formulated thoughts. --[[User:Jachym|Jachym]] 09:13, 2 February 2007 (CET)

List of suggested classes and their purpose.

* '''Layer''' -- Raster, vector, WMS, whatever layer
** '''Attributes''' -- Attributes are depending on layer type, but there are also common attributes marked with prefix "l_" (for 'layer'):
*** l_type -- vector, raster, wms, text, graph, ...
*** l_mapfile -- renderd ppm file
*** l_maskfile -- pgm file with layer's alpha channel
*** l_active -- layer is active, will be rendered only if True
*** l_hidden - layer is hidden, will be allways rendered
*** l_opacity - layer opacity [0-1]
** '''Methods'''
*** Render -- runs d.* and similar commands for making content of l_mapfile

* '''Map''' -- Set of layers renderd to single PNG image, ready to display in Map display frame
** '''Attributes'''
*** Width -- map width
*** Height -- map height
*** Region -- Region boundaries and resolution
*** Layers -- Array of ''Layer''s displayed in this "map"
*** MapFile -- path to resulting PNG file with rendered map
** '''Methods'''
*** AddRasterLayer -- Adds GRASS-raster layer to list of layers
*** AddVectorLayer -- Adds GRASS-vector layer to list of layers
*** Add...Layer -- Adds some type of layer (wms, wfs, text, ...) to list of layers
*** GetListOfLayers -- Returns array of layers (''active, hidden, type'')
*** Render -- Creates final PNG image and stores it's path to ''MapFile''

''TSW Comment: perhaps it would be simpler to have AddLayer and pass the type as a parameter. Automatic would be nice, but since it is possible for vector and raster files to have the same name, this wouldn't work. Another option to consider would be to use AddLayer as a base class AddLayerRaster, ... as subclasses. This would make things more modular and theoretically at least, easier to maintain and develop.''

''JC Comment: I made separate functions for raster and vector, because of their attributes are completely different. There should be also AddWMSLayer etc. functions. IMHO it does not matter, if we have general AddLayer with parameter layer_type, or separate functions for all layer types.''

* '''DigitToolbar''' -- Pop-up toolbar with digitising functions
* '''DisplayToolBar''' -- Pop-up toolbar with substitution of other d.* modules

* '''MapDisplay''' -- Frame (in [http://wiki.wxpython.org/index.cgi/Frequently_Asked_Questions#head-829eea79fe17c04c65c00a7dc0bffa69f2473167 wxWidgets terminology]) with embed toolbar for zooming and paning and maybe data quering and pop-up toolbar for substitution of other d.* modules (d.path, d.profile, ...)
NOTE: This section should be completed
** '''Attributes'''
*** Width
*** Height
*** Mouse -- mouse actions, movements, presed buttons etc.
*** Map -- ''Map'' class
** ''Methods'' -- just very coarse definition
*** Zoom -- for zooming and paning
*** DrawBox -- For box drawing
*** DrawLine -- For line drawing
*** DrawPoint -- for points drawing

* '''GisManager''' -- GIS Manager frame
** '''Attributes'''
*** Displays -- array with map displayes
** '''Methods'''
*** AddDisplay -- Creates new map display
*** AddLayer -- Adds layer of defined type
*** EditLayer -- Opens pop-up window with layer attributes definition
*** ExecuteCommand -- Executes module from command line or menu

* '''GCPDisplay''' -- Special type of MapDisplay with tool for setting GCPs
* '''HCPDisplay''' -- Special type of MapDisplay with tools for creating configuration files for hardcopy maps

=== Used tools ===
wxPython seems to be the best tool for "new generation gui", because of it's multiplatformity and native look&feel on various platforms.

=== Where to get it ===
Jachym suggests to move the development to GRASS-Addons subversion repository, until it is "mature enough". Subversion enables for example to rename files, which could be useful. Current version can be found at https://grasssvn.itc.it/grasssvn/grassaddons/trunk/grassaddons/gui/#_trunk_grassaddons_gui_ and downloaded with command

svn co https://grasssvn.itc.it/svn/grassaddons/trunk/grassaddons grassaddons/gui

Write access to the GRASS-Addons SVN is managed by Markus Neteler.

=== Layout Concepts ===

==== Screenshots with proposed shapes ====

{| class="wikitable" style="text-align:center;" border="1"
| [[Image:Gism.png]] || [[Image:Gism2.jpeg]]
|-
| The wxGlade definition file is avaliable [https://grasssvn.itc.it/grasssvn/grassaddons/trunk/grassaddons/gui/gism.wxg in the subversion repository] || Another proposal by Michael Barton
|}

==== Discussion / Comments ====

If the goal is to move toward a single command line interface integrated into the GUI, perhaps we should use the shape of a terminal window as the the shape of the new GIS manager. In this way the layers tree could appear next to the layer attributes in the same way the currently gis.m displays the layer attributes below the tree. The downside to this is having space on the desktop.

Another possibility would be to link the command window to the map display in the shape of an xterm, in this way the gis manager could have a profile shape by default that could easily fit onto a single screen for those without multiple display systems. Another possibility that might be desirable is to be able to 'tear off' the command window separately or link it to either the GIS manager tree or the display window.

It appears in the screen shots that multiple command windows are being considered (1 per map). In some ways this is potentially quite elegant especially if they are set up as separate sessions altogether so we wouldn't need to use win override. What we do encounter is issues related to multiple users which are non-trivial. Still as the layout suggest this it may be worth considering the impact of this, although the current solution in gis.m is probably the best for now.

=== GUI History ===
'''[http://www.public.asu.edu/~cmbarton/files/grass_wxpython/ Link to wxPython prototype GUI for GRASS 6]'''

'''Update 18:02, 14 August 2006 (CEST) '''New version implements double buffered drawing to fix display issues on Debian, including flickering why panning and display being erased by overlaying windows. Output to PNG file added. Better looking zoom rectangles.

'''*****The wxPython code is moving to the GRASS CVS. You should look for the newest versions there. Volunteers to help with the new GUI are welcomed!*****''' [[User:Cmbarton|Cmbarton]]

'''Update 00:50, 9 August 2006 (CEST) '''New version will run directly from GRASS prompt with new startup script. Now put gism.py and associated files into $GISBASE/etc/gmwxp and add a new script (gm.wxp) to the $GISBASE/scripts folder. Then simply type gm.wxp& from the GRASS command prompt to get the new prototype wxPython GUI for GRASS. See instructions in today's package update. [[User:Cmbarton|Cmbarton]]

'''Update 23:59, 7 August 2006 (CEST) '''New version with nearly complete raster menu by Yann Chemin. [[User:Cmbarton|Cmbarton]]

'''Update 19:02, 7 August 2006 (CEST)'''I just uploaded a new version of gism.py and related files. I'll keep an archive and so am changing the link to go to the folder rather than the file itself so I won't have to keep changing the link. This update includes the following changes:
*The biggest change in wrapping in grassgui.py. This provides autogenerated wxPython GUI dialogs for all grass commands.
This can now be called from the command console (just type in the command name with no arguments as you do now) or the
prototype menus. I updated grassgui.py to current wxPython syntax (mostly) and added methods to make it callable from
other modules.
*Methods added to gism.py and grassgui.py that automatically restart them with pythonw for the Mac
--[[User:Cmbarton|Cmbarton]] 19:02, 7 August 2006 (CEST)

Initial development has begun on the next generation UI for GRASS. wxPython is the leading contender for a platform in which to continue development of the GRASS GUI. wxPython is a Python implementation of the well known wxWidgets (formerly wxWindows) interface development platform for C++. An initial demonstration was developed by Jachym Cepicky to show the possibility of controling GRASS via wxPython. A second generation prototype has been completed, building on Jachym's work. It is available for testing and further development at link above.
--[[User:Cmbarton|Cmbarton]] 07:15, 4 August 2006 (CEST)

== Components ==

=== Core GIS manager ===
* name? (does it even need one?)

=== Module GUIs ===
* Generate from XML --interface-description or new --wxpython switch?

=== Startup GUI ===
* for picking mapset etc

=== New location GUI ===
* Wizard for creating new location & region.
:see QGIS's one

=== Cartography: GUI front end for ps.map ===

* This is a cartographic composer, intended to be a stand alone hardcopy plot generator. It is not meant to be a '''Print''' button for the maps currently displayed in the GIS manager, that will need it own controls.

* The GUI will prepare a semi-WYSIWYG + tree menu controls which can write a ps.map control file, and then run ps.map to create PostScript and PDF output directly. Loading a ps.map control file is harder and can happen later.

* For a start at a Tcl/Tk composer see gui/tcltk/d.m/print.tcl

* Start with most important mapping instructions
** paper
** scale
** maploc
** rast
** vects
** grids
** scalebar
** mapinfo
** text labels

==== Outputs ====

* ps.map instructions file
* PostScript file [ps.map instructions tmp file]
* lpr [PostScript tmp file]
* PDF File (pstopdf? ps2pdf? GNU Ghostscript?) [PostScript tmp file]

==== Inputs ====

* Ability to load in saved ps.map scripts. I consider this to be a low priority, deal with it after map creation is fully functional. Start with scripts saved using the GUI, after that is working expand to load any ps.map instructions file.

=== Georectifier ===
* Should be a simple port of Michael's tcltk Georectifier for gis.m

=== Digitizer ===
* Rewrite v.digit. Replace r.digit (r.in.poly format isn't far from v.in.ascii standard format)
* v.edit?
* Integrate d.rast.edit, d.rast.num functionality in another tool?

= Tcl/Tk GUI =
Screenshots: http://grass.itc.it/grass61/screenshots/index.php

===Draft GUI design specifications===

* See attached file

===Summary of 2005 discussions on next generation UI for GRASS===

* Attached file gives a distillation of several months of emails on the GRASS developers list. It includes a series of desired design features and specifications, along with supporting quotes.

===Compiled emails from 2005 discussions on next generation UI for GRASS===

* Attached file compiles all (or all that I could find) of the late 2005 emails on the GRASS developers list discussing proposed specifications for a next generation GRASS GUI. It is a series of rtm files that group the discussions according to a series of topics.

GRASS GUI

2007-02-02T16:03:17Z

⚠️Jachym: /* Screenshots with proposed shapes */

== wxPython GUI ==
=== General GUI Design ===
==== User's point of view ====
* GUI has multiple map displays
* Each map display has several buttons for basic functions
** Zooming and Paning
** Data Quering
* Each map display will be able to fire up pop-up toolbar with more complicated and not-so-often-used display functions (substitutions for d.measure, d.profile, d.text, ...)
* Each map display will be able to fire up pop-up toolbar with v.digit substitution
* Monitors can be started from the command line and from the GIS Manager
* Monitors must be able to display following types of layers
** GRASS Raster
** GRASS Vector
** GDAL Raster
** GDAL Vector
** WMS Layer from remote server
** WCS and WFS layers too
** Text layers
** Graphics layers
** Grid
** Image layers
** ...
* GIS Manager is tool for
** Monitors management and monitor content management
** Layer look management
** Modules starting (from integrated command line or menu)
** Displaying output from modules (G_message, G_warning, G_fatal_error, G_percent)
* GIS Manager must be able to save and restore session
* There should be default session file, which will be loaded by default ones GRASS is started with -gui parameter
* Georectification tool should be part of new GUI. It should be special type of monitor with added GCP function
* Map Composer should be part of the new GUI. This tool should generate configuration files for hardcopy maps. The configuration files should be either ps.map files or maybe SVG

==== Coder's point of view ====
NOTE: As I have no coders background, sorry for inept formulated thoughts. --[[User:Jachym|Jachym]] 09:13, 2 February 2007 (CET)

List of suggested classes and their purpose.

* '''Layer''' -- Raster, vector, WMS, whatever layer
** '''Attributes''' -- Attributes are depending on layer type, but there are also common attributes marked with prefix "l_" (for 'layer'):
*** l_type -- vector, raster, wms, text, graph, ...
*** l_mapfile -- renderd ppm file
*** l_maskfile -- pgm file with layer's alpha channel
*** l_active -- layer is active, will be rendered only if True
*** l_hidden - layer is hidden, will be allways rendered
*** l_opacity - layer opacity [0-1]
** '''Methods'''
*** Render -- runs d.* and similar commands for making content of l_mapfile

* '''Map''' -- Set of layers renderd to single PNG image, ready to display in Map display frame
** '''Attributes'''
*** Width -- map width
*** Height -- map height
*** Region -- Region boundaries and resolution
*** Layers -- Array of ''Layer''s displayed in this "map"
*** MapFile -- path to resulting PNG file with rendered map
** '''Methods'''
*** AddRasterLayer -- Adds GRASS-raster layer to list of layers
*** AddVectorLayer -- Adds GRASS-vector layer to list of layers
*** Add...Layer -- Adds some type of layer (wms, wfs, text, ...) to list of layers
*** GetListOfLayers -- Returns array of layers (''active, hidden, type'')
*** Render -- Creates final PNG image and stores it's path to ''MapFile''

* '''DigitToolbar''' -- Pop-up toolbar with digitising functions
* '''DisplayToolBar''' -- Pop-up toolbar with substitution of other d.* modules

* '''MapDisplay''' -- Frame (in [http://wiki.wxpython.org/index.cgi/Frequently_Asked_Questions#head-829eea79fe17c04c65c00a7dc0bffa69f2473167 wxWidgets terminology]) with embed toolbar for zooming and paning and maybe data quering and pop-up toolbar for substitution of other d.* modules (d.path, d.profile, ...)
NOTE: This section should be completed
** '''Attributes'''
*** Width
*** Height
*** Mouse -- mouse actions, movements, presed buttons etc.
*** Map -- ''Map'' class
** ''Methods'' -- just very coarse definition
*** Zoom -- for zooming and paning
*** DrawBox -- For box drawing
*** DrawLine -- For line drawing
*** DrawPoint -- for points drawing

* '''GisManager''' -- GIS Manager frame
** '''Attributes'''
*** Displays -- array with map displayes
** '''Methods'''
*** AddDisplay -- Creates new map display
*** AddLayer -- Adds layer of defined type
*** EditLayer -- Opens pop-up window with layer attributes definition
*** ExecuteCommand -- Executes module from command line or menu

* '''GCPDisplay''' -- Special type of MapDisplay with tool for setting GCPs
* '''HCPDisplay''' -- Special type of MapDisplay with tools for creating configuration files for hardcopy maps

=== Used tools ===
wxPython seems to be the best tool for "new generation gui", because of it's multiplatformity and native look&feel on various platforms.

=== Where to get it ===
Jachym suggests to move the development to GRASS-Addons subversion repository, until it is "mature enough". Subversion enables for example to rename files, which could be useful. Current version can be found at https://grasssvn.itc.it/grasssvn/grassaddons/trunk/grassaddons/gui/#_trunk_grassaddons_gui_ and downloaded with command

svn co https://grasssvn.itc.it/svn/grassaddons/trunk/grassaddons grassaddons/gui

Write access to the GRASS-Addons SVN is managed by Markus Neteler.

=== Screenshots with proposed shapes ===

{| class="wikitable" style="text-align:center;" border="1"
| [[Image:Gism.png]] || [[Image:Gism2.jpeg]]
|-
| The wxGlade definition file is avaliable [https://grasssvn.itc.it/grasssvn/grassaddons/trunk/grassaddons/gui/gism.wxg in the subversion repository] || Another proposal by Michael Barton
|}

=== GUI History ===
'''[http://www.public.asu.edu/~cmbarton/files/grass_wxpython/ Link to wxPython prototype GUI for GRASS 6]'''

'''Update 18:02, 14 August 2006 (CEST) '''New version implements double buffered drawing to fix display issues on Debian, including flickering why panning and display being erased by overlaying windows. Output to PNG file added. Better looking zoom rectangles.

'''*****The wxPython code is moving to the GRASS CVS. You should look for the newest versions there. Volunteers to help with the new GUI are welcomed!*****''' [[User:Cmbarton|Cmbarton]]

'''Update 00:50, 9 August 2006 (CEST) '''New version will run directly from GRASS prompt with new startup script. Now put gism.py and associated files into $GISBASE/etc/gmwxp and add a new script (gm.wxp) to the $GISBASE/scripts folder. Then simply type gm.wxp& from the GRASS command prompt to get the new prototype wxPython GUI for GRASS. See instructions in today's package update. [[User:Cmbarton|Cmbarton]]

'''Update 23:59, 7 August 2006 (CEST) '''New version with nearly complete raster menu by Yann Chemin. [[User:Cmbarton|Cmbarton]]

'''Update 19:02, 7 August 2006 (CEST)'''I just uploaded a new version of gism.py and related files. I'll keep an archive and so am changing the link to go to the folder rather than the file itself so I won't have to keep changing the link. This update includes the following changes:
*The biggest change in wrapping in grassgui.py. This provides autogenerated wxPython GUI dialogs for all grass commands.
This can now be called from the command console (just type in the command name with no arguments as you do now) or the
prototype menus. I updated grassgui.py to current wxPython syntax (mostly) and added methods to make it callable from
other modules.
*Methods added to gism.py and grassgui.py that automatically restart them with pythonw for the Mac
--[[User:Cmbarton|Cmbarton]] 19:02, 7 August 2006 (CEST)

Initial development has begun on the next generation UI for GRASS. wxPython is the leading contender for a platform in which to continue development of the GRASS GUI. wxPython is a Python implementation of the well known wxWidgets (formerly wxWindows) interface development platform for C++. An initial demonstration was developed by Jachym Cepicky to show the possibility of controling GRASS via wxPython. A second generation prototype has been completed, building on Jachym's work. It is available for testing and further development at link above.
--[[User:Cmbarton|Cmbarton]] 07:15, 4 August 2006 (CEST)

== Tcl/Tk GUI ==
Screenshots: http://grass.itc.it/grass61/screenshots/index.php

===Draft GUI design specifications===

* See attached file

===Summary of 2005 discussions on next generation UI for GRASS===

* Attached file gives a distillation of several months of emails on the GRASS developers list. It includes a series of desired design features and specifications, along with supporting quotes.

===Compiled emails from 2005 discussions on next generation UI for GRASS===

* Attached file compiles all (or all that I could find) of the late 2005 emails on the GRASS developers list discussing proposed specifications for a next generation GRASS GUI. It is a series of rtm files that group the discussions according to a series of topics.

File:Gism2.jpeg

2007-02-02T15:57:28Z

⚠️Jachym: Proposed screenshot from Michael

Proposed screenshot from Michael

GRASS GUI

2007-02-02T09:20:34Z

⚠️Jachym: /* Proposed screenshots */

== wxPython GUI ==
=== General GUI Design ===
==== User's point of view ====
* GUI has multiple map displays
* Each map display has several buttons for basic functions
** Zooming and Paning
** Data Quering
* Each map display will be able to fire up pop-up toolbar with more complicated and not-so-often-used display functions (substitutions for d.measure, d.profile, d.text, ...)
* Each map display will be able to fire up pop-up toolbar with v.digit substitution
* Monitors can be started from the command line and from the GIS Manager
* Monitors must be able to display following types of layers
** GRASS Raster
** GRASS Vector
** GDAL Raster
** GDAL Vector
** WMS Layer from remote server
** WCS and WFS layers too
** Text layers
** Graphics layers
** Grid
** Image layers
** ...
* GIS Manager is tool for
** Monitors management and monitor content management
** Layer look management
** Modules starting (from integrated command line or menu)
** Displaying output from modules (G_message, G_warning, G_fatal_error, G_percent)
* GIS Manager must be able to save and restore session
* There should be default session file, which will be loaded by default ones GRASS is started with -gui parameter
* Georectification tool should be part of new GUI. It should be special type of monitor with added GCP function
* Map Composer should be part of the new GUI. This tool should generate configuration files for hardcopy maps. The configuration files should be either ps.map files or maybe SVG

==== Coder's point of view ====
NOTE: As I have no coders background, sorry for inept formulated thoughts. --[[User:Jachym|Jachym]] 09:13, 2 February 2007 (CET)

List of suggested classes and their purpose.

* '''Layer''' -- Raster, vector, WMS, whatever layer
** '''Attributes''' -- Attributes are depending on layer type, but there are also common attributes marked with prefix "l_" (for 'layer'):
*** l_type -- vector, raster, wms, text, graph, ...
*** l_mapfile -- renderd ppm file
*** l_maskfile -- pgm file with layer's alpha channel
*** l_active -- layer is active, will be rendered only if True
*** l_hidden - layer is hidden, will be allways rendered
*** l_opacity - layer opacity [0-1]
** '''Methods'''
*** Render -- runs d.* and similar commands for making content of l_mapfile

* '''Map''' -- Set of layers renderd to single PNG image, ready to display in Map display frame
** '''Attributes'''
*** Width -- map width
*** Height -- map height
*** Region -- Region boundaries and resolution
*** Layers -- Array of ''Layer''s displayed in this "map"
*** MapFile -- path to resulting PNG file with rendered map
** '''Methods'''
*** AddRasterLayer -- Adds GRASS-raster layer to list of layers
*** AddVectorLayer -- Adds GRASS-vector layer to list of layers
*** Add...Layer -- Adds some type of layer (wms, wfs, text, ...) to list of layers
*** GetListOfLayers -- Returns array of layers (''active, hidden, type'')
*** Render -- Creates final PNG image and stores it's path to ''MapFile''

* '''DigitToolbar''' -- Pop-up toolbar with digitising functions
* '''DisplayToolBar''' -- Pop-up toolbar with substitution of other d.* modules

* '''MapDisplay''' -- Frame (in [http://wiki.wxpython.org/index.cgi/Frequently_Asked_Questions#head-829eea79fe17c04c65c00a7dc0bffa69f2473167 wxWidgets terminology]) with embed toolbar for zooming and paning and maybe data quering and pop-up toolbar for substitution of other d.* modules (d.path, d.profile, ...)
NOTE: This section should be completed
** '''Attributes'''
*** Width
*** Height
*** Mouse -- mouse actions, movements, presed buttons etc.
*** Map -- ''Map'' class
** ''Methods'' -- just very coarse definition
*** Zoom -- for zooming and paning
*** DrawBox -- For box drawing
*** DrawLine -- For line drawing
*** DrawPoint -- for points drawing

* '''GisManager''' -- GIS Manager frame
** '''Attributes'''
*** Displays -- array with map displayes
** '''Methods'''
*** AddDisplay -- Creates new map display
*** AddLayer -- Adds layer of defined type
*** EditLayer -- Opens pop-up window with layer attributes definition
*** ExecuteCommand -- Executes module from command line or menu

* '''GCPDisplay''' -- Special type of MapDisplay with tool for setting GCPs
* '''HCPDisplay''' -- Special type of MapDisplay with tools for creating configuration files for hardcopy maps

=== Used tools ===
wxPython seems to be the best tool for "new generation gui", because of it's multiplatformity and native look&feel on various platforms.

=== Where to get it ===
Jachym suggests to move the development to GRASS-Addons subversion repository, until it is "mature enough". Subversion enables for example to rename files, which could be useful. Current version can be found at https://grasssvn.itc.it/grasssvn/grassaddons/trunk/grassaddons/gui/#_trunk_grassaddons_gui_ and downloaded with command

svn co https://grasssvn.itc.it/svn/grassaddons/trunk/grassaddons grassaddons/gui

=== Screenshots with proposed shapes ===
[[Image:Gism.png]]
The wxGlade definition file is avaliable [https://grasssvn.itc.it/grasssvn/grassaddons/trunk/grassaddons/gui/gism.wxg in the subversion repository]

=== GUI History ===
'''[http://www.public.asu.edu/~cmbarton/files/grass_wxpython/ Link to wxPython prototype GUI for GRASS 6]'''

'''Update 18:02, 14 August 2006 (CEST) '''New version implements double buffered drawing to fix display issues on Debian, including flickering why panning and display being erased by overlaying windows. Output to PNG file added. Better looking zoom rectangles.

'''*****The wxPython code is moving to the GRASS CVS. You should look for the newest versions there. Volunteers to help with the new GUI are welcomed!*****''' [[User:Cmbarton|Cmbarton]]

'''Update 00:50, 9 August 2006 (CEST) '''New version will run directly from GRASS prompt with new startup script. Now put gism.py and associated files into $GISBASE/etc/gmwxp and add a new script (gm.wxp) to the $GISBASE/scripts folder. Then simply type gm.wxp& from the GRASS command prompt to get the new prototype wxPython GUI for GRASS. See instructions in today's package update. [[User:Cmbarton|Cmbarton]]

'''Update 23:59, 7 August 2006 (CEST) '''New version with nearly complete raster menu by Yann Chemin. [[User:Cmbarton|Cmbarton]]

'''Update 19:02, 7 August 2006 (CEST)'''I just uploaded a new version of gism.py and related files. I'll keep an archive and so am changing the link to go to the folder rather than the file itself so I won't have to keep changing the link. This update includes the following changes:
*The biggest change in wrapping in grassgui.py. This provides autogenerated wxPython GUI dialogs for all grass commands.
This can now be called from the command console (just type in the command name with no arguments as you do now) or the
prototype menus. I updated grassgui.py to current wxPython syntax (mostly) and added methods to make it callable from
other modules.
*Methods added to gism.py and grassgui.py that automatically restart them with pythonw for the Mac
--[[User:Cmbarton|Cmbarton]] 19:02, 7 August 2006 (CEST)

Initial development has begun on the next generation UI for GRASS. wxPython is the leading contender for a platform in which to continue development of the GRASS GUI. wxPython is a Python implementation of the well known wxWidgets (formerly wxWindows) interface development platform for C++. An initial demonstration was developed by Jachym Cepicky to show the possibility of controling GRASS via wxPython. A second generation prototype has been completed, building on Jachym's work. It is available for testing and further development at link above.
--[[User:Cmbarton|Cmbarton]] 07:15, 4 August 2006 (CEST)

== Tcl/Tk GUI ==
Screenshots: http://grass.itc.it/grass61/screenshots/index.php

===Draft GUI design specifications===

* See attached file

===Summary of 2005 discussions on next generation UI for GRASS===

* Attached file gives a distillation of several months of emails on the GRASS developers list. It includes a series of desired design features and specifications, along with supporting quotes.

===Compiled emails from 2005 discussions on next generation UI for GRASS===

* Attached file compiles all (or all that I could find) of the late 2005 emails on the GRASS developers list discussing proposed specifications for a next generation GRASS GUI. It is a series of rtm files that group the discussions according to a series of topics.

GRASS GUI

2007-02-02T09:20:07Z

⚠️Jachym: /* Where to get it */

== wxPython GUI ==
=== General GUI Design ===
==== User's point of view ====
* GUI has multiple map displays
* Each map display has several buttons for basic functions
** Zooming and Paning
** Data Quering
* Each map display will be able to fire up pop-up toolbar with more complicated and not-so-often-used display functions (substitutions for d.measure, d.profile, d.text, ...)
* Each map display will be able to fire up pop-up toolbar with v.digit substitution
* Monitors can be started from the command line and from the GIS Manager
* Monitors must be able to display following types of layers
** GRASS Raster
** GRASS Vector
** GDAL Raster
** GDAL Vector
** WMS Layer from remote server
** WCS and WFS layers too
** Text layers
** Graphics layers
** Grid
** Image layers
** ...
* GIS Manager is tool for
** Monitors management and monitor content management
** Layer look management
** Modules starting (from integrated command line or menu)
** Displaying output from modules (G_message, G_warning, G_fatal_error, G_percent)
* GIS Manager must be able to save and restore session
* There should be default session file, which will be loaded by default ones GRASS is started with -gui parameter
* Georectification tool should be part of new GUI. It should be special type of monitor with added GCP function
* Map Composer should be part of the new GUI. This tool should generate configuration files for hardcopy maps. The configuration files should be either ps.map files or maybe SVG

==== Coder's point of view ====
NOTE: As I have no coders background, sorry for inept formulated thoughts. --[[User:Jachym|Jachym]] 09:13, 2 February 2007 (CET)

List of suggested classes and their purpose.

* '''Layer''' -- Raster, vector, WMS, whatever layer
** '''Attributes''' -- Attributes are depending on layer type, but there are also common attributes marked with prefix "l_" (for 'layer'):
*** l_type -- vector, raster, wms, text, graph, ...
*** l_mapfile -- renderd ppm file
*** l_maskfile -- pgm file with layer's alpha channel
*** l_active -- layer is active, will be rendered only if True
*** l_hidden - layer is hidden, will be allways rendered
*** l_opacity - layer opacity [0-1]
** '''Methods'''
*** Render -- runs d.* and similar commands for making content of l_mapfile

* '''Map''' -- Set of layers renderd to single PNG image, ready to display in Map display frame
** '''Attributes'''
*** Width -- map width
*** Height -- map height
*** Region -- Region boundaries and resolution
*** Layers -- Array of ''Layer''s displayed in this "map"
*** MapFile -- path to resulting PNG file with rendered map
** '''Methods'''
*** AddRasterLayer -- Adds GRASS-raster layer to list of layers
*** AddVectorLayer -- Adds GRASS-vector layer to list of layers
*** Add...Layer -- Adds some type of layer (wms, wfs, text, ...) to list of layers
*** GetListOfLayers -- Returns array of layers (''active, hidden, type'')
*** Render -- Creates final PNG image and stores it's path to ''MapFile''

* '''DigitToolbar''' -- Pop-up toolbar with digitising functions
* '''DisplayToolBar''' -- Pop-up toolbar with substitution of other d.* modules

* '''MapDisplay''' -- Frame (in [http://wiki.wxpython.org/index.cgi/Frequently_Asked_Questions#head-829eea79fe17c04c65c00a7dc0bffa69f2473167 wxWidgets terminology]) with embed toolbar for zooming and paning and maybe data quering and pop-up toolbar for substitution of other d.* modules (d.path, d.profile, ...)
NOTE: This section should be completed
** '''Attributes'''
*** Width
*** Height
*** Mouse -- mouse actions, movements, presed buttons etc.
*** Map -- ''Map'' class
** ''Methods'' -- just very coarse definition
*** Zoom -- for zooming and paning
*** DrawBox -- For box drawing
*** DrawLine -- For line drawing
*** DrawPoint -- for points drawing

* '''GisManager''' -- GIS Manager frame
** '''Attributes'''
*** Displays -- array with map displayes
** '''Methods'''
*** AddDisplay -- Creates new map display
*** AddLayer -- Adds layer of defined type
*** EditLayer -- Opens pop-up window with layer attributes definition
*** ExecuteCommand -- Executes module from command line or menu

* '''GCPDisplay''' -- Special type of MapDisplay with tool for setting GCPs
* '''HCPDisplay''' -- Special type of MapDisplay with tools for creating configuration files for hardcopy maps

=== Used tools ===
wxPython seems to be the best tool for "new generation gui", because of it's multiplatformity and native look&feel on various platforms.

=== Where to get it ===
Jachym suggests to move the development to GRASS-Addons subversion repository, until it is "mature enough". Subversion enables for example to rename files, which could be useful. Current version can be found at https://grasssvn.itc.it/grasssvn/grassaddons/trunk/grassaddons/gui/#_trunk_grassaddons_gui_ and downloaded with command

svn co https://grasssvn.itc.it/svn/grassaddons/trunk/grassaddons grassaddons/gui

=== Proposed screenshots ===
[[Image:Gism.png]]
The wxGlade definition file is avaliable [https://grasssvn.itc.it/grasssvn/grassaddons/trunk/grassaddons/gui/gism.wxg in the subversion repository]

=== GUI History ===
'''[http://www.public.asu.edu/~cmbarton/files/grass_wxpython/ Link to wxPython prototype GUI for GRASS 6]'''

'''Update 18:02, 14 August 2006 (CEST) '''New version implements double buffered drawing to fix display issues on Debian, including flickering why panning and display being erased by overlaying windows. Output to PNG file added. Better looking zoom rectangles.

'''*****The wxPython code is moving to the GRASS CVS. You should look for the newest versions there. Volunteers to help with the new GUI are welcomed!*****''' [[User:Cmbarton|Cmbarton]]

'''Update 00:50, 9 August 2006 (CEST) '''New version will run directly from GRASS prompt with new startup script. Now put gism.py and associated files into $GISBASE/etc/gmwxp and add a new script (gm.wxp) to the $GISBASE/scripts folder. Then simply type gm.wxp& from the GRASS command prompt to get the new prototype wxPython GUI for GRASS. See instructions in today's package update. [[User:Cmbarton|Cmbarton]]

'''Update 23:59, 7 August 2006 (CEST) '''New version with nearly complete raster menu by Yann Chemin. [[User:Cmbarton|Cmbarton]]

'''Update 19:02, 7 August 2006 (CEST)'''I just uploaded a new version of gism.py and related files. I'll keep an archive and so am changing the link to go to the folder rather than the file itself so I won't have to keep changing the link. This update includes the following changes:
*The biggest change in wrapping in grassgui.py. This provides autogenerated wxPython GUI dialogs for all grass commands.
This can now be called from the command console (just type in the command name with no arguments as you do now) or the
prototype menus. I updated grassgui.py to current wxPython syntax (mostly) and added methods to make it callable from
other modules.
*Methods added to gism.py and grassgui.py that automatically restart them with pythonw for the Mac
--[[User:Cmbarton|Cmbarton]] 19:02, 7 August 2006 (CEST)

Initial development has begun on the next generation UI for GRASS. wxPython is the leading contender for a platform in which to continue development of the GRASS GUI. wxPython is a Python implementation of the well known wxWidgets (formerly wxWindows) interface development platform for C++. An initial demonstration was developed by Jachym Cepicky to show the possibility of controling GRASS via wxPython. A second generation prototype has been completed, building on Jachym's work. It is available for testing and further development at link above.
--[[User:Cmbarton|Cmbarton]] 07:15, 4 August 2006 (CEST)

== Tcl/Tk GUI ==
Screenshots: http://grass.itc.it/grass61/screenshots/index.php

===Draft GUI design specifications===

* See attached file

===Summary of 2005 discussions on next generation UI for GRASS===

* Attached file gives a distillation of several months of emails on the GRASS developers list. It includes a series of desired design features and specifications, along with supporting quotes.

===Compiled emails from 2005 discussions on next generation UI for GRASS===

* Attached file compiles all (or all that I could find) of the late 2005 emails on the GRASS developers list discussing proposed specifications for a next generation GRASS GUI. It is a series of rtm files that group the discussions according to a series of topics.

File:Gism.png

2007-02-02T09:15:24Z

⚠️Jachym: GIS Manager prepared using wxGlade. NOTE: Missing toolbar and menu bar are not intention. I was just not able to embed it in the main window.

GIS Manager prepared using wxGlade.

NOTE: Missing toolbar and menu bar are not intention. I was just not able to embed it in the main window.

GRASS GUI

2007-02-02T09:07:25Z

⚠️Jachym: /* wxPython GUI */

== wxPython GUI ==
=== General GUI Design ===
==== User's point of view ====
* GUI has multiple map displays
* Each map display has several buttons for basic functions
** Zooming and Paning
** Data Quering
* Each map display will be able to fire up pop-up toolbar with more complicated and not-so-often-used display functions (substitutions for d.measure, d.profile, d.text, ...)
* Each map display will be able to fire up pop-up toolbar with v.digit substitution
* Monitors can be started from the command line and from the GIS Manager
* Monitors must be able to display following types of layers
** GRASS Raster
** GRASS Vector
** GDAL Raster
** GDAL Vector
** WMS Layer from remote server
** WCS and WFS layers too
** Text layers
** Graphics layers
** Grid
** Image layers
** ...
* GIS Manager is tool for
** Monitors management and monitor content management
** Layer look management
** Modules starting (from integrated command line or menu)
** Displaying output from modules (G_message, G_warning, G_fatal_error, G_percent)
* GIS Manager must be able to save and restore session
* There should be default session file, which will be loaded by default ones GRASS is started with -gui parameter
* Georectification tool should be part of new GUI. It should be special type of monitor with added GCP function
* Map Composer should be part of the new GUI. This tool should generate configuration files for hardcopy maps. The configuration files should be either ps.map files or maybe SVG

==== Coder's point of view ====
NOTE: As I have no coders background, sorry for inept formulated thoughts. --[[User:Jachym|Jachym]] 09:13, 2 February 2007 (CET)

List of suggested classes and their purpose.

* '''Layer''' -- Raster, vector, WMS, whatever layer
** '''Attributes''' -- Attributes are depending on layer type, but there are also common attributes marked with prefix "l_" (for 'layer'):
*** l_type -- vector, raster, wms, text, graph, ...
*** l_mapfile -- renderd ppm file
*** l_maskfile -- pgm file with layer's alpha channel
*** l_active -- layer is active, will be rendered only if True
*** l_hidden - layer is hidden, will be allways rendered
*** l_opacity - layer opacity [0-1]
** '''Methods'''
*** Render -- runs d.* and similar commands for making content of l_mapfile

* '''Map''' -- Set of layers renderd to single PNG image, ready to display in Map display frame
** '''Attributes'''
*** Width -- map width
*** Height -- map height
*** Region -- Region boundaries and resolution
*** Layers -- Array of ''Layer''s displayed in this "map"
*** MapFile -- path to resulting PNG file with rendered map
** '''Methods'''
*** AddRasterLayer -- Adds GRASS-raster layer to list of layers
*** AddVectorLayer -- Adds GRASS-vector layer to list of layers
*** Add...Layer -- Adds some type of layer (wms, wfs, text, ...) to list of layers
*** GetListOfLayers -- Returns array of layers (''active, hidden, type'')
*** Render -- Creates final PNG image and stores it's path to ''MapFile''

* '''DigitToolbar''' -- Pop-up toolbar with digitising functions
* '''DisplayToolBar''' -- Pop-up toolbar with substitution of other d.* modules

* '''MapDisplay''' -- Frame (in [http://wiki.wxpython.org/index.cgi/Frequently_Asked_Questions#head-829eea79fe17c04c65c00a7dc0bffa69f2473167 wxWidgets terminology]) with embed toolbar for zooming and paning and maybe data quering and pop-up toolbar for substitution of other d.* modules (d.path, d.profile, ...)
NOTE: This section should be completed
** '''Attributes'''
*** Width
*** Height
*** Mouse -- mouse actions, movements, presed buttons etc.
*** Map -- ''Map'' class
** ''Methods'' -- just very coarse definition
*** Zoom -- for zooming and paning
*** DrawBox -- For box drawing
*** DrawLine -- For line drawing
*** DrawPoint -- for points drawing

* '''GisManager''' -- GIS Manager frame
** '''Attributes'''
*** Displays -- array with map displayes
** '''Methods'''
*** AddDisplay -- Creates new map display
*** AddLayer -- Adds layer of defined type
*** EditLayer -- Opens pop-up window with layer attributes definition
*** ExecuteCommand -- Executes module from command line or menu

* '''GCPDisplay''' -- Special type of MapDisplay with tool for setting GCPs
* '''HCPDisplay''' -- Special type of MapDisplay with tools for creating configuration files for hardcopy maps

=== Used tools ===
wxPython seems to be the best tool for "new generation gui", because of it's multiplatformity and native look&feel on various platforms.

=== Where to get it ===
Jachym suggests to move the development to GRASS-Addons subversion repository, until it is "mature enough". Subversion enables for example to rename files, which could be useful. Current version can be found at https://grasssvn.itc.it/grasssvn/grassaddons/trunk/grassaddons/gui/#_trunk_grassaddons_gui_ and downloaded with command

svn co https://grasssvn.itc.it/svn/grassaddons/trunk/grassaddons grassaddons/gui

=== GUI History ===
'''[http://www.public.asu.edu/~cmbarton/files/grass_wxpython/ Link to wxPython prototype GUI for GRASS 6]'''

'''Update 18:02, 14 August 2006 (CEST) '''New version implements double buffered drawing to fix display issues on Debian, including flickering why panning and display being erased by overlaying windows. Output to PNG file added. Better looking zoom rectangles.

'''*****The wxPython code is moving to the GRASS CVS. You should look for the newest versions there. Volunteers to help with the new GUI are welcomed!*****''' [[User:Cmbarton|Cmbarton]]

'''Update 00:50, 9 August 2006 (CEST) '''New version will run directly from GRASS prompt with new startup script. Now put gism.py and associated files into $GISBASE/etc/gmwxp and add a new script (gm.wxp) to the $GISBASE/scripts folder. Then simply type gm.wxp& from the GRASS command prompt to get the new prototype wxPython GUI for GRASS. See instructions in today's package update. [[User:Cmbarton|Cmbarton]]

'''Update 23:59, 7 August 2006 (CEST) '''New version with nearly complete raster menu by Yann Chemin. [[User:Cmbarton|Cmbarton]]

'''Update 19:02, 7 August 2006 (CEST)'''I just uploaded a new version of gism.py and related files. I'll keep an archive and so am changing the link to go to the folder rather than the file itself so I won't have to keep changing the link. This update includes the following changes:
*The biggest change in wrapping in grassgui.py. This provides autogenerated wxPython GUI dialogs for all grass commands.
This can now be called from the command console (just type in the command name with no arguments as you do now) or the
prototype menus. I updated grassgui.py to current wxPython syntax (mostly) and added methods to make it callable from
other modules.
*Methods added to gism.py and grassgui.py that automatically restart them with pythonw for the Mac
--[[User:Cmbarton|Cmbarton]] 19:02, 7 August 2006 (CEST)

Initial development has begun on the next generation UI for GRASS. wxPython is the leading contender for a platform in which to continue development of the GRASS GUI. wxPython is a Python implementation of the well known wxWidgets (formerly wxWindows) interface development platform for C++. An initial demonstration was developed by Jachym Cepicky to show the possibility of controling GRASS via wxPython. A second generation prototype has been completed, building on Jachym's work. It is available for testing and further development at link above.
--[[User:Cmbarton|Cmbarton]] 07:15, 4 August 2006 (CEST)

== Tcl/Tk GUI ==
Screenshots: http://grass.itc.it/grass61/screenshots/index.php

===Draft GUI design specifications===

* See attached file

===Summary of 2005 discussions on next generation UI for GRASS===

* Attached file gives a distillation of several months of emails on the GRASS developers list. It includes a series of desired design features and specifications, along with supporting quotes.

===Compiled emails from 2005 discussions on next generation UI for GRASS===

* Attached file compiles all (or all that I could find) of the late 2005 emails on the GRASS developers list discussing proposed specifications for a next generation GRASS GUI. It is a series of rtm files that group the discussions according to a series of topics.

GRASS GUI

2007-02-02T08:58:40Z

⚠️Jachym: /* Coder's point of view */

== wxPython GUI ==
=== General GUI Design ===
==== User's point of view ====
* GUI has multiple map displays
* Each map display has several buttons for basic functions
** Zooming and Paning
** Data Quering
* Each map display will be able to fire up pop-up toolbar with more complicated and not-so-often-used display functions (substitutions for d.measure, d.profile, d.text, ...)
* Each map display will be able to fire up pop-up toolbar with v.digit substitution
* Monitors can be started from the command line and from the GIS Manager
* Monitors must be able to display following types of layers
** GRASS Raster
** GRASS Vector
** GDAL Raster
** GDAL Vector
** WMS Layer from remote server
** WCS and WFS layers too
** Text layers
** Graphics layers
** Grid
** Image layers
** ...
* GIS Manager is tool for
** Monitors management and monitor content management
** Layer look management
** Modules starting (from integrated command line or menu)
** Displaying output from modules (G_message, G_warning, G_fatal_error, G_percent)
* GIS Manager must be able to save and restore session
* There should be default session file, which will be loaded by default ones GRASS is started with -gui parameter
* Georectification tool should be part of new GUI. It should be special type of monitor with added GCP function
* Map Composer should be part of the new GUI. This tool should generate configuration files for hardcopy maps. The configuration files should be either ps.map files or maybe SVG

==== Coder's point of view ====
NOTE: As I have no coders background, sorry for inept formulated thoughts. --[[User:Jachym|Jachym]] 09:13, 2 February 2007 (CET)

List of suggested classes and their purpose.

* '''Layer''' -- Raster, vector, WMS, whatever layer
** '''Attributes''' -- Attributes are depending on layer type, but there are also common attributes marked with prefix "l_" (for 'layer'):
*** l_type -- vector, raster, wms, text, graph, ...
*** l_mapfile -- renderd ppm file
*** l_maskfile -- pgm file with layer's alpha channel
*** l_active -- layer is active, will be rendered only if True
*** l_hidden - layer is hidden, will be allways rendered
*** l_opacity - layer opacity [0-1]
** '''Methods'''
*** Render -- runs d.* and similar commands for making content of l_mapfile

* '''Map''' -- Set of layers renderd to single PNG image, ready to display in Map display frame
** '''Attributes'''
*** Width -- map width
*** Height -- map height
*** Region -- Region boundaries and resolution
*** Layers -- Array of ''Layer''s displayed in this "map"
*** MapFile -- path to resulting PNG file with rendered map
** '''Methods'''
*** AddRasterLayer -- Adds GRASS-raster layer to list of layers
*** AddVectorLayer -- Adds GRASS-vector layer to list of layers
*** Add...Layer -- Adds some type of layer (wms, wfs, text, ...) to list of layers
*** GetListOfLayers -- Returns array of layers (''active, hidden, type'')
*** Render -- Creates final PNG image and stores it's path to ''MapFile''

* '''DigitToolbar''' -- Pop-up toolbar with digitising functions
* '''DisplayToolBar''' -- Pop-up toolbar with substitution of other d.* modules

* '''MapDisplay''' -- Frame (in [http://wiki.wxpython.org/index.cgi/Frequently_Asked_Questions#head-829eea79fe17c04c65c00a7dc0bffa69f2473167 wxWidgets terminology]) with embed toolbar for zooming and paning and maybe data quering and pop-up toolbar for substitution of other d.* modules (d.path, d.profile, ...)
NOTE: This section should be completed
** '''Attributes'''
*** Width
*** Height
*** Mouse -- mouse actions, movements, presed buttons etc.
*** Map -- ''Map'' class
** ''Methods'' -- just very coarse definition
*** Zoom -- for zooming and paning
*** DrawBox -- For box drawing
*** DrawLine -- For line drawing
*** DrawPoint -- for points drawing

* '''GisManager''' -- GIS Manager frame
** '''Attributes'''
*** Displays -- array with map displayes
** '''Methods'''
*** AddDisplay -- Creates new map display
*** AddLayer -- Adds layer of defined type
*** EditLayer -- Opens pop-up window with layer attributes definition
*** ExecuteCommand -- Executes module from command line or menu

* '''GCPDisplay''' -- Special type of MapDisplay with tool for setting GCPs
* '''HCPDisplay''' -- Special type of MapDisplay with tools for creating configuration files for hardcopy maps

=== GUI History ===
'''[http://www.public.asu.edu/~cmbarton/files/grass_wxpython/ Link to wxPython prototype GUI for GRASS 6]'''

'''Update 18:02, 14 August 2006 (CEST) '''New version implements double buffered drawing to fix display issues on Debian, including flickering why panning and display being erased by overlaying windows. Output to PNG file added. Better looking zoom rectangles.

'''*****The wxPython code is moving to the GRASS CVS. You should look for the newest versions there. Volunteers to help with the new GUI are welcomed!*****''' [[User:Cmbarton|Cmbarton]]

'''Update 00:50, 9 August 2006 (CEST) '''New version will run directly from GRASS prompt with new startup script. Now put gism.py and associated files into $GISBASE/etc/gmwxp and add a new script (gm.wxp) to the $GISBASE/scripts folder. Then simply type gm.wxp& from the GRASS command prompt to get the new prototype wxPython GUI for GRASS. See instructions in today's package update. [[User:Cmbarton|Cmbarton]]

'''Update 23:59, 7 August 2006 (CEST) '''New version with nearly complete raster menu by Yann Chemin. [[User:Cmbarton|Cmbarton]]

'''Update 19:02, 7 August 2006 (CEST)'''I just uploaded a new version of gism.py and related files. I'll keep an archive and so am changing the link to go to the folder rather than the file itself so I won't have to keep changing the link. This update includes the following changes:
*The biggest change in wrapping in grassgui.py. This provides autogenerated wxPython GUI dialogs for all grass commands.
This can now be called from the command console (just type in the command name with no arguments as you do now) or the
prototype menus. I updated grassgui.py to current wxPython syntax (mostly) and added methods to make it callable from
other modules.
*Methods added to gism.py and grassgui.py that automatically restart them with pythonw for the Mac
--[[User:Cmbarton|Cmbarton]] 19:02, 7 August 2006 (CEST)

Initial development has begun on the next generation UI for GRASS. wxPython is the leading contender for a platform in which to continue development of the GRASS GUI. wxPython is a Python implementation of the well known wxWidgets (formerly wxWindows) interface development platform for C++. An initial demonstration was developed by Jachym Cepicky to show the possibility of controling GRASS via wxPython. A second generation prototype has been completed, building on Jachym's work. It is available for testing and further development at link above.
--[[User:Cmbarton|Cmbarton]] 07:15, 4 August 2006 (CEST)

== Tcl/Tk GUI ==
Screenshots: http://grass.itc.it/grass61/screenshots/index.php

===Draft GUI design specifications===

* See attached file

===Summary of 2005 discussions on next generation UI for GRASS===

* Attached file gives a distillation of several months of emails on the GRASS developers list. It includes a series of desired design features and specifications, along with supporting quotes.

===Compiled emails from 2005 discussions on next generation UI for GRASS===

* Attached file compiles all (or all that I could find) of the late 2005 emails on the GRASS developers list discussing proposed specifications for a next generation GRASS GUI. It is a series of rtm files that group the discussions according to a series of topics.

GRASS GUI

2007-02-02T08:13:50Z

⚠️Jachym: /* Coder's point of view */

== wxPython GUI ==
=== General GUI Design ===
==== User's point of view ====
* GUI has multiple map displays
* Each map display has several buttons for basic functions
** Zooming and Paning
** Data Quering
* Each map display will be able to fire up pop-up toolbar with more complicated and not-so-often-used display functions (substitutions for d.measure, d.profile, d.text, ...)
* Each map display will be able to fire up pop-up toolbar with v.digit substitution
* Monitors can be started from the command line and from the GIS Manager
* Monitors must be able to display following types of layers
** GRASS Raster
** GRASS Vector
** GDAL Raster
** GDAL Vector
** WMS Layer from remote server
** WCS and WFS layers too
** Text layers
** Graphics layers
** Grid
** Image layers
** ...
* GIS Manager is tool for
** Monitors management and monitor content management
** Layer look management
** Modules starting (from integrated command line or menu)
** Displaying output from modules (G_message, G_warning, G_fatal_error, G_percent)
* GIS Manager must be able to save and restore session
* There should be default session file, which will be loaded by default ones GRASS is started with -gui parameter
* Georectification tool should be part of new GUI. It should be special type of monitor with added GCP function
* Map Composer should be part of the new GUI. This tool should generate configuration files for hardcopy maps. The configuration files should be either ps.map files or maybe SVG

==== Coder's point of view ====
NOTE: As I have no coders background, sorry for inept formulated thoughts. --[[User:Jachym|Jachym]] 09:13, 2 February 2007 (CET)

List of suggested classes and their purpose.

* '''Layer''' -- Raster, vector, WMS, whatever layer
** '''Attributes''' -- Attributes are depending on layer type, but there are also common attributes marked with prefix "l_" (for 'layer'):
*** l_type -- vector, raster, wms, text, graph, ...
*** l_mapfile -- renderd ppm file
*** l_maskfile -- pgm file with layer's alpha channel
*** l_active -- layer is active, will be rendered only if True
*** l_hidden - layer is hidden, will be allways rendered
*** l_opacity - layer opacity [0-1]
** '''Methods'''
*** Render -- runs d.* and similar commands for making content of l_mapfile

* '''Map''' -- Set of layers renderd to single PNG image, ready to display in Map display frame
** '''Attributes'''
*** Width -- map width
*** Height -- map height
*** Region -- Region boundaries and resolution
*** Layers -- Array of ''Layer''s displayed in this "map"
*** MapFile -- path to resulting PNG file with rendered map
** '''Methods'''
*** AddRasterLayer -- Adds GRASS-raster layer to list of layers
*** AddVectorLayer -- Adds GRASS-vector layer to list of layers
*** Add...Layer -- Adds some type of layer (wms, wfs, text, ...) to list of layers
*** GetListOfLayers -- Returns array of layers (''active, hidden, type'')
*** Render -- Creates final PNG image and stores it's path to ''MapFile''

=== GUI History ===
'''[http://www.public.asu.edu/~cmbarton/files/grass_wxpython/ Link to wxPython prototype GUI for GRASS 6]'''

'''Update 18:02, 14 August 2006 (CEST) '''New version implements double buffered drawing to fix display issues on Debian, including flickering why panning and display being erased by overlaying windows. Output to PNG file added. Better looking zoom rectangles.

'''*****The wxPython code is moving to the GRASS CVS. You should look for the newest versions there. Volunteers to help with the new GUI are welcomed!*****''' [[User:Cmbarton|Cmbarton]]

'''Update 00:50, 9 August 2006 (CEST) '''New version will run directly from GRASS prompt with new startup script. Now put gism.py and associated files into $GISBASE/etc/gmwxp and add a new script (gm.wxp) to the $GISBASE/scripts folder. Then simply type gm.wxp& from the GRASS command prompt to get the new prototype wxPython GUI for GRASS. See instructions in today's package update. [[User:Cmbarton|Cmbarton]]

'''Update 23:59, 7 August 2006 (CEST) '''New version with nearly complete raster menu by Yann Chemin. [[User:Cmbarton|Cmbarton]]

'''Update 19:02, 7 August 2006 (CEST)'''I just uploaded a new version of gism.py and related files. I'll keep an archive and so am changing the link to go to the folder rather than the file itself so I won't have to keep changing the link. This update includes the following changes:
*The biggest change in wrapping in grassgui.py. This provides autogenerated wxPython GUI dialogs for all grass commands.
This can now be called from the command console (just type in the command name with no arguments as you do now) or the
prototype menus. I updated grassgui.py to current wxPython syntax (mostly) and added methods to make it callable from
other modules.
*Methods added to gism.py and grassgui.py that automatically restart them with pythonw for the Mac
--[[User:Cmbarton|Cmbarton]] 19:02, 7 August 2006 (CEST)

Initial development has begun on the next generation UI for GRASS. wxPython is the leading contender for a platform in which to continue development of the GRASS GUI. wxPython is a Python implementation of the well known wxWidgets (formerly wxWindows) interface development platform for C++. An initial demonstration was developed by Jachym Cepicky to show the possibility of controling GRASS via wxPython. A second generation prototype has been completed, building on Jachym's work. It is available for testing and further development at link above.
--[[User:Cmbarton|Cmbarton]] 07:15, 4 August 2006 (CEST)

== Tcl/Tk GUI ==
Screenshots: http://grass.itc.it/grass61/screenshots/index.php

===Draft GUI design specifications===

* See attached file

===Summary of 2005 discussions on next generation UI for GRASS===

* Attached file gives a distillation of several months of emails on the GRASS developers list. It includes a series of desired design features and specifications, along with supporting quotes.

===Compiled emails from 2005 discussions on next generation UI for GRASS===

* Attached file compiles all (or all that I could find) of the late 2005 emails on the GRASS developers list discussing proposed specifications for a next generation GRASS GUI. It is a series of rtm files that group the discussions according to a series of topics.

GRASS GUI

2007-02-02T07:26:26Z

⚠️Jachym: /* wxPython GUI */

GRASS and Python

2007-02-02T06:56:56Z

⚠️Jachym: /* wxPython GUI development for GRASS */

==Python SIGs==
Python Special Interest Groups are focused collaborative efforts to develop, improve, or maintain specific Python resources. Each SIG has a charter, a coordinator, a mailing list, and a directory on the Python website. SIG membership is informal, defined by subscription to the SIG's mailing list. Anyone can join a SIG, and participate in the development discussions via the SIG's mailing list. Below is the list of currently active Python SIGs, with links to their resources.

See more at http://www.python.org/community/sigs/

==Writing python scripts in GRASS==
Python is between shell and C programms. For C part - it can handle GRASS C functions via swig. For shell part, it can be processed with g.parser, so automatic input check and help generation (apart from translation) can be processed.

Example of python script, which is processed by g.parser:
#!/usr/bin/python

import sys
import os

#%Module
#% description: g.parser test script
#% keywords: keyword1, keyword2
#%End
#%flag
#% key: f
#% description: a flag
#%END
#%option
#% key: raster
#% type: string
#% gisprompt: old,cell,raster
#% description: raster input map
#% required : yes
#%end
#%option
#% key: vector
#% type: string
#% gisprompt: old,vector,vector
#% description: vector input map
#% required : yes
#%end
#%option
#% key: option1
#% type: string
#% description: an option
#% required : yes
#%end

def main():

#add your code here
print ""

if ( os.getenv("GIS_FLAG_f") != "0" ):
print "Flag -f set"
else:
print "Flag -f not set"

print "Value of GIS_OPT_option1: %s" % os.getenv("GIS_OPT_option1")
print "Value of GIS_OPT_raster: %s" % os.getenv("GIS_OPT_raster")
print "Value of GIS_OPT_vect: %s" % os.getenv("GIS_OPT_vect")

#end of your code
return

if __name__ == "__main__":
args = ""
for arg in sys.argv:
args += arg+" "
try:
if ( sys.argv[1] != "@ARGS_PARSED@" ):
os.system("g.parser %s " % (args))
except IndexError:
os.system("g.parser %s" % (args))

if sys.argv[1] == "@ARGS_PARSED@":
main();
==Python extensions for GRASS GIS==
=== wxPython GUI development for GRASS ===
See section [[GRASS_and_Python#wxPython_GUI_development_for_GRASS]]

===Python-SWIG-GRASS interface===
There is a prototype GRASS-SWIG interface available (thanks to Sajith VK), find it in GRASS 6-CVS: '''swig/python/'''. Draft documentation is [http://mpa.itc.it/markus/grass63progman/swig/ here]. It now wraps both raster and vector data C functions plus the general GIS (G_*()) functions.

Background: [http://www.swig.org SWIG] (Simplified Wrapper and Interface Generator) is:

* A compiler that turns ANSI C/C++ declarations into scripting language interfaces.
* Completely automated (produces a fully working Python extension module).
* Language neutral. SWIG can also target Tcl, Perl, Guile, MATLAB, etc...
* Attempts to eliminate the tedium of writing extension modules.

Sample script for raster access (use within GRASS, Spearfish session):
#!/usr/bin/python
import python_grass6 as g6lib

input = 'roads'
mapset = 'PERMANENT'

# initialize
g6lib.G_gisinit('')
infd = g6lib.G_open_cell_old(input, mapset)
cell = g6lib.G_allocate_cell_buf()

rown=0
# the API still needs error checking to be added
while 1:
myrow = g6lib.G_get_map_row_nomask(infd, cell, rown)
print rown,myrow[0:10]
rown = rown+1
if rown==476:break

g6lib.G_close_cell(infd)
g6lib.G_free(cell)

Sample script for vector access (use within GRASS, Spearfish session):
#!/usr/bin/python
import python_grass6 as g6lib

input = 'soils'
mapset = 'PERMANENT'

# initialize
g6lib.G_gisinit('')

# define map structure
map = g6lib.Map_info()

# define open level (level 2: topology)
g6lib.Vect_set_open_level (2)

# open existing map
g6lib.Vect_open_old(map, input, mapset)

# query
print 'Vect is 3D: ', g6lib.Vect_is_3d (map)
print 'Vect DB links: ', g6lib.Vect_get_num_dblinks(map)
print 'Map Scale: 1:', g6lib.Vect_get_scale(map)

# close map
g6lib.Vect_close(map)

'''TODO''': Implement modules support in a Python class using --interface-description and a Python-XML parser. This should be a generic class with module's name as parameter, returning back an object which describes the module (description, flags, parameters, status of not/required). See [http://freegis.org/cgi-bin/viewcvs.cgi/grass6/gui/wxpython/ GRASS 6 wxPython interface] for inspiration. Important is to auto-generate the GRASS-Python class at compile time with a Python script.

=== Python-GRASS add-ons ===

Stand-alone addons:

# Jáchym Čepický's G-ps.map, a GUI to typeset printable maps with ps.map (http://193.84.38.2/~jachym/index.py?cat=gpsmap)
# Jáchym Čepický's v.pydigit, a GUI to v.edit (http://les-ejk.cz/?cat=vpydigit)
# Jáchym Čepický's PyWPS, GRASS-Web Processing Service (http://pywps.wald.intevation.org)

=== Using Grass gui.tcl in python ===

Here is some example code to use the grass automatically generated guis in python code. This could (should) all be bundled up and abstracted away so that the implementation can be replaced later.

import Tkinter
import os

# Startup (once):

tk = Tkinter.Tk()
tk.eval ("wm withdraw .")
tk.eval ("source $env(GISBASE)/etc/gui.tcl")
# Here you could do various things to change what the gui does
# See gui.tcl and README.GUI

# Make a gui (per dialog)
# This sets up a window for the command.
# This can be different to integrate with tkinter:
tk.eval ('set path ".dialog$dlg"')
tk.eval ('toplevel .dialog$dlg')
# Load the code for this command:
fd = os.popen ("d.vect --tcltk")
gui = fd.read()
# Run it
tk.eval(gui)
dlg = tk.eval('set dlg') # This is used later to get and set

# Get the current command in the gui we just made:
currentcommand = tk.eval ("dialog_get_command " + dlg)

# Set the command in the dialog we just made:
tk.eval ("dialog_set_command " + dlg + " {d.vect map=roads}")

== Links ==

=== Programming ===
* GRASS-SWIG interface http://mpa.itc.it/markus/grass63progman/swig/
* SWIG http://www.swig.org/
* SIP (C/C++ bindings generator) http://directory.fsf.org/all/Python-SIP.html
* Python and GDAL/OGR:
** [http://mapserver.gis.umn.edu/community/conferences/MUM3/workshop/python Open Source Python GIS Hacks Mum'03]
** http://hobu.biz/software/OSGIS_Hacks - Python OSGIS Hacks '05
** http://zcologia.com/news/categorylist_html?cat_id=8
** http://www.perrygeo.net/wordpress/?p=4
* Python bindings to PROJ:
** http://www.cdc.noaa.gov/people/jeffrey.s.whitaker/python/pyproj.html
* Other external projects
** Scientific Python: http://www.scipy.org/

=== Presentations ===

From FOSS4G2006:
* [http://www.foss4g2006.org/materialDisplay.py?contribId=136&sessionId=48&materialId=slides&confId=1 A Python sweeps in the GRASS] - A. Frigeri 2006
* [http://www.foss4g2006.org/materialDisplay.py?contribId=67&sessionId=48&materialId=slides&confId=1 GRASS goes web: PyWPS] - J. Cepicky 2006

[[Category:Development]]
[[Category:Linking to other languages]]

GRASS GUI

2007-02-02T06:55:31Z

⚠️Jachym: /* wxPython GUI */

== wxPython GUI ==

'''[http://www.public.asu.edu/~cmbarton/files/grass_wxpython/ Link to wxPython prototype GUI for GRASS 6]'''

'''Update 18:02, 14 August 2006 (CEST) '''New version implements double buffered drawing to fix display issues on Debian, including flickering why panning and display being erased by overlaying windows. Output to PNG file added. Better looking zoom rectangles.

'''*****The wxPython code is moving to the GRASS CVS. You should look for the newest versions there. Volunteers to help with the new GUI are welcomed!*****''' [[User:Cmbarton|Cmbarton]]

'''Update 00:50, 9 August 2006 (CEST) '''New version will run directly from GRASS prompt with new startup script. Now put gism.py and associated files into $GISBASE/etc/gmwxp and add a new script (gm.wxp) to the $GISBASE/scripts folder. Then simply type gm.wxp& from the GRASS command prompt to get the new prototype wxPython GUI for GRASS. See instructions in today's package update. [[User:Cmbarton|Cmbarton]]

'''Update 23:59, 7 August 2006 (CEST) '''New version with nearly complete raster menu by Yann Chemin. [[User:Cmbarton|Cmbarton]]

'''Update 19:02, 7 August 2006 (CEST)'''I just uploaded a new version of gism.py and related files. I'll keep an archive and so am changing the link to go to the folder rather than the file itself so I won't have to keep changing the link. This update includes the following changes:
*The biggest change in wrapping in grassgui.py. This provides autogenerated wxPython GUI dialogs for all grass commands.
This can now be called from the command console (just type in the command name with no arguments as you do now) or the
prototype menus. I updated grassgui.py to current wxPython syntax (mostly) and added methods to make it callable from
other modules.
*Methods added to gism.py and grassgui.py that automatically restart them with pythonw for the Mac
--[[User:Cmbarton|Cmbarton]] 19:02, 7 August 2006 (CEST)

Initial development has begun on the next generation UI for GRASS. wxPython is the leading contender for a platform in which to continue development of the GRASS GUI. wxPython is a Python implementation of the well known wxWidgets (formerly wxWindows) interface development platform for C++. An initial demonstration was developed by Jachym Cepicky to show the possibility of controling GRASS via wxPython. A second generation prototype has been completed, building on Jachym's work. It is available for testing and further development at link above.
--[[User:Cmbarton|Cmbarton]] 07:15, 4 August 2006 (CEST)

== Tcl/Tk GUI ==
Screenshots: http://grass.itc.it/grass61/screenshots/index.php

===Draft GUI design specifications===

* See attached file

===Summary of 2005 discussions on next generation UI for GRASS===

* Attached file gives a distillation of several months of emails on the GRASS developers list. It includes a series of desired design features and specifications, along with supporting quotes.

===Compiled emails from 2005 discussions on next generation UI for GRASS===

* Attached file compiles all (or all that I could find) of the late 2005 emails on the GRASS developers list discussing proposed specifications for a next generation GRASS GUI. It is a series of rtm files that group the discussions according to a series of topics.

GRASS and Python

2007-02-02T06:55:04Z

⚠️Jachym: /* wxPython GUI development for GRASS */

==Python SIGs==
Python Special Interest Groups are focused collaborative efforts to develop, improve, or maintain specific Python resources. Each SIG has a charter, a coordinator, a mailing list, and a directory on the Python website. SIG membership is informal, defined by subscription to the SIG's mailing list. Anyone can join a SIG, and participate in the development discussions via the SIG's mailing list. Below is the list of currently active Python SIGs, with links to their resources.

See more at http://www.python.org/community/sigs/

==Writing python scripts in GRASS==
Python is between shell and C programms. For C part - it can handle GRASS C functions via swig. For shell part, it can be processed with g.parser, so automatic input check and help generation (apart from translation) can be processed.

Example of python script, which is processed by g.parser:
#!/usr/bin/python

import sys
import os

#%Module
#% description: g.parser test script
#% keywords: keyword1, keyword2
#%End
#%flag
#% key: f
#% description: a flag
#%END
#%option
#% key: raster
#% type: string
#% gisprompt: old,cell,raster
#% description: raster input map
#% required : yes
#%end
#%option
#% key: vector
#% type: string
#% gisprompt: old,vector,vector
#% description: vector input map
#% required : yes
#%end
#%option
#% key: option1
#% type: string
#% description: an option
#% required : yes
#%end

def main():

#add your code here
print ""

if ( os.getenv("GIS_FLAG_f") != "0" ):
print "Flag -f set"
else:
print "Flag -f not set"

print "Value of GIS_OPT_option1: %s" % os.getenv("GIS_OPT_option1")
print "Value of GIS_OPT_raster: %s" % os.getenv("GIS_OPT_raster")
print "Value of GIS_OPT_vect: %s" % os.getenv("GIS_OPT_vect")

#end of your code
return

if __name__ == "__main__":
args = ""
for arg in sys.argv:
args += arg+" "
try:
if ( sys.argv[1] != "@ARGS_PARSED@" ):
os.system("g.parser %s " % (args))
except IndexError:
os.system("g.parser %s" % (args))

if sys.argv[1] == "@ARGS_PARSED@":
main();
==Python extensions for GRASS GIS==
=== wxPython GUI development for GRASS ===
See section

===Python-SWIG-GRASS interface===
There is a prototype GRASS-SWIG interface available (thanks to Sajith VK), find it in GRASS 6-CVS: '''swig/python/'''. Draft documentation is [http://mpa.itc.it/markus/grass63progman/swig/ here]. It now wraps both raster and vector data C functions plus the general GIS (G_*()) functions.

Background: [http://www.swig.org SWIG] (Simplified Wrapper and Interface Generator) is:

* A compiler that turns ANSI C/C++ declarations into scripting language interfaces.
* Completely automated (produces a fully working Python extension module).
* Language neutral. SWIG can also target Tcl, Perl, Guile, MATLAB, etc...
* Attempts to eliminate the tedium of writing extension modules.

Sample script for raster access (use within GRASS, Spearfish session):
#!/usr/bin/python
import python_grass6 as g6lib

input = 'roads'
mapset = 'PERMANENT'

# initialize
g6lib.G_gisinit('')
infd = g6lib.G_open_cell_old(input, mapset)
cell = g6lib.G_allocate_cell_buf()

rown=0
# the API still needs error checking to be added
while 1:
myrow = g6lib.G_get_map_row_nomask(infd, cell, rown)
print rown,myrow[0:10]
rown = rown+1
if rown==476:break

g6lib.G_close_cell(infd)
g6lib.G_free(cell)

Sample script for vector access (use within GRASS, Spearfish session):
#!/usr/bin/python
import python_grass6 as g6lib

input = 'soils'
mapset = 'PERMANENT'

# initialize
g6lib.G_gisinit('')

# define map structure
map = g6lib.Map_info()

# define open level (level 2: topology)
g6lib.Vect_set_open_level (2)

# open existing map
g6lib.Vect_open_old(map, input, mapset)

# query
print 'Vect is 3D: ', g6lib.Vect_is_3d (map)
print 'Vect DB links: ', g6lib.Vect_get_num_dblinks(map)
print 'Map Scale: 1:', g6lib.Vect_get_scale(map)

# close map
g6lib.Vect_close(map)

'''TODO''': Implement modules support in a Python class using --interface-description and a Python-XML parser. This should be a generic class with module's name as parameter, returning back an object which describes the module (description, flags, parameters, status of not/required). See [http://freegis.org/cgi-bin/viewcvs.cgi/grass6/gui/wxpython/ GRASS 6 wxPython interface] for inspiration. Important is to auto-generate the GRASS-Python class at compile time with a Python script.

=== Python-GRASS add-ons ===

Stand-alone addons:

# Jáchym Čepický's G-ps.map, a GUI to typeset printable maps with ps.map (http://193.84.38.2/~jachym/index.py?cat=gpsmap)
# Jáchym Čepický's v.pydigit, a GUI to v.edit (http://les-ejk.cz/?cat=vpydigit)
# Jáchym Čepický's PyWPS, GRASS-Web Processing Service (http://pywps.wald.intevation.org)

=== Using Grass gui.tcl in python ===

Here is some example code to use the grass automatically generated guis in python code. This could (should) all be bundled up and abstracted away so that the implementation can be replaced later.

import Tkinter
import os

# Startup (once):

tk = Tkinter.Tk()
tk.eval ("wm withdraw .")
tk.eval ("source $env(GISBASE)/etc/gui.tcl")
# Here you could do various things to change what the gui does
# See gui.tcl and README.GUI

# Make a gui (per dialog)
# This sets up a window for the command.
# This can be different to integrate with tkinter:
tk.eval ('set path ".dialog$dlg"')
tk.eval ('toplevel .dialog$dlg')
# Load the code for this command:
fd = os.popen ("d.vect --tcltk")
gui = fd.read()
# Run it
tk.eval(gui)
dlg = tk.eval('set dlg') # This is used later to get and set

# Get the current command in the gui we just made:
currentcommand = tk.eval ("dialog_get_command " + dlg)

# Set the command in the dialog we just made:
tk.eval ("dialog_set_command " + dlg + " {d.vect map=roads}")

== Links ==

=== Programming ===
* GRASS-SWIG interface http://mpa.itc.it/markus/grass63progman/swig/
* SWIG http://www.swig.org/
* SIP (C/C++ bindings generator) http://directory.fsf.org/all/Python-SIP.html
* Python and GDAL/OGR:
** [http://mapserver.gis.umn.edu/community/conferences/MUM3/workshop/python Open Source Python GIS Hacks Mum'03]
** http://hobu.biz/software/OSGIS_Hacks - Python OSGIS Hacks '05
** http://zcologia.com/news/categorylist_html?cat_id=8
** http://www.perrygeo.net/wordpress/?p=4
* Python bindings to PROJ:
** http://www.cdc.noaa.gov/people/jeffrey.s.whitaker/python/pyproj.html
* Other external projects
** Scientific Python: http://www.scipy.org/

=== Presentations ===

From FOSS4G2006:
* [http://www.foss4g2006.org/materialDisplay.py?contribId=136&sessionId=48&materialId=slides&confId=1 A Python sweeps in the GRASS] - A. Frigeri 2006
* [http://www.foss4g2006.org/materialDisplay.py?contribId=67&sessionId=48&materialId=slides&confId=1 GRASS goes web: PyWPS] - J. Cepicky 2006

[[Category:Development]]
[[Category:Linking to other languages]]

GRASS 7 ideas collection

2007-01-19T13:29:26Z

⚠️Jachym: /* Modules */

== Raster ==

=== Library ===

* Split libgis into G_() part and Rast_() part
* Rewrite library from scratch. See [http://grass.itc.it/pipermail/grass-dev/2006-August/025025.html suggestions]

=== Modules ===

* Remove r.in.arc and r.out.arc, '''if''' a [http://intevation.de/rt/webrt?serial_num=4897 related bug in r.in.gdal] is fixed. The [http://bugzilla.remotesensing.org/show_bug.cgi?id=1071 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 [http://intevation.de/rt/webrt?serial_num=3054 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

* drop '''r.univar.sh'''; newly implemented '''r.univar''' features cover it

* r.sum, r.mode, r.median, r.average, r.statistics, r.univar, r.univar2 - maybe they can be reduced to just r.statistics and r.univar? See [http://intevation.de/rt/webrt?serial_num=1848 RT #1848] and a [http://grass.itc.it/pipermail/grass-dev/2006-November/027665.html thread on the GRASS dev list]

* Dispose r.out.tiff. New C r.out.gdal should cover all it's option now (doublecheck!). See [http://intevation.de/rt/webrt?serial_num=3680 RT #3680] (starting with date Sun, Nov 26 2006 14:54:23).

* Remove remainging -v and -q flags for verbosity levels of modules.

== Vector ==
=== Library ===
=== Modules ===

* rename v.mkgrid to v.grid
* merge v.select and v.overlay
* Remove [http://intevation.de/rt/webrt?serial_num=3600 doubled units in v.to.db GUI]

* Fix the [http://intevation.de/rt/webrt?serial_num=3623 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 ([http://www.ngdc.noaa.gov/mgg/shorelines/data/gshhs/version1.2/gshhs_dp.c C code file])to substitute prune tool of v.clean (why wait for GRASS 7 ??)

== General ==
=== Library ===
* Add support for planetary bodies reference systems
* Add new partial differential equation (PDE) library with OpenMP support

=== Modules ===

* g.remove, g.mremove, g.rename, g.copy: don't allow for default datatype (which is currently raster) [http://intevation.de/rt/webrt?serial_num=3009].

== Database ==
=== Library ===
=== Modules ===

== 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
* Depreciate tape functions in next major revision of GRASS and create a tape module that accomplishes tape access.

== 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 [http://intevation.de/rt/webrt?serial_num=2969 '''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 [http://www.gnu.org/software/units/ units] software
* store vertical map datum on per-location base (GDAL/OGR needs the same [http://lists.maptools.org/pipermail/gdal-dev/2005-October/006857.html 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 [http://freegis.org/cgi-bin/viewcvs.cgi/grass/documents/parameter_proposal.txt?rev=HEAD&content-type=text/vnd.viewcvs-markup 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)
* Facilitating easy development of custom GUI application based on GRASS

* [[GRASS and Python|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 -- <cite> frankie at #grass irc</cite>
** 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 -- <cite> frankie at #grass irc</cite>

[[Category:Development]]
[[Category:Release Roadmap]]

GRASS Digitizing tool

2006-12-23T16:06:15Z

⚠️Jachym: /* v.edit */

=v.digit=
GRASS digitizing tool should be
* written in '''wxPython''' Programming language or Tcl
* it should extend functionality of map display just like new Georeferencing tool does:
** (like ArcGIS does) only new "Digitizing Toolbox" would appear, after digitizing tool is started
** Vector file editing will happen in current map display, with all it's functions for zooming, quering and so on
* There should be graphical tool for database management, at least for adding (?and removing?) columns, adding new features and editing existing ones.

While digitising, edited vector file would be drawed to map display. ''Only currently edited or selected features would be stored in memory.'' This should spead up digitising and redrawing process significantly.

=v.edit=
GRASS graphical digitising tool should be graphical front-end for new v.edit module. v.edit should be CML tool for
* creating new vector file, eventualy overwrite existing ones '''create'''
* adding new features (points, lines, polylines, centroids) '''add'''
* removenig old features (with database record) '''delete'''
* moving whole feature '''move'''
* moving specified vertex '''vertex'''
* adding new vertext to line/boundary '''break'''
* spliting line/boundary completely '''split'''
* removing vertex '''straight'''
* selecting features '''select'''
* merging two lines/boundaries together '''merge'''
* IMHO funtionality for adding 'z' values to vector contour lines should be back too

v.edit should accept feature selection by:
* bbox '''bbox'''
* catlist '''cats'''
* single coordinates '''coords'''

==Examples of actions==
* Create new vector file
v.edit tool=create map=vectfile
creates new vector map, eventualy will read data from standard inputs in default format (standard/point)
v.edit tool=create map=vectfile input=file.txt
creates new vector map and reads data from file file.txt in default format

* Add new feature to existing vector
v.edit tool=add map=vectfile
Read data from standard inputs in standard format

* Remove feature from vector file
v.edit tool=delete map=vectfile cat=34,24
Remove features with category 34 and 24 from file vectfile
v.edit tool=delete map=vectfile coords=344556.23,23445.2345
Remove feature located on coordinates 344556.23,23445.2345
v.edit tool=delete map=vectifle bbox=344556.23,234455.2345,567566.34,456455.34
Remove features defined by bounding box 344556.23,234455.2345,567566.34,456455.34

* Move feature
v.edit tool=move map=vectifle coords=344556.23,23445.2345 move=100000,-100000
Move feature located on coordinates 344556.23,23445.2345 to coordinates 644556.23,43445.2345
v.edit tool=move map=vectifle cat=45 move=1000,-1000
Move all points of feature of category 45 to coordinates about 1000 map units to the west and 1000 map units to the south
v.edit tool=move map=vectifle bbox=344556.23,234455.2345,567566.34,456455.34 to=1000,-1000
Move all points of features defined by bounding box 344556.23,234455.2345,567566.34,456455.34 about 1000 map units to the west and 1000 map units to the south

* Moving vertext
v.edit tool=vertex map=vectifile coords=344556.23,23445.2345 move=1000,-1000
Move vertex on coordinates 344556.23,23445.2345 to 545556.23,22445.2345

* Breaking line
v.edit tool=break map=vectifile coords=344556.23,23445.2345
Break line on coordinates 344556.23,23445.2345 at coords 345433.3,34567.32
v.edit tool=break map=vectifile cat=45 coords=345433.3,34567.32
Break line of category 45 at coords 345433.3,34567.32

* Remove vertex -- straight line
v.edit tool=straight map=vectifile coords=344556.23,23445.2345
Remove vertex at coordinates 344556.23,23445.2345

* Spliting line
v.edit tool=split map=vectifile coords=344556.23,23445.2345
Split line on coordinates 344556.23,23445.2345 at coords 345433.3,34567.32
v.edit tool=split map=vectifile cat=45 coords=345433.3,34567.32
Split line of category 45 at coords 345433.3,34567.32

* Mergin two lines
v.edit tool=merge map=vectfile coords=606853.875,4921332,603216.75,4922763
Merge first line defined by coordinates 606853.875,4921332 with second line, defined by coordinates 603216.75,4922763. Define nearest distance between line first and last points and move first (last) point of second line to first line -- First line will remain untached.
v.edit tool=merge map=vectfile bbox=344556.23,23445.2345
Merge two lines defined by bounding box
v.edit tool=merge map=vectfile cat=43,45
Merge two lines defined by category

* Selecting features
Print line id's selected by coords, bbox or cat. Example:
v.edit map=soils@PERMANENT tool=select bbox=595733.8125,4919781.75,598536.1875,4917396.75
Example with d.vect:
d.vect col=red width=2 -i cat="`v.edit map=soils@PERMANENT tool=select bbox=595733.8125,4919781.75,598536.1875,4917396.75`" map=soils

==Summary==
v.edit --help

Description:
Edits a vector map; allows adding, deleting and modifying objects in a vector map.

Keywords:
vector, editing

Usage:
v.edit [-tdbcn] map=name tool=string [input=string] [cats=range]
[coords=x,y[,x,y,...]] [move=x,y] [bbox=x1,y1,x2,y2] [snap=value]
[layer=value] [--verbose] [--quiet]

Flags:
-t Do not use topology.
-d No database updates.
-b Give cats to boundaries too.
-c Do not close boundaries
-n Don't expect a header
--v Verbose module output
--q Quiet module output

Parameters:
map Name of input vector map
tool The edit tool to take.
create - Create new vector file
add - Add new vector feature to existing vector file
delete - Delete feature from vector file
move - Move feature in vector file
vertex - Move just only vertex
straight - Remove vertex
merge - Merge two vector lines togher
break - Add new vertex to existing vector line
split - Split line into two separate lines
select - Select lines and print their ID's
options: create,add,delete,move,vertex,straight,merge,break,split,select
input ASCII file to be converted to binary vector file, if not given reads from standard input
cats Category values
Example: 1,3,7-9,13
coords An x,y list of points. Required for add and move actions.
move Difference in x,y direction for moving feature or vertex
bbox Bounding box of selected feature
snap Object points will snap to existing points within snap units.
default: 5.0
layer Layer number
A single vector map can be connected to multiple database tables. This number determines which table to use.
default: 1

= r.digit =

The r.in.poly ascii format is almost the same as the standard vector ascii format. So the new digitizer should be able to output for both, and then we have a replacement for r.digit too!

GRASS Digitizing tool

2006-12-22T21:42:44Z

⚠️Jachym: /* Examples of actions */

=v.digit=
GRASS digitizing tool should be
* written in '''wxPython''' Programming language or Tcl
* it should extend functionality of map display just like new Georeferencing tool does:
** (like ArcGIS does) only new "Digitizing Toolbox" would appear, after digitizing tool is started
** Vector file editing will happen in current map display, with all it's functions for zooming, quering and so on
* There should be graphical tool for database management, at least for adding (?and removing?) columns, adding new features and editing existing ones.

While digitising, edited vector file would be drawed to map display. ''Only currently edited or selected features would be stored in memory.'' This should spead up digitising and redrawing process significantly.

=v.edit=
GRASS graphical digitising tool should be graphical front-end for new v.edit module. v.edit should be CML tool for
* creating new vector file, eventualy overwrite existing ones '''create'''
* adding new features (points, lines, polylines, centroids) '''add'''
* removenig old features (with database record) '''delete'''
* moving whole feature '''move'''
* moving specified vertex '''vertex'''
* adding new vertext to line/boundary '''break'''
* spliting line/boundary completely '''split'''
* merging two lines/boundaries together '''merge'''
* IMHO funtionality for adding 'z' values to vector contour lines should be back too

v.edit should accept feature selection by:
* bbox '''bbox'''
* catlist '''cats'''
* single coordinates '''coords'''

==Examples of actions==
* Create new vector file
v.edit tool=create map=vectfile
creates new vector map, eventualy will read data from standard inputs in default format (standard/point)
v.edit tool=create map=vectfile input=file.txt
creates new vector map and reads data from file file.txt in default format

* Add new feature to existing vector
v.edit tool=add map=vectfile
Read data from standard inputs in standard format

* Remove feature from vector file
v.edit tool=delete map=vectfile cat=34,24
Remove features with category 34 and 24 from file vectfile
v.edit tool=delete map=vectfile coords=344556.23,23445.2345
Remove feature located on coordinates 344556.23,23445.2345
v.edit tool=delete map=vectifle bbox=344556.23,234455.2345,567566.34,456455.34
Remove features defined by bounding box 344556.23,234455.2345,567566.34,456455.34

* Move feature
v.edit tool=move map=vectifle coords=344556.23,23445.2345 move=100000,-100000
Move feature located on coordinates 344556.23,23445.2345 to coordinates 644556.23,43445.2345
v.edit tool=move map=vectifle cat=45 move=1000,-1000
Move all points of feature of category 45 to coordinates about 1000 map units to the west and 1000 map units to the south
v.edit tool=move map=vectifle bbox=344556.23,234455.2345,567566.34,456455.34 to=1000,-1000
Move all points of features defined by bounding box 344556.23,234455.2345,567566.34,456455.34 about 1000 map units to the west and 1000 map units to the south

* Moving vertext
v.edit tool=vertex map=vectifile coords=344556.23,23445.2345 move=1000,-1000
Move vertex on coordinates 344556.23,23445.2345 to 545556.23,22445.2345

* Breaking line
v.edit tool=break map=vectifile coords=344556.23,23445.2345
Break line on coordinates 344556.23,23445.2345 at coords 345433.3,34567.32
v.edit tool=break map=vectifile cat=45 coords=345433.3,34567.32
Break line of category 45 at coords 345433.3,34567.32

* Remove vertex -- straight line
v.edit tool=straight map=vectifile coords=344556.23,23445.2345
Remove vertex at coordinates 344556.23,23445.2345

* Spliting line
v.edit tool=split map=vectifile coords=344556.23,23445.2345
Split line on coordinates 344556.23,23445.2345 at coords 345433.3,34567.32
v.edit tool=split map=vectifile cat=45 coords=345433.3,34567.32
Split line of category 45 at coords 345433.3,34567.32

* Mergin two lines
v.edit tool=merge map=vectfile coords=606853.875,4921332,603216.75,4922763
Merge first line defined by coordinates 606853.875,4921332 with second line, defined by coordinates 603216.75,4922763. Define nearest distance between line first and last points and move first (last) point of second line to first line -- First line will remain untached.
v.edit tool=merge map=vectfile bbox=344556.23,23445.2345
Merge two lines defined by bounding box
v.edit tool=merge map=vectfile cat=43,45
Merge two lines defined by category

==Summary==
v.edit --help

Description:
Edits a vector map; allows adding, deleting and modifying objects in a vector map.

Keywords:
vector, editing

Usage:
v.edit [-tdbcn] map=name tool=string [input=string] [cats=range]
[coords=x,y[,x,y,...]] [move=x,y] [bbox=x1,y1,x2,y2] [snap=value]
[layer=value] [--verbose] [--quiet]

Flags:
-t Do not use topology.
-d No database updates.
-b Give cats to boundaries too.
-c Do not close boundaries
-n Don't expect a header
--v Verbose module output
--q Quiet module output

Parameters:
map Name of input vector map
tool The edit tool to take.
create - Create new vector file
add - Add new vector feature to existing vector file
delete - Delete feature from vector file
move - Move feature in vector file
vertex - Move just only vertex
straight - Remove vertex
merge - Merge two vector lines togher
break - Add new vertex to existing vector line
split - Split line into two separate lines
options: create,add,delete,move,vertex,straight,merge,break,split
input ASCII file to be converted to binary vector file, if not given reads from standard input
cats Category values
Example: 1,3,7-9,13
coords An x,y list of points. Required for add and move actions.
move Difference in x,y direction for moving feature or vertex
bbox Bounding box of selected feature
snap Object points will snap to existing points within snap units.
default: 5.0
layer Layer number
A single vector map can be connected to multiple database tables. This number determines which table to use.
default: 1

= r.digit =

The r.in.poly ascii format is almost the same as the standard vector ascii format. So the new digitizer should be able to output for both, and then we have a replacement for r.digit too!

GRASS Digitizing tool

2006-12-22T21:38:11Z

⚠️Jachym: /* Summary */

=v.digit=
GRASS digitizing tool should be
* written in '''wxPython''' Programming language or Tcl
* it should extend functionality of map display just like new Georeferencing tool does:
** (like ArcGIS does) only new "Digitizing Toolbox" would appear, after digitizing tool is started
** Vector file editing will happen in current map display, with all it's functions for zooming, quering and so on
* There should be graphical tool for database management, at least for adding (?and removing?) columns, adding new features and editing existing ones.

While digitising, edited vector file would be drawed to map display. ''Only currently edited or selected features would be stored in memory.'' This should spead up digitising and redrawing process significantly.

=v.edit=
GRASS graphical digitising tool should be graphical front-end for new v.edit module. v.edit should be CML tool for
* creating new vector file, eventualy overwrite existing ones '''create'''
* adding new features (points, lines, polylines, centroids) '''add'''
* removenig old features (with database record) '''delete'''
* moving whole feature '''move'''
* moving specified vertex '''vertex'''
* adding new vertext to line/boundary '''break'''
* spliting line/boundary completely '''split'''
* merging two lines/boundaries together '''merge'''
* IMHO funtionality for adding 'z' values to vector contour lines should be back too

v.edit should accept feature selection by:
* bbox '''bbox'''
* catlist '''cats'''
* single coordinates '''coords'''

==Examples of actions==
* Create new vector file
v.edit tool=create map=vectfile
creates new vector map, eventualy will read data from standard inputs in default format (standard/point)
v.edit tool=create map=vectfile input=file.txt
creates new vector map and reads data from file file.txt in default format

* Add new feature to existing vector
v.edit tool=add map=vectfile
Read data from standard inputs in standard format

* Remove feature from vector file
v.edit tool=delete map=vectfile cat=34,24
Remove features with category 34 and 24 from file vectfile
v.edit tool=delete map=vectfile coords=344556.23,23445.2345
Remove feature located on coordinates 344556.23,23445.2345
v.edit tool=delete map=vectifle bbox=344556.23,234455.2345,567566.34,456455.34
Remove features defined by bounding box 344556.23,234455.2345,567566.34,456455.34

* Move feature
v.edit tool=move map=vectifle coords=344556.23,23445.2345 move=100000,-100000
Move feature located on coordinates 344556.23,23445.2345 to coordinates 644556.23,43445.2345
v.edit tool=move map=vectifle cat=45 move=1000,-1000
Move all points of feature of category 45 to coordinates about 1000 map units to the west and 1000 map units to the south
v.edit tool=move map=vectifle bbox=344556.23,234455.2345,567566.34,456455.34 to=1000,-1000
Move all points of features defined by bounding box 344556.23,234455.2345,567566.34,456455.34 about 1000 map units to the west and 1000 map units to the south

* Moving vertext
v.edit tool=vertex map=vectifile coords=344556.23,23445.2345 move=1000,-1000
Move vertex on coordinates 344556.23,23445.2345 to 545556.23,22445.2345

* Breaking line
v.edit tool=break map=vectifile coords=344556.23,23445.2345
Break line on coordinates 344556.23,23445.2345 at coords 345433.3,34567.32
v.edit tool=break map=vectifile cat=45 coords=345433.3,34567.32
Break line of category 45 at coords 345433.3,34567.32

* Spliting line
v.edit tool=split map=vectifile coords=344556.23,23445.2345
Split line on coordinates 344556.23,23445.2345 at coords 345433.3,34567.32
v.edit tool=split map=vectifile cat=45 coords=345433.3,34567.32
Split line of category 45 at coords 345433.3,34567.32

* Mergin two lines
v.edit tool=merge map=vectfile coords=606853.875,4921332,603216.75,4922763
Merge first line defined by coordinates 606853.875,4921332 with second line, defined by coordinates 603216.75,4922763. Define nearest distance between line first and last points and move first (last) point of second line to first line -- First line will remain untached.
v.edit tool=merge map=vectfile bbox=344556.23,23445.2345
Merge two lines defined by bounding box
v.edit tool=merge map=vectfile cat=43,45
Merge two lines defined by category

==Summary==
v.edit --help

Description:
Edits a vector map; allows adding, deleting and modifying objects in a vector map.

Keywords:
vector, editing

Usage:
v.edit [-tdbcn] map=name tool=string [input=string] [cats=range]
[coords=x,y[,x,y,...]] [move=x,y] [bbox=x1,y1,x2,y2] [snap=value]
[layer=value] [--verbose] [--quiet]

Flags:
-t Do not use topology.
-d No database updates.
-b Give cats to boundaries too.
-c Do not close boundaries
-n Don't expect a header
--v Verbose module output
--q Quiet module output

Parameters:
map Name of input vector map
tool The edit tool to take.
create - Create new vector file
add - Add new vector feature to existing vector file
delete - Delete feature from vector file
move - Move feature in vector file
vertex - Move just only vertex
straight - Remove vertex
merge - Merge two vector lines togher
break - Add new vertex to existing vector line
split - Split line into two separate lines
options: create,add,delete,move,vertex,straight,merge,break,split
input ASCII file to be converted to binary vector file, if not given reads from standard input
cats Category values
Example: 1,3,7-9,13
coords An x,y list of points. Required for add and move actions.
move Difference in x,y direction for moving feature or vertex
bbox Bounding box of selected feature
snap Object points will snap to existing points within snap units.
default: 5.0
layer Layer number
A single vector map can be connected to multiple database tables. This number determines which table to use.
default: 1

= r.digit =

The r.in.poly ascii format is almost the same as the standard vector ascii format. So the new digitizer should be able to output for both, and then we have a replacement for r.digit too!

GRASS Digitizing tool

2006-12-22T21:35:28Z

⚠️Jachym: /* Examples of actions */

=v.digit=
GRASS digitizing tool should be
* written in '''wxPython''' Programming language or Tcl
* it should extend functionality of map display just like new Georeferencing tool does:
** (like ArcGIS does) only new "Digitizing Toolbox" would appear, after digitizing tool is started
** Vector file editing will happen in current map display, with all it's functions for zooming, quering and so on
* There should be graphical tool for database management, at least for adding (?and removing?) columns, adding new features and editing existing ones.

While digitising, edited vector file would be drawed to map display. ''Only currently edited or selected features would be stored in memory.'' This should spead up digitising and redrawing process significantly.

=v.edit=
GRASS graphical digitising tool should be graphical front-end for new v.edit module. v.edit should be CML tool for
* creating new vector file, eventualy overwrite existing ones '''create'''
* adding new features (points, lines, polylines, centroids) '''add'''
* removenig old features (with database record) '''delete'''
* moving whole feature '''move'''
* moving specified vertex '''vertex'''
* adding new vertext to line/boundary '''break'''
* spliting line/boundary completely '''split'''
* merging two lines/boundaries together '''merge'''
* IMHO funtionality for adding 'z' values to vector contour lines should be back too

v.edit should accept feature selection by:
* bbox '''bbox'''
* catlist '''cats'''
* single coordinates '''coords'''

==Examples of actions==
* Create new vector file
v.edit tool=create map=vectfile
creates new vector map, eventualy will read data from standard inputs in default format (standard/point)
v.edit tool=create map=vectfile input=file.txt
creates new vector map and reads data from file file.txt in default format

* Add new feature to existing vector
v.edit tool=add map=vectfile
Read data from standard inputs in standard format

* Remove feature from vector file
v.edit tool=delete map=vectfile cat=34,24
Remove features with category 34 and 24 from file vectfile
v.edit tool=delete map=vectfile coords=344556.23,23445.2345
Remove feature located on coordinates 344556.23,23445.2345
v.edit tool=delete map=vectifle bbox=344556.23,234455.2345,567566.34,456455.34
Remove features defined by bounding box 344556.23,234455.2345,567566.34,456455.34

* Move feature
v.edit tool=move map=vectifle coords=344556.23,23445.2345 move=100000,-100000
Move feature located on coordinates 344556.23,23445.2345 to coordinates 644556.23,43445.2345
v.edit tool=move map=vectifle cat=45 move=1000,-1000
Move all points of feature of category 45 to coordinates about 1000 map units to the west and 1000 map units to the south
v.edit tool=move map=vectifle bbox=344556.23,234455.2345,567566.34,456455.34 to=1000,-1000
Move all points of features defined by bounding box 344556.23,234455.2345,567566.34,456455.34 about 1000 map units to the west and 1000 map units to the south

* Moving vertext
v.edit tool=vertex map=vectifile coords=344556.23,23445.2345 move=1000,-1000
Move vertex on coordinates 344556.23,23445.2345 to 545556.23,22445.2345

* Breaking line
v.edit tool=break map=vectifile coords=344556.23,23445.2345
Break line on coordinates 344556.23,23445.2345 at coords 345433.3,34567.32
v.edit tool=break map=vectifile cat=45 coords=345433.3,34567.32
Break line of category 45 at coords 345433.3,34567.32

* Spliting line
v.edit tool=split map=vectifile coords=344556.23,23445.2345
Split line on coordinates 344556.23,23445.2345 at coords 345433.3,34567.32
v.edit tool=split map=vectifile cat=45 coords=345433.3,34567.32
Split line of category 45 at coords 345433.3,34567.32

* Mergin two lines
v.edit tool=merge map=vectfile coords=606853.875,4921332,603216.75,4922763
Merge first line defined by coordinates 606853.875,4921332 with second line, defined by coordinates 603216.75,4922763. Define nearest distance between line first and last points and move first (last) point of second line to first line -- First line will remain untached.
v.edit tool=merge map=vectfile bbox=344556.23,23445.2345
Merge two lines defined by bounding box
v.edit tool=merge map=vectfile cat=43,45
Merge two lines defined by category

==Summary==
v.edit --help

Description:
Edits a vector map; allows adding, deleting and modifying objects in a vector map.

Keywords:
vector, editing

Usage:
v.edit [-tdc] map=name tool=string [input=file] [cats=range]
[coords=x,y[,x,y,...]] [move=x,y] [at=x,y] [bbox=x,y,x,y]
[--verbose] [--quiet]

Flags:
-t Do not build topology.
-d No database updates.
-c Do not close boundaries
--v Verbose module output
--q Quiet module output

Parameters:
map Name of input vector map
tool The edit action to take.
options: create,add,delete,move,movevertex,break,split
create: creates new vector file
add: add new features to existing vector file
delete: delete feature from existing vector file
move: move whole feature
vertex: move just one vertex of the feature
merge: merge two vector lines together
break: add new vertex to feature
split: split feature
input ASCII file to be converted to binary vector file, if not given reads from standard input
cats Category values
Example: 1,3,7-9,13
coords An x,y list of points
move New location of the feature
at Coordinates of breaking or spliting feature
bbox Bounding box in form x1,y1,x2,y2

= r.digit =

The r.in.poly ascii format is almost the same as the standard vector ascii format. So the new digitizer should be able to output for both, and then we have a replacement for r.digit too!

GRASS Digitizing tool

2006-12-15T16:40:24Z

⚠️Jachym: /* Summary */

=v.digit=
GRASS digitizing tool should be
* written in '''wxPython''' Programming language or Tcl
* it should extend functionality of map display just like new Georeferencing tool does:
** (like ArcGIS does) only new "Digitizing Toolbox" would appear, after digitizing tool is started
** Vector file editing will happen in current map display, with all it's functions for zooming, quering and so on
* There should be graphical tool for database management, at least for adding (?and removing?) columns, adding new features and editing existing ones.

While digitising, edited vector file would be drawed to map display. ''Only currently edited or selected features would be stored in memory.'' This should spead up digitising and redrawing process significantly.

=v.edit=
GRASS graphical digitising tool should be graphical front-end for new v.edit module. v.edit should be CML tool for
* creating new vector file, eventualy overwrite existing ones '''create'''
* adding new features (points, lines, polylines, centroids) '''add'''
* removenig old features (with database record) '''delete'''
* moving whole feature '''move'''
* moving specified vertex '''vertex'''
* adding new vertext to line/boundary '''break'''
* spliting line/boundary completely '''split'''
* merging two lines/boundaries together '''merge'''
* IMHO funtionality for adding 'z' values to vector contour lines should be back too

v.edit should accept feature selection by:
* bbox '''bbox'''
* catlist '''cats'''
* single coordinates '''coords'''

==Examples of actions==
* Create new vector file
v.edit tool=create map=vectfile
creates new vector map, eventualy will read data from standard inputs in default format (standard/point)
v.edit tool=create map=vectfile input=file.txt
creates new vector map and reads data from file file.txt in default format

* Add new feature to existing vector
v.edit tool=add map=vectfile format=standard
Read data from standard inputs in standard format
v.edit tool=add map=vectfile input=file.txt format=point
Reads data from file file.txt in point format

* Remove feature from vector file
v.edit tool=delete map=vectfile cat=34,24
Remove features with category 34 and 24 from file vectfile
v.edit tool=delete map=vectfile coords=344556.23,23445.2345
Remove feature located on coordinates 344556.23,23445.2345
v.edit tool=delete map=vectifle bbox=344556.23,234455.2345,567566.34,456455.34
Remove features defined by bounding box 344556.23,234455.2345,567566.34,456455.34

* Move feature
v.edit tool=move map=vectifle coords=344556.23,23445.2345 move=100000,-100000
Move feature located on coordinates 344556.23,23445.2345 to coordinates 644556.23,43445.2345
v.edit tool=move map=vectifle cat=45 move=1000,-1000
Move all points of feature of category 45 to coordinates about 1000 map units to the west and 1000 map units to the south
v.edit tool=move map=vectifle bbox=344556.23,234455.2345,567566.34,456455.34 to=1000,-1000
Move all points of features defined by bounding box 344556.23,234455.2345,567566.34,456455.34 about 1000 map units to the west and 1000 map units to the south

* Moving vertext
v.edit tool=vertex map=vectifile coords=344556.23,23445.2345 move=1000,-1000
Move vertex on coordinates 344556.23,23445.2345 to 545556.23,22445.2345

* Breaking line
v.edit tool=break map=vectifile coords=344556.23,23445.2345 at=345433.3,34567.32
Break line on coordinates 344556.23,23445.2345 at coords 345433.3,34567.32
v.edit tool=break map=vectifile cat=45 at=345433.3,34567.32
Break line of category 45 at coords 345433.3,34567.32

* Spliting line
v.edit tool=split map=vectifile coords=344556.23,23445.2345 at=345433.3,34567.32
Split line on coordinates 344556.23,23445.2345 at coords 345433.3,34567.32
v.edit tool=split map=vectifile cat=45 at=345433.3,34567.32
Split line of category 45 at coords 345433.3,34567.32

==Summary==
v.edit --help

Description:
Edits a vector map; allows adding, deleting and modifying objects in a vector map.

Keywords:
vector, editing

Usage:
v.edit [-tdc] map=name tool=string [input=file] [cats=range]
[coords=x,y[,x,y,...]] [move=x,y] [at=x,y] [bbox=x,y,x,y]
[--verbose] [--quiet]

Flags:
-t Do not build topology.
-d No database updates.
-c Do not close boundaries
--v Verbose module output
--q Quiet module output

Parameters:
map Name of input vector map
tool The edit action to take.
options: create,add,delete,move,movevertex,break,split
create: creates new vector file
add: add new features to existing vector file
delete: delete feature from existing vector file
move: move whole feature
vertex: move just one vertex of the feature
merge: merge two vector lines together
break: add new vertex to feature
split: split feature
input ASCII file to be converted to binary vector file, if not given reads from standard input
cats Category values
Example: 1,3,7-9,13
coords An x,y list of points
move New location of the feature
at Coordinates of breaking or spliting feature
bbox Bounding box in form x1,y1,x2,y2

= r.digit =

The r.in.poly ascii format is almost the same as the standard vector ascii format. So the new digitizer should be able to output for both, and then we have a replacement for r.digit too!

GRASS Digitizing tool

2006-12-15T16:24:26Z

⚠️Jachym: /* v.edit */

=v.digit=
GRASS digitizing tool should be
* written in '''wxPython''' Programming language or Tcl
* it should extend functionality of map display just like new Georeferencing tool does:
** (like ArcGIS does) only new "Digitizing Toolbox" would appear, after digitizing tool is started
** Vector file editing will happen in current map display, with all it's functions for zooming, quering and so on
* There should be graphical tool for database management, at least for adding (?and removing?) columns, adding new features and editing existing ones.

While digitising, edited vector file would be drawed to map display. ''Only currently edited or selected features would be stored in memory.'' This should spead up digitising and redrawing process significantly.

=v.edit=
GRASS graphical digitising tool should be graphical front-end for new v.edit module. v.edit should be CML tool for
* creating new vector file, eventualy overwrite existing ones '''create'''
* adding new features (points, lines, polylines, centroids) '''add'''
* removenig old features (with database record) '''delete'''
* moving whole feature '''move'''
* moving specified vertex '''vertex'''
* adding new vertext to line/boundary '''break'''
* spliting line/boundary completely '''split'''
* merging two lines/boundaries together '''merge'''
* IMHO funtionality for adding 'z' values to vector contour lines should be back too

v.edit should accept feature selection by:
* bbox '''bbox'''
* catlist '''cats'''
* single coordinates '''coords'''

==Examples of actions==
* Create new vector file
v.edit tool=create map=vectfile
creates new vector map, eventualy will read data from standard inputs in default format (standard/point)
v.edit tool=create map=vectfile input=file.txt
creates new vector map and reads data from file file.txt in default format

* Add new feature to existing vector
v.edit tool=add map=vectfile format=standard
Read data from standard inputs in standard format
v.edit tool=add map=vectfile input=file.txt format=point
Reads data from file file.txt in point format

* Remove feature from vector file
v.edit tool=delete map=vectfile cat=34,24
Remove features with category 34 and 24 from file vectfile
v.edit tool=delete map=vectfile coords=344556.23,23445.2345
Remove feature located on coordinates 344556.23,23445.2345
v.edit tool=delete map=vectifle bbox=344556.23,234455.2345,567566.34,456455.34
Remove features defined by bounding box 344556.23,234455.2345,567566.34,456455.34

* Move feature
v.edit tool=move map=vectifle coords=344556.23,23445.2345 move=100000,-100000
Move feature located on coordinates 344556.23,23445.2345 to coordinates 644556.23,43445.2345
v.edit tool=move map=vectifle cat=45 move=1000,-1000
Move all points of feature of category 45 to coordinates about 1000 map units to the west and 1000 map units to the south
v.edit tool=move map=vectifle bbox=344556.23,234455.2345,567566.34,456455.34 to=1000,-1000
Move all points of features defined by bounding box 344556.23,234455.2345,567566.34,456455.34 about 1000 map units to the west and 1000 map units to the south

* Moving vertext
v.edit tool=vertex map=vectifile coords=344556.23,23445.2345 move=1000,-1000
Move vertex on coordinates 344556.23,23445.2345 to 545556.23,22445.2345

* Breaking line
v.edit tool=break map=vectifile coords=344556.23,23445.2345 at=345433.3,34567.32
Break line on coordinates 344556.23,23445.2345 at coords 345433.3,34567.32
v.edit tool=break map=vectifile cat=45 at=345433.3,34567.32
Break line of category 45 at coords 345433.3,34567.32

* Spliting line
v.edit tool=split map=vectifile coords=344556.23,23445.2345 at=345433.3,34567.32
Split line on coordinates 344556.23,23445.2345 at coords 345433.3,34567.32
v.edit tool=split map=vectifile cat=45 at=345433.3,34567.32
Split line of category 45 at coords 345433.3,34567.32

==Summary==
v.edit --help

Description:
Edits a vector map; allows adding, deleting and modifying objects in a vector map.

Keywords:
vector, editing

Usage:
v.edit [-tdc] map=name tool=string [input=file] [cats=range]
[coords=x,y[,x,y,...]] [to=x,y] [at=x,y] [bbox=x,y,x,y]
[--verbose] [--quiet]

Flags:
-t Do not build topology.
-d No database updates.
-c Do not close boundaries
--v Verbose module output
--q Quiet module output

Parameters:
map Name of input vector map
tool The edit action to take.
options: create,add,delete,move,movevertex,break,split
create: creates new vector file
add: add new features to existing vector file
delete: delete feature from existing vector file
move: move whole feature
vertex: move just one vertex of the feature
break: add new vertex to feature
split: split feature
input ASCII file to be converted to binary vector file, if not given reads from standard input
cats Category values
Example: 1,3,7-9,13
coords An x,y list of points
to New location of the feature
at Coordinates of breaking or spliting feature
bbox Bounding box in form x1,y1,x2,y2

= r.digit =

The r.in.poly ascii format is almost the same as the standard vector ascii format. So the new digitizer should be able to output for both, and then we have a replacement for r.digit too!

AddOns

2006-12-13T14:30:03Z

⚠️Jachym: /* Vector add-ons */

This page contains references to user contributions and add-ons (the original GRASS GIS software can be downloaded [http://grass.itc.it/download/index.php here]).

__TOC__

==Copyright and licensing information==

''Please be sure to include copyright and licensing information in the header comments of your code so that others may know how they can use, extend, modify, and redistribute your work.''

e.g. at the top of a shell script:
<pre>
#!/bin/sh
############################################################################
#
# MODULE: v.in.e00
#
# AUTHOR(S): Markus Neteler, Otto Dassau
#
# PURPOSE: Import E00 data into a GRASS vector map
# Imports single and split E00 files (.e00, .e01, .e02 ...)
#
# COPYRIGHT: (c) 2004, 2005 GDF Hannover bR, http://www.gdf-hannover.de
#
# This program is free software under the GNU General Public
# License (>=v2). Read the file COPYING that comes with GRASS
# for details.
#
#############################################################################
#
# REQUIREMENTS:
# - avcimport: http://avce00.maptools.org

[script follows]
</pre>

==Shell script coding standards==

Please have a look at our [http://grass.itc.it/grass63/source/SUBMITTING_SCRIPTS Shell script coding standards] before submitting here.

==Miscellaneous Add-ons==

* [http://bambi.otago.ac.nz/hamish/grass/utm_which_zone.sh utm_which_zone.sh] is a shell script to determine UTM zone from Lat/Lon input. Requires [http://www.octave.org Octave] to be installed. A shell-only version is [http://dcalvelo.free.fr/grass/utm_which_zone_sh.sh available] which only requires awk. '''Authors''': Hamish Bowman (Octave part), Markus Neteler (shell script wrapper), Daniel Calvelo (sh+awk version)

* Perl scripts for converting data forth and back between Excel files and PostgreSQL: [http://dcalvelo.free.fr/grass/pg2xls.pl pg2xls.pl] reads data from PostgreSQL and produces an excel workbook; [http://dcalvelo.free.fr/grass/xls2sql.pl xls2sql.pl] reads excel files and outputs SQL statements to be fed into an RDBMS. Both scripts need modules from [http://www.cpan.org CPAN], especially [http://search.cpan.org/dist/Spreadsheet-ParseExcel/ Spreadsheet::ParseExcel] for xls2sql.pl and [http://search.cpan.org/~tmtm/Spreadsheet-WriteExcel-FromDB Spreadsheet::WriteExcel::FromDB] and its dependencies for pg2sql.pl. Check the source headers for more info. '''Authors:''' Daniel Calvelo (xls2sql.pl), Markus Neteler (pg2xls.pl)

* [http://dream.lrrl.arch.tu-muenchen.de/~wqual/perl/dbf2sql.tgz dbf2sql] is a Perl script for translating dbf-tables into a sql-command. dbf-tables are read using dbfdump-command from dbd-xbase-perl module ([http://search.cpan.org/~janpaz/DBD-XBase-0.241/ dbd::xbase] and [http://search.cpan.org/~jv/Getopt-Long-2.35/lib/Getopt/Long.pm getopt::long] have to be installed from CPAN first). There are problems, if the last column of the table contains characters. Suggestions for improvements welcome! '''Author:'''Wolfgang Qual

* [http://www.igc.usp.br/pessoais/guano/downloads/azimuth2.c azimuth2.c] is a small C program to calculate the azimuth and length of vector lines exported by GRASS-GIS as ASCII files (like this: v.out.ascii input=vector output=ascii format=standard). It is useful for create rose diagrams of lineament maps. Improvements on the original code after suggestions by Örs Téglásy, Hungary. '''Author:''' Carlos Henrique Grohmann

==GRASS 5.x==

===Vector add-ons for GRASS 5===

* See here: http://grass.itc.it/download/addons.php

===Raster add-ons for GRASS 5===

* See here: http://grass.itc.it/download/addons.php

* [http://www.valledemexico.ambitiouslemon.com/gwmodelling.html r.gmtg] The groundwater modelling tool for grass. A module to use MODFLOW within GRASS. '''Author''': Jaime Carrera

==GRASS 6.x==

===Vector add-ons===

* [http://geni.ath.cx/grass/v.out.gmt v.out.gmt] is a shell script that exports a polygon vector file into GMT xy file. psbasemap code was copied from Hamish's r.out.gmt. '''Author:''' Huidae Cho, Hamish Bowman, Dylan Beaudette

* [http://www.pois.org/florian/downloads/grass/v.strahler.tgz v.strahler] is a module that calculates the Strahler Order for all lines of a given dendritic network. '''Author:''' Florian Kindl

* [http://svg.cc/grass/index.html v.out.svg] is a module that exports SVG notation along with optional attribute data directly from GRASS 6.x vector layers. Now part of grass63-cvs. '''Author:''' Klaus Förster

* [http://les-ejk.cz/programs/ v.trees3d] is a module for making 3D trees from input vector point file. '''Author:''' Jachym Cepicky

* [http://www.public.asu.edu/~cmbarton/files/grass_scripts/v.lda v.lda] is a shell script for calculating Ian Johnson's (U. Sidney) Local Density Analysis values to measure clustering of point data at different neighborhood radii. There is an option to create a simple line graph of the results. There have been reports of problems creating the line graph on Cygwin installations of GRASS. '''Author:''' Michael Barton

* [http://www.public.asu.edu/~cmbarton/files/grass_scripts/v.append v.append] is a shell script combining two vector files AND their associated attribute tables. The vector files should be of the same type and, for best results, should have identically formatted attribute tables. '''Author:''' Michael Barton

* [http://www.shockfamily.net/cedric/grass/v.group v.group] generates a new vector map with the same geometry as an existing map. The new map has categories and a table based on grouping by the values in certain columns of the existing map's table. The values in these columns are preserved in the table for the new map. It's like a v.reclass that preserves data. '''Author:''' Cedric Shock

* [http://bambi.otago.ac.nz/hamish/grass/v.out.ascii.db v.out.ascii.db] is a shell script for exporting vector point data coordinates and selected attribute columns to either a file or to the console. '''Author:''' Hamish Bowman

* [http://les-ejk.cz/programs v.rasterbounds] is a shell script for creating polygon-vector file of rasterfile boundaries. The best version of GRASS is 6.1+. If you are using GRASS < 6.1, you have to be in the same mapset as your raster maps are from. '''Author:''' Jachym Cepicky

* [http://www.clubwebcanada.ca/twiens/v.sample.buffer.tgz v.sample.buffer] is a shell script that samples rasters in buffers of a specified size around features in a specified vector file. Sampling results are added as attributes to the vector file. This script was designed for sampling vegetation indices and DEM derived attributes for bird point counts. Sampling results can be one or more basic statistics such as mean, range, max, etc. '''Author:''' Trevor Wiens

* [http://www.gfosservices.it/materiale_didattico/moduli/grass_kriging.tar.gz v.variogram] is a script that create an omnidirectional experimental semi-variogram. This scripts require R-statistics software installed on your machine. Now the script is updated to run on spgrass6 >= 0.3 and sp >= 0.9 [http://grass.itc.it/pipermail/statsgrass/2006-October/000455.html reply]. '''Author:''' Ivan Marchesini, Pierluigi De Rosa.

* [http://www.gfosservices.it/materiale_didattico/moduli/grass_kriging.tar.gz v.surf.krige] is a script that do a surface interpolation from vector point data by Kriging method. The interpolated value of a cell is determined by using an omnidirectional variogram model fitted starting from model parameter given by user shown from the experimental semi variogram produced by v.variogram. The script can perform also the Leave-One-out cross validation to test the variogram model "fitted by eye" and an automatic fitted variogram model. The cross validation helps the user to choose the best variogram model to interpolate own data. '''Author:''' Pierluigi De Rosa.

* [http://ngeo.de/grassstuff/v.lmeasure v.lmeasure] and [http://ngeo.de/grassstuff/v.revlmeasure v.revlmeasure] are two perl scripts that place equidistant vector points along a given arbitrary vector line starting from the beginning or end of the vector line, respectively. Resulting vector points are labeled with the distance from origin. '''Author:''' Mats Schuh

* [http://david.p.finlayson.googlepages.com/v.swathwidth v.swathwidth] creates a vector map representing the sea bottom coverage of a multibeam (swath) sonar survey. '''Author:''' David Finlayson

* [http://kufaya.googlepages.com/v.flip.tar.gz v.flip] flips the direction of selected vector lines. '''Author:''' Maciej Sieczka

* [http://phygeo7.geo.uni-augsburg.de/gis2/scripts/v.digatt v.digatt] (shell script) Interactively assign numeric table attributes to series of vector objects. It is meant to be effective by avoiding to type in the attribute value for all single objects again and again. The user is prompted for typing in an attribute value which is assigned to all objects selected by mouseclick afterwards. Next the display is redrawn after updating the table column. Zooming allows to change the region before the old value can be reused or a new one can be typed in (or copied by mouse from another object) in order to assign it to the next series of objects etc. It is tested not very extensively yet. Therefore better work with a copy of your map and consider using v.digit or d.what.vect -e alternatively. [http://phygeo7.geo.uni-augsburg.de/gis2/scripts/v.digatt.png screenshot]. '''Author:''' Andreas Philipp

* [http://k153-85.fsv.cvut.cz/cgi-bin/viewcvs.cgi/grass6/vector/v.in.gama/ v.in.gama] converts [http://www.gnu.org/software/gama/ GNU GaMa] XML output file to a GRASS vector map layer. '''Author:''' Martin Landa

===Raster add-ons===

* [http://www.igc.usp.br/pessoais/guano/downloads/r.roughness r.roughness] is a shell script to calculate the surface roughness of a DEM, using r.surf.area and v.surf.rst. (for GRASS versions 6.1 and above)
* [http://www.igc.usp.br/pessoais/guano/downloads/r.roughness60 r.roughness60] - for GRASS versions 6.0.X '''Author:''' Carlos Henrique Grohmann

* [http://les-ejk.cz/programs/grass/r.gauss.tgz r.gauss] is Gaussian and Laplacian of Gaussian filter for GRASS. It is written in C language. '''Author:''' Jachym Cepicky

* [http://les-ejk.cz/programs/grass/r.mlv.tgz r.mlv] is Mean of least variance filter for GRASS. It is an edge-preserving (or even edge-enhacing) filter, which should serve for removing additive noise from images. It is written in C language. '''Author:''' Jachym Cepicky

* [http://les-ejk.cz/programs/grass/r.bilateral.tgz r.bilateral] Bilateral filter is an edge-preserving filter, which combines domain and range filtering. It is written in C language. '''Author:''' Jachym Cepicky

* [http://les-ejk.cz/programs/zc.pl Zero crossing] is a simple Perl script, finds the ,,zero crossings`` from the Laplacian of Gaussian filter (see above). It is really very simple, the edges don't need to be really on that pixel, where they are detected, no interpolation is performed. '''Author:''' Jachym Cepicky

'''Usage:'''
zc.pl -i input -o output |r.mapcalc

* [http://les-ejk.cz/programs/local_max.pl Local maxima] is a Perl script for <code>r.mapcalc</code>. It detects local maxima of the image. '''Author:''' Jachym Cepicky

'''Usage:'''
local_maxima.pl -i input -o output -s matrix_size|r.mapcalc

* [http://bambi.otago.ac.nz/hamish/grass/r.out.gmt r.out.gmt] is a GRASS script for exporting a GRASS raster map into a [[http://www.soest.hawaii.edu/gmt/ GMT]] grid file. It also creates a GMT color table from the data and can generate some GMT commands for plotting a postscript file. (code is experimental, but functional) see also http://169.237.35.250/~dylan/grass_user_group/#GMT_and_GRASS-overview '''Authors:''' Hamish Bowman, Dylan Beaudette

* [http://geni.ath.cx/grass/r.out.gmt yet another r.out.gmt] is a modified version of Hamish's r.out.gmt. Added options for title, xlabel, ylabel, comment, and map width. Removed any settings that can be changed by gmtset for more flexibility. '''Author:''' Hamish Bowman, Huidae Cho, Dylan Beaudette

* [http://bambi.otago.ac.nz/hamish/grass/r.pack r.pack] and [http://bambi.otago.ac.nz/hamish/grass/r.unpack r.unpack] are two GRASS scripts for transfering raster maps to another computer as a single file. '''Author:''' Hamish Bowman

* [http://bambi.otago.ac.nz/hamish/grass/dominant_dir.m dominant_dir.m] and [http://bambi.otago.ac.nz/hamish/grass/calc_terraflow_dir.m calc_terraflow_dir.m] are two Matlab scripts for determining the dominant flow direction from a r.terraflow MFD map and converting into a GRASS aspect map for use with d.rast.arrow, etc. '''Author:''' Hamish Bowman

* [http://www-pool.math.tu-berlin.de/~soeren/grass/modules/ r.in.onearth] for download and import satellite images direct from the NASA onearth WMS server into GRASS. '''Author:''' Soeren Gebbert

* [http://www.shockfamily.net/cedric/grass/r.tileset r.tileset] generates a list of tiles and sizes in a source projection that cover the region in the current database with appropriate resolution. The size of individual tiles can be constrained. Only tiles intersecting the current region are returned. These tilings are appropriate for requesting data from another projection to meet the specifications of the current region. For example, it could be used to generate tile requests to a latitude / longitude WMS server like this <code>r.tileset -w sourceproj="+init=epsg:4326"</code>. '''Author:''' Cedric Shock

* [ftp://gsca.nrcan.gc.ca/outgoing/Patton/Grass/Scripts/r.csr.tar.bz2 r.csr] integrates several Grass programs to produce colored, shaded-relief rasters in one step. Accepts single or multiple elevation/bathymetry maps as input; optionally will fill data holidays with 3x3 median filter, multiple times, if required; can apply color maps from a) input raster, b) another raster in MAPSET, or c) from a rules file; otherwise, rainbow colorbar is applied. Output colored, shaded-relief rasters can optionally be exported to tiff format and archived using tar with gzip/bzip2 compression if appropriate flags are given. Shading parameters can be modified, though useful defaults are given. '''Author:''' Eric Patton

* [ftp://gsca.nrcan.gc.ca/outgoing/Patton/Grass/Scripts/r.fragment.tar.bz2 r.fragment] fragments a raster into a user-defined set of smaller tiles according to an input number of rows and columns. Optionally, a null value threshold can be set to filter out candidate tiles that would have a large percentage of null cells. '''Author:''' Eric Patton

* [http://david.p.finlayson.googlepages.com/r.eucdist r.eucdist] creates a raster map estimating the euclidean distance from known cells. '''Author:''' David Finlayson

* [http://david.p.finlayson.googlepages.com/r.smoothpatch r.smoothpatch] creates a composite of two rasters using a distance-weighted average across the transition to smooth the edges. '''Author:''' David Finlayson

* [http://www.faunalia.it/download/r_li/ r.li] is a more flexible and faster replacement of the old r.le. '''''Moved into 6.3-CVS'''''. '''Authors:''' Claudio Porta, Davide Spano, Serena Pallecchi, [http://www.faunalia.it Faunalia]

* [http://kufaya.googlepages.com/r.surf.nnbathy.tar.gz r.surf.nnbathy] interpolates surface from raster input using [http://www.marine.csiro.au/~sakov/ nn] natural neighbor intepolation library. '''Author:''' Maciej Sieczka

* [http://www.star.ait.ac.th/~yann/sebal/r.usler.tar.gz r.usler] creates USLE R factor (Rainfall erosivity) from annual precipitations. It has 4 methods, Morgan, Roose, Foster and El-Swaify to choose from. '''Authors:''' Natalia Medvedeva and Yann Chemin

* [http://www.star.ait.ac.th/~yann/sebal/r.uslek.tar.gz r.uslek] creates USLE K factor (soil erodibility) from sand,clay,silt fractions and organic matter fraction. Based on USDA 1951 (p209) quoted in FAO World Soil CD, and from some generic [soil class+OM] to K conversion table.Update: Fixed input file swap and silty-clay class recognition. '''Author:''' Yann Chemin

* [http://www.star.ait.ac.th/~yann/sebal/r.albedo.tar.gz r.albedo] creates Albedo. Albedo is the shortwave surface reflectance in the range of 0.3-3 micro-meters. This module takes Modis, Aster, Landsat or AVHRR individual surface reflectance bands to calculate Albedo. This module is a precursor to r.sun or any Energy-Balance related processing. '''Author:''' Yann Chemin

* [http://www.star.ait.ac.th/~yann/sebal/ r.eb.*] are a set of 13 GRASS modules that together perform the main functions of the SEBAL model (Bastiaanssen, 1995). Those functions include (but are not limited to) Soil heat flux, sensible heat flux, net radiation, evaporative fraction at satellite overpass, diurnal actual evapotranspiration, momentum roughness length, etc. These modules are also part of any Energy-Balance related processing. '''Author:''' Yann Chemin

* [http://www.star.ait.ac.th/~yann/sebal/r.evapo.potrad.tar.gz r.evapo.potrad] create diurnal Potential evapotranspiration assuming all net radiation becomes ET, according to SEBAL model (Bastiaanssen, 1995). This module also has a flag for diurnal net radiation as required by SEBAL in [http://www.star.ait.ac.th/~yann/sebal/r.eb.eta.tar.gz r.eb.eta]. '''Author:''' Yann Chemin

* [http://www.star.ait.ac.th/~yann/sebal/r.vi.tar.gz r.vi] creates a given Vegetation index from a list of 13 of them, most of them only requiring Red and NIR. Updated to accept all types of input data. '''Authors:''' Baburao Kamble and Yann Chemin

* [http://www.star.ait.ac.th/~yann/sebal/r.vi.mpi.tar.gz r.vi.mpi] creates a given Vegetation index from a list of 13 of them, most of them only requiring Red and NIR. This is a MPI version for educational purposes (no speed up here!). '''Author:''' Shamim Akhter

* [http://www.star.ait.ac.th/~yann/sebal/r.dn2ref.l7.tar.gz r.dn2ref.l7] [http://www.star.ait.ac.th/~yann/sebal/r.dn2ref.ast.tar.gz r.dn2ref.ast] create top of atmosphere reflectance for Landsat 7ETM+ and ASTER. These modules also have a flag for radiance output. Updated r.dn2ref.l7 to read .met calibration file. [http://www.star.ait.ac.th/~yann/sebal/r.dn2full.l7.tar.gz r.dn2full.l7] is an attempt to get all bands of Landsat7 calibrated and corrected to either reflectance or temperature, reads only the met file.
[http://www.star.ait.ac.th/~yann/sebal/r.dn2potrad.l7.tar.gz r.dn2potrad.l7] is an attempt to get ET potential from DN of Landsat 7 (Careful! No Atmospheric correction!). '''Author:''' Yann Chemin

* [http://www.star.ait.ac.th/~yann/sebal/r.biomass.tar.gz r.biomass] create biomass growth map from fPAR, lightuse efficiency, water availability (or evap.fraction), Lat, doy and tsw . '''Author:''' Yann Chemin

* [http://www.pois.org/florian/downloads/grass/r.boxcount.tgz r.boxcount] and [http://www.pois.org/florian/downloads/grass/r.boxcount.sh.tgz r.boxcount.sh] calculate the fractal dimension for a given map. These are versions for grass6 of [http://www.ucl.ac.uk/~tcrnmar/ Mark Lake's modules] for grass43. '''Authors:''' Mark Lake, grass6 port: Florian Kindl

===General add-ons===

* [http://www.gdf-hannover.de/dassau/g.laptop/g.laptop.sh g.laptop.sh] is an interactive shell script to extract raster and vector data from current Location into a new one. Data can be copied or extracted in current or original resolution and region extend. This script was written to extract smaller parts of a GRASS location to be able to present them on a laptop without the necessity to transfer huge data. Maps do not have to be in the same mapset. '''Author:''' Otto Dassau

* '''''Readline completion''''' for GRASS commands under the bash shell: [http://www.sorokine.info/grass-complete/ grass-complete] won't clutter the environment but needs to be installed; [http://dcalvelo.free.fr/grass/grass_rlcompleter.sh grass_rlcompleter.sh] needs almost no installation but will pollute the environment. Grass-Complete currently requires Bash version 2.05 for proper install. '''Author:''' Alexandre Sorokine (grass-complete), Daniel Calvelo (grass_rlcompleter.sh)
 
=== Imagery add-ons ===

* [http://www.star.ait.ac.th/~yann/6s/i.atcorr.1.3.1b.tar.gz i.atcorr] Atmospheric Correction using Christo Zietsman's implementation of 6s code in C/C++. The Old Page was rescued by Christo recently and copied [http://www.star.ait.ac.th/~yann/6s/ here]. Compiled in CVS but not tested. Update: The source code is somehow functional in GRASS CVS, it is processing and creates output map, but does not accept non-default input. Not Tested/Validated! '''Author:''' Christo Zietsman

* [http://bambi.otago.ac.nz/hamish/grass/gdal/i.warp61 i.warp61] is a shell script that will use gdalwarp to rectify a raw input image using thin plate splines. The map should be imported into GRASS with r.in.gdal and GCPs set with i.points. Input is the raw image (GeoTIFF, JPEG, etc). Output is a GeoTIFF in the imagery group's target location's map projection. Requires a recent (early 2006) version of GRASS 6.1, or newer. '''Author:''' Hamish Bowman
 

=== Display add-ons ===

==== [[IconSymbols]] ====
* [[IconSymbols|Symbols]] which can be used with ''d.vect, d.graph'', and ''ps.map''.

==== Modules ====

* [http://bambi.otago.ac.nz/hamish/grass/d.frame.quarter d.frame.quarter] is a shell script that will split the display into four quadrants using ''d.frame''. Individual frames are named ''uno, dos, tres, cuatro'', and ''full_screen''. '''Author:''' Hamish Bowman

* [ftp://gsca.nrcan.gc.ca/outgoing/Patton/Grass/Scripts/d.hyperlink.tar.bz2 d.hyperlink] is an interactive shell script that allows the viewing of hyperlinked images from a vector's attribute table in an external image viewer. Queries can be made via SQL statements or interactive mouse-clicking. The attribute table must be pre-populated with a column containing the image to link the vector to; the user also specifies the image folder in the current MAPSET where the images are located. The script currently supports gimp, Eye of Gnome, gthumb, gpdf, and Inkscape image viewers. '''Author: '''Eric Patton

* [http://www.ornl.gov/sci/gist/software/grass/ pd-GRASS]: Parallel Display for GRASS GIS '''Author:''' Alex Sorokine

* [http://bambi.otago.ac.nz/hamish/grass/d.region.box d.region.box] is a shell script that quickly displays a box around the current region. '''Author:''' Hamish Bowman

* [http://bambi.otago.ac.nz/hamish/grass/d.stations d.stations] is a shell script that quickly displays vector points (or sites for GRASS 5.4 and below). '''Author:''' Hamish Bowman

* [http://bambi.otago.ac.nz/hamish/grass/d.varea d.varea] is a shell script that quickly displays vector areas. '''Author:''' Hamish Bowman

===Postscript add-ons===

* [http://les-ejk.cz/programs/grass/ps.atlas ps.atlas] is a shell script that makes more maps on current region according to input *.psmap file. General map can be stored as vector file. The resulting *.eps maps can be automatically converted to *.pdf files. '''Author:''' Jachym Cepicky

* [[ps.map scripts|ps.map samples/templates]]

==== [[AreaFillPatterns]] ====
* Hatches for ps.map's vareas

===GRASS and UMN Mapserver===

* [http://www.mail-archive.com/mapserver-users@lists.umn.edu/msg00086.html See interesting posting]

[[Category:Community]]
[[Category:Development]]
[[Category:Documentation]]
[[Category:Installation]]

GRASS Digitizing tool

2006-12-11T14:58:10Z

⚠️Jachym: movevertex -> vertex

=v.digit=
GRASS digitizing tool should be
* written in '''wxPython''' Programming language or Tcl
* it should extend functionality of map display just like new Georeferencing tool does:
** (like ArcGIS does) only new "Digitizing Toolbox" would appear, after digitizing tool is started
** Vector file editing will happen in current map display, with all it's functions for zooming, quering and so on
* There should be graphical tool for database management, at least for adding (?and removing?) columns, adding new features and editing existing ones.

While digitising, edited vector file would be drawed to map display. ''Only currently edited or selected features would be stored in memory.'' This should spead up digitising and redrawing process significantly.

=v.edit=
GRASS graphical digitising tool should be graphical front-end for new v.edit module. v.edit should be CML tool for
* creating new vector file, eventualy overwrite existing ones '''create'''
* adding new features (points, lines, polylines, centroids) '''add'''
* removenig old features (with database record) '''delete'''
* moving whole feature '''move'''
* moving specified vertex '''vertex'''
* adding new vertext to line/boundary '''break'''
* spliting line/boundary completely '''split'''
* IMHO funtionality for adding 'z' values to vector contour lines should be back too

v.edit should accept feature selection by:
* bbox '''bbox'''
* catlist '''cats'''
* single coordinates '''coords'''

==Examples of actions==
* Create new vector file
v.edit tool=create map=vectfile
creates new vector map, eventualy will read data from standard inputs in default format (standard/point)
v.edit tool=create map=vectfile input=file.txt
creates new vector map and reads data from file file.txt in default format

* Add new feature to existing vector
v.edit tool=add map=vectfile format=standard
Read data from standard inputs in standard format
v.edit tool=add map=vectfile input=file.txt format=point
Reads data from file file.txt in point format

* Remove feature from vector file
v.edit tool=delete map=vectfile cat=34,24
Remove features with category 34 and 24 from file vectfile
v.edit tool=delete map=vectfile coords=344556.23,23445.2345
Remove feature located on coordinates 344556.23,23445.2345
v.edit tool=delete map=vectifle bbox=344556.23,234455.2345,567566.34,456455.34
Remove features defined by bounding box 344556.23,234455.2345,567566.34,456455.34

* Move feature
v.edit tool=move map=vectifle coords=344556.23,23445.2345 to=544556.23,53445.2345
Move feature located on coordinates 344556.23,23445.2345 to coordinates 544556.23,53445.2345
v.edit tool=move map=vectifle cat=45 to=544556.23,53445.2345
Move feature of category 45 to coordinates 544556.23,53445.2345
v.edit tool=move map=vectifle bbox=344556.23,234455.2345,567566.34,456455.34 to=544556.23,53445.2345
Move all features in defined by bounding box 344556.23,234455.2345,567566.34,456455.34 to 544556.23,53445.2345 (down-left corner of the bbox)

* Moving vertext
v.edit tool=vertex map=vectifile coords=344556.23,23445.2345 to=544556.23,53445.2345
Move vertex on coordinates 344556.23,23445.2345 to 544556.23,53445.2345

* Breaking line
v.edit tool=break map=vectifile coords=344556.23,23445.2345 at=345433.3,34567.32
Break line on coordinates 344556.23,23445.2345 at coords 345433.3,34567.32
v.edit tool=break map=vectifile cat=45 at=345433.3,34567.32
Break line of category 45 at coords 345433.3,34567.32

* Spliting line
v.edit tool=split map=vectifile coords=344556.23,23445.2345 at=345433.3,34567.32
Split line on coordinates 344556.23,23445.2345 at coords 345433.3,34567.32
v.edit tool=split map=vectifile cat=45 at=345433.3,34567.32
Split line of category 45 at coords 345433.3,34567.32

==Summary==
v.edit --help

Description:
Edits a vector map; allows adding, deleting and modifying objects in a vector map.

Keywords:
vector, editing

Usage:
v.edit [-tdc] map=name tool=string [input=file] [cats=range]
[coords=x,y[,x,y,...]] [to=x,y] [at=x,y] [bbox=x,y,x,y]
[--verbose] [--quiet]

Flags:
-t Do not build topology.
-d No database updates.
-c Do not close boundaries
--v Verbose module output
--q Quiet module output

Parameters:
map Name of input vector map
tool The edit action to take.
options: create,add,delete,move,movevertex,break,split
create: creates new vector file
add: add new features to existing vector file
delete: delete feature from existing vector file
move: move whole feature
vertex: move just one vertex of the feature
break: add new vertex to feature
split: split feature
input ASCII file to be converted to binary vector file, if not given reads from standard input
cats Category values
Example: 1,3,7-9,13
coords An x,y list of points
to New location of the feature
at Coordinates of breaking or spliting feature
bbox Bounding box in form x1,y1,x2,y2

= r.digit =

The r.in.poly ascii format is almost the same as the standard vector ascii format. So the new digitizer should be able to output for both, and then we have a replacement for r.digit too!

GRASS Digitizing tool

2006-12-08T08:06:48Z

⚠️Jachym: /* v.edit */

=v.digit=
GRASS digitizing tool should be
* written in Python Programming language or Tcl
* it should extend functionality of map display just like new Georeferencing tool does:
** (like ArcGIS does) only new "Digitizing Toolbox" would appear, after digitizing tool is started
** Vector file editing will happen in current map display, with all it's functions for zooming, quering and so on
* There should be graphical tool for database management, at least for adding (?and removing?) columns, adding new features and editing existing ones.

While digitising, edited vector file would be drawed to map display. ''Only currently edited or selected features would be stored in memory.'' This should spead up digitising and redrawing process significantly.

=v.edit=
GRASS graphical digitising tool should be graphical front-end for new v.edit module. v.edit should be CML tool for
* creating new vector file, eventualy overwrite existing ones '''create'''
* adding new features (points, lines, polylines, centroids) '''add'''
* removenig old features (with database record) '''delete'''
* moving whole feature '''move'''
* moving specified vertex '''movevertex'''
* adding new vertext to line/boundary '''break'''
* spliting line/boundary completely '''split'''
* IMHO funtionality for adding 'z' values to vector contour lines should be back too

v.edit should accept feature selection by:
* bbox '''bbox'''
* catlist '''cats'''
* single coordinates '''coords'''

==Examples of actions==
* Create new vector file
v.edit tool=create map=vectfile
creates new vector map, eventualy will read data from standard inputs in default format (standard/point)
v.edit tool=create map=vectfile input=file.txt
creates new vector map and reads data from file file.txt in default format

* Add new feature to existing vector
v.edit tool=add map=vectfile format=standard
Read data from standard inputs in standard format
v.edit tool=add map=vectfile input=file.txt format=point
Reads data from file file.txt in point format

* Remove feature from vector file
v.edit tool=delete map=vectfile cat=34,24
Remove features with category 34 and 24 from file vectfile
v.edit tool=delete map=vectfile coords=344556.23,23445.2345
Remove feature located on coordinates 344556.23,23445.2345
v.edit tool=delete map=vectifle bbox=344556.23,234455.2345,567566.34,456455.34
Remove features defined by bounding box 344556.23,234455.2345,567566.34,456455.34

* Move feature
v.edit tool=move map=vectifle coords=344556.23,23445.2345 to=544556.23,53445.2345
Move feature located on coordinates 344556.23,23445.2345 to coordinates 544556.23,53445.2345
v.edit tool=move map=vectifle cat=45 to=544556.23,53445.2345
Move feature of category 45 to coordinates 544556.23,53445.2345
v.edit tool=move map=vectifle bbox=344556.23,234455.2345,567566.34,456455.34 to=544556.23,53445.2345
Move all features in defined by bounding box 344556.23,234455.2345,567566.34,456455.34 to 544556.23,53445.2345 (down-left corner of the bbox)

* Moving vertext
v.edit tool=movevertex map=vectifile coords=344556.23,23445.2345 to=544556.23,53445.2345
Move vertex on coordinates 344556.23,23445.2345 to 544556.23,53445.2345

* Breaking line
v.edit tool=break map=vectifile coords=344556.23,23445.2345 at=345433.3,34567.32
Break line on coordinates 344556.23,23445.2345 at coords 345433.3,34567.32
v.edit tool=break map=vectifile cat=45 at=345433.3,34567.32
Break line of category 45 at coords 345433.3,34567.32

* Spliting line
v.edit tool=split map=vectifile coords=344556.23,23445.2345 at=345433.3,34567.32
Split line on coordinates 344556.23,23445.2345 at coords 345433.3,34567.32
v.edit tool=split map=vectifile cat=45 at=345433.3,34567.32
Split line of category 45 at coords 345433.3,34567.32

==Summary==
v.edit --help

Description:
Edits a vector map; allows adding, deleting and modifying objects in a vector map.

Keywords:
vector, editing

Usage:
v.edit [-tdc] map=name tool=string [input=file] [cats=range]
[coords=x,y[,x,y,...]] [to=x,y] [at=x,y] [bbox=x,y,x,y]
[--verbose] [--quiet]

Flags:
-t Do not build topology.
-d No database updates.
-c Do not close boundaries
--v Verbose module output
--q Quiet module output

Parameters:
map Name of input vector map
tool The edit action to take.
options: create,add,delete,move,movevertex,break,split
create: creates new vector file
add: add new features to existing vector file
delete: delete feature from existing vector file
move: move whole feature
movevertex: move just one vertex of the feature
break: add new vertex to feature
split: split feature
input ASCII file to be converted to binary vector file, if not given reads from standard input
cats Category values
Example: 1,3,7-9,13
coords An x,y list of points
to New location of the feature
at Coordinates of breaking or spliting feature
bbox Bounding box in form x1,y1,x2,y2

GRASS Digitizing tool

2006-12-07T15:44:41Z

⚠️Jachym:

GRASS Digitizing tool

2006-12-07T15:38:36Z

⚠️Jachym: /* v.edit */

GRASS digitizing tool should be
* written in Python Programming language or Tcl
* it should extend functionality of map display just like new Georeferencing tool does:
** (like ArcGIS does) only new "Digitizing Toolbox" would appear, after digitizing tool is started
** Vector file editing will happen in current map display, with all it's functions for zooming, quering and so on
* There should be graphical tool for database management, at least for adding (?and removing?) columns, adding new features and editing existing ones.

While digitising, edited vector file would be drawed to map display. ''Only currently edited or selected features would be stored in memory.'' This should spead up digitising and redrawing process significantly.

=v.edit=
GRASS graphical digitising tool should be graphical front-end for new v.edit module. v.edit should be CML tool for
* adding new features (points, lines, polylines, centroids)
* removenig old features (with database record)
* moving whole feature
* moving specified vertex
* spliting new vertex between two existing ones
* IMHO funtionality for adding 'z' values to vector contour lines should be back too

v.edit should accept feature selection by:
* bbox
* catlist
* single coordinates

==v.edit input types==
v.edit should accept inputs in following formats (based on v.in.acii):
=== For adding new features===
* point
e.g.
x|y|z
10|20|30
* standard
e.g.
L 1
10 20 30
20 30 40
1
===For removing existing features===
* list of categories with specified separator
* coordinate pair
x,y
* bounding box
x1,y1,x2,y2

===For moving existing feature===
Feature identification like for removing existing featuer
* Dx,Dy
* new x,y of first node

===For breaking line===
* x,y

===For moving vertex===
* identification by x,y
* moving like moving of whole feature

GRASS Digitizing tool

2006-12-07T14:08:54Z

⚠️Jachym:

GRASS Digitizing tool

2006-12-07T14:08:03Z

⚠️Jachym:

=GRASS digitizing tool= should be
* written in Python Programming language or Tcl
* it should extend functionality of map display just like new Georeferencing tool does:
** (like ArcGIS does) only new "Digitizing Toolbox" would appear, after digitizing tool is started
** Vector file editing will happen in current map display, with all it's functions for zooming, quering and so on
* There should be graphical tool for database management, at least for adding (?and removing?) columns, adding new features and editing existing ones.

While digitising, edited vector file would be drawed to map display. ''Only currently edited or selected features would be stored in
memory.'' This should spead up digitising and redrawing process significantly.

=v.edit=
GRASS graphical digitising tool should be graphical front-end for new v.edit module. v.edit should be CML tool for
* adding new features (points, lines, polylines, centroids)
* removenig old features (with database record)
* moving whole feature
* moving specified vertex
* spliting new vertex between two existing ones
* IMHO funtionality for adding 'z' values to vector contour lines should be back too

v.edit should accept feature selection by:
* bbox
* catlist
* single coordinates

Development

2006-12-07T13:53:03Z

⚠️Jachym: /* Sandbox (ideas section) */

__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)
* [[Updating GRASS Documentation]] How-To
* [[GIS Concepts]] and how they are implemented in GRASS
* [[GRASS Debugging]]
* [[Large File Support]] (LFS) implementation
* '''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://intevation.de/rt/webrt?q_queue=grass GRASS bug and wish tracking system]

* [http://wald.intevation.org/projects/grass/ ''New'' GRASS bug and wish tracking system] (experimental)

* [[GRASS AddOns]] - User code contributions (custom scripts, modules, icons, etc)

* [[Compile and Install]] hints

===== CVS =====
* Main [http://grass.ibiblio.org/devel/cvs.php CVS server] help page
* Live [http://freegis.org/cgi-bin/viewcvs.cgi/ GRASS WebCVS interface] browsable source code repository
* Hints for [[Working with CVS]]

===== QA =====
* [[Testing GRASS software]] - a test protocol based on the Spearfish sample data set

* Internal GRASS test suite (scripts collection in "testsuite/")

* External [http://www-pool.math.tu-berlin.de/~soeren/grass/GRASS_TestSuite/html_grass-6.2/ GRASS test suite] (TU Berlin)

* External [http://web.soccerlab.polymtl.ca/grass-evolution/grass-browsers/grass-index-en.html GRASS Quality Assessment and monitoring system] (École Polytechnique de Montréal and ITC-irst)

* CVS-commit reports into [irc://irc.freenode.net/grass IRC '#grass' channel] via [http://cia.navi.cx/stats/project/GRASS CIA - The open source informant]

* [http://www.google.com/codesearch?q=package%3Agrass Google Code Search]

* what was that other one??

* [http://koders.com Koders Code Search]

==== 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]
* [http://wiki.qgis.org/qgiswiki/GrassCookbook QGIS GRASS Cookbook] - Recipes for common tasks

=== GRASS License ===

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

=== Plans ===

===== Overview =====

* [[Release Roadmap]] (old [http://grass.ibiblio.org/devel/roadmap.php Development Roadmap] which needs freshening) - please help with testing release candidates
* [[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, see also [[Release Roadmap]])
* [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]]
* [[Image processing]]
* [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
* Discussion on add-on manager repository setup: [[Development GEM|GEM repository]]
* Discussion of support for [[time series in GRASS]], e.g. for linking to data and models
* [[GRASS GUI]] development
* [[GRASS Location Wizard]] development
* [[GRASS Digitizing tool]] ideas

=== Linking GRASS to external languages ===
* [http://mpa.itc.it/markus/grass63progman/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]]

GRASS and Python

2006-11-03T08:10:23Z

⚠️Jachym: /* Python-GRASS add-ons */

==Python SIGs==
Python Special Interest Groups are focused collaborative efforts to develop, improve, or maintain specific Python resources. Each SIG has a charter, a coordinator, a mailing list, and a directory on the Python website. SIG membership is informal, defined by subscription to the SIG's mailing list. Anyone can join a SIG, and participate in the development discussions via the SIG's mailing list. Below is the list of currently active Python SIGs, with links to their resources.

See more at http://www.python.org/community/sigs/

==Writing python scripts in GRASS==
Python is between shell and C programms. For C part - it can handle GRASS C functions via swig. For shell part, it can be processed with g.parser, so automatic input check and help generation (apart from translation) can be processed.

Example of python script, which is processed by g.parser:
#!/usr/bin/python

import sys
import os

#%Module
#% description: g.parser test script
#% keywords: keyword1, keyword2
#%End
#%flag
#% key: f
#% description: a flag
#%END
#%option
#% key: raster
#% type: string
#% gisprompt: old,cell,raster
#% description: raster input map
#% required : yes
#%end
#%option
#% key: vector
#% type: string
#% gisprompt: old,vector,vector
#% description: vector input map
#% required : yes
#%end
#%option
#% key: option1
#% type: string
#% description: an option
#% required : yes
#%end

def main():

#add your code here
print ""

if ( os.getenv("GIS_FLAG_f") != "0" ):
print "Flag -f set"
else:
print "Flag -f not set"

print "Value of GIS_OPT_option1: %s" % os.getenv("GIS_OPT_option1")
print "Value of GIS_OPT_raster: %s" % os.getenv("GIS_OPT_raster")
print "Value of GIS_OPT_vect: %s" % os.getenv("GIS_OPT_vect")

#end of your code
return

if __name__ == "__main__":
args = ""
for arg in sys.argv:
args += arg+" "
try:
if ( sys.argv[1] != "@ARGS_PARSED@" ):
os.system("g.parser %s " % (args))
except IndexError:
os.system("g.parser %s" % (args))

if sys.argv[1] == "@ARGS_PARSED@":
main();
==Python extensions for GRASS GIS==
=== wxPython GUI development for GRASS ===
'''[http://www.public.asu.edu/~cmbarton/files/grass_wxpython/ Link to wxPython prototype GUI for GRASS 6]'''

'''Update 18:02, 14 August 2006 (CEST) '''New version implements double buffered drawing to fix display issues on Debian, including flickering why panning and display being erased by overlaying windows. Output to PNG file added. Better looking zoom rectangles.

'''*****The wxPython code is moving to the GRASS CVS. You should look for the newest versions there. Volunteers to help with the new GUI are welcomed!*****''' [[User:Cmbarton|Cmbarton]]

'''Update 00:50, 9 August 2006 (CEST) '''New version will run directly from GRASS prompt with new startup script. Now put gism.py and associated files into $GISBASE/etc/gmwxp and add a new script (gm.wxp) to the $GISBASE/scripts folder. Then simply type gm.wxp& from the GRASS command prompt to get the new prototype wxPython GUI for GRASS. See instructions in today's package update. [[User:Cmbarton|Cmbarton]]

'''Update 23:59, 7 August 2006 (CEST) '''New version with nearly complete raster menu by Yann Chemin. [[User:Cmbarton|Cmbarton]]

'''Update 19:02, 7 August 2006 (CEST)'''I just uploaded a new version of gism.py and related files. I'll keep an archive and so am changing the link to go to the folder rather than the file itself so I won't have to keep changing the link. This update includes the following changes:
*The biggest change in wrapping in grassgui.py. This provides autogenerated wxPython GUI dialogs for all grass commands.
This can now be called from the command console (just type in the command name with no arguments as you do now) or the
prototype menus. I updated grassgui.py to current wxPython syntax (mostly) and added methods to make it callable from
other modules.
*Methods added to gism.py and grassgui.py that automatically restart them with pythonw for the Mac
--[[User:Cmbarton|Cmbarton]] 19:02, 7 August 2006 (CEST)

Initial development has begun on the next generation UI for GRASS. wxPython is the leading contender for a platform in which to continue development of the GRASS GUI. wxPython is a Python implementation of the well known wxWidgets (formerly wxWindows) interface development platform for C++. An initial demonstration was developed by Jachym Cepicky to show the possibility of controling GRASS via wxPython. A second generation prototype has been completed, building on Jachym's work. It is available for testing and further development at link above.
--[[User:Cmbarton|Cmbarton]] 07:15, 4 August 2006 (CEST)

===Python-SWIG-GRASS interface===
There is a prototype GRASS-SWIG interface available (thanks to Sajith VK), find it in GRASS 6-CVS: '''swig/python/'''. Draft documentation is [http://mpa.itc.it/markus/grass63progman/swig/ here]. It now wraps both raster and vector data C functions plus the general GIS (G_*()) functions.

Background: [http://www.swig.org SWIG] (Simplified Wrapper and Interface Generator) is:

* A compiler that turns ANSI C/C++ declarations into scripting language interfaces.
* Completely automated (produces a fully working Python extension module).
* Language neutral. SWIG can also target Tcl, Perl, Guile, MATLAB, etc...
* Attempts to eliminate the tedium of writing extension modules.

Sample script for raster access (use within GRASS, Spearfish session):
#!/usr/bin/python
import python_grass6 as g6lib

input = 'roads'
mapset = 'PERMANENT'

# initialize
g6lib.G_gisinit('')
infd = g6lib.G_open_cell_old(input, mapset)
cell = g6lib.G_allocate_cell_buf()

rown=0
# the API still needs error checking to be added
while 1:
myrow = g6lib.G_get_map_row_nomask(infd, cell, rown)
print rown,myrow[0:10]
rown = rown+1
if rown==476:break

g6lib.G_close_cell(infd)
g6lib.G_free(cell)

Sample script for vector access (use within GRASS, Spearfish session):
#!/usr/bin/python
import python_grass6 as g6lib

input = 'soils'
mapset = 'PERMANENT'

# initialize
g6lib.G_gisinit('')

# define map structure
map = g6lib.Map_info()

# define open level (level 2: topology)
g6lib.Vect_set_open_level (2)

# open existing map
g6lib.Vect_open_old(map, input, mapset)

# query
print 'Vect is 3D: ', g6lib.Vect_is_3d (map)
print 'Vect DB links: ', g6lib.Vect_get_num_dblinks(map)
print 'Map Scale: 1:', g6lib.Vect_get_scale(map)

# close map
g6lib.Vect_close(map)

'''TODO''': Implement modules support in a Python class using --interface-description and a Python-XML parser. This should be a generic class with module's name as parameter, returning back an object which describes the module (description, flags, parameters, status of not/required). See [http://freegis.org/cgi-bin/viewcvs.cgi/grass6/gui/wxpython/ GRASS 6 wxPython interface] for inspiration. Important is to auto-generate the GRASS-Python class at compile time with a Python script.

=== Python-GRASS add-ons ===

Stand-alone addons:

# Jáchym Čepický's G-ps.map, a GUI to typeset printable maps with ps.map (http://les-ejk.cz/?cat=gpsmap)
# Jáchym Čepický's v.pydigit, a GUI to v.edit (http://les-ejk.cz/?cat=vpydigit)
# Jáchym Čepický's PyWPS, GRASS-Web Processing Service (http://pywps.wald.intevation.org)

=== Using Grass gui.tcl in python ===

Here is some example code to use the grass automatically generated guis in python code. This could (should) all be bundled up and abstracted away so that the implementation can be replaced later.

import Tkinter
import os

# Startup (once):

tk = Tkinter.Tk()
tk.eval ("wm withdraw .")
tk.eval ("source $env(GISBASE)/etc/gui.tcl")
# Here you could do various things to change what the gui does
# See gui.tcl and README.GUI

# Make a gui (per dialog)
# This sets up a window for the command.
# This can be different to integrate with tkinter:
tk.eval ('set path ".dialog$dlg"')
tk.eval ('toplevel .dialog$dlg')
# Load the code for this command:
fd = os.popen ("d.vect --tcltk")
gui = fd.read()
# Run it
tk.eval(gui)
dlg = tk.eval('set dlg') # This is used later to get and set

# Get the current command in the gui we just made:
currentcommand = tk.eval ("dialog_get_command " + dlg)

# Set the command in the dialog we just made:
tk.eval ("dialog_set_command " + dlg + " {d.vect map=roads}")

== Links ==

=== Programming ===
* GRASS-SWIG interface http://mpa.itc.it/markus/grass63progman/swig/
* SWIG http://www.swig.org/
* SIP (C/C++ bindings generator) http://directory.fsf.org/all/Python-SIP.html
* Python and GDAL/OGR:
** [http://mapserver.gis.umn.edu/community/conferences/MUM3/workshop/python Open Source Python GIS Hacks Mum'03]
** http://hobu.biz/software/OSGIS_Hacks - Python OSGIS Hacks '05
** http://zcologia.com/news/categorylist_html?cat_id=8
** http://www.perrygeo.net/wordpress/?p=4
* Python bindings to PROJ:
** http://www.cdc.noaa.gov/people/jeffrey.s.whitaker/python/pyproj.html
* Other external projects
** Scientific Python: http://www.scipy.org/

=== Presentations ===

From FOSS4G2006:
* [http://www.foss4g2006.org/materialDisplay.py?contribId=136&sessionId=48&materialId=slides&confId=1 A Python sweeps in the GRASS] - A. Frigeri 2006
* [http://www.foss4g2006.org/materialDisplay.py?contribId=67&sessionId=48&materialId=slides&confId=1 GRASS goes web: PyWPS] - J. Cepicky 2006

[[Category:Development]]
[[Category:Linking to other languages]]

GRASS 6.2 Feature Plan

2006-10-31T19:40:19Z

⚠️Jachym: /* WONTFIX? Later? */

GRASS 6.2 Feature Plan

2006-10-23T10:45:13Z

⚠️Jachym: /* RC3 */

AddOns

2006-10-17T06:09:48Z

⚠️Jachym: /* Raster add-ons */

This page contains references to user contributions and add-ons (the original GRASS GIS software can be downloaded [http://grass.itc.it/download/index.php here]).

__TOC__

==Copyright and licensing information==

''Please be sure to include copyright and licensing information in the header comments of your code so that others may know how they can use, extend, modify, and redistribute your work.''

e.g. at the top of a shell script:
<pre>
#!/bin/sh
############################################################################
#
# MODULE: v.in.e00
#
# AUTHOR(S): Markus Neteler, Otto Dassau
#
# PURPOSE: Import E00 data into a GRASS vector map
# Imports single and split E00 files (.e00, .e01, .e02 ...)
#
# COPYRIGHT: (c) 2004, 2005 GDF Hannover bR, http://www.gdf-hannover.de
#
# This program is free software under the GNU General Public
# License (>=v2). Read the file COPYING that comes with GRASS
# for details.
#
#############################################################################
#
# REQUIREMENTS:
# - avcimport: http://avce00.maptools.org

[script follows]
</pre>

==Shell script coding standards==

Please have a look at our [http://grass.itc.it/grass63/source/SUBMITTING_SCRIPTS Shell script coding standards] before submitting here.

==Miscellaneous Add-ons==

* [http://bambi.otago.ac.nz/hamish/grass/utm_which_zone.sh utm_which_zone.sh] is a shell script to determine UTM zone from Lat/Lon input. Requires [http://www.octave.org Octave] to be installed. A shell-only version is [http://dcalvelo.free.fr/grass/utm_which_zone_sh.sh available] which only requires awk. '''Authors''': Hamish Bowman (Octave part), Markus Neteler (shell script wrapper), Daniel Calvelo (sh+awk version)

* Perl scripts for converting data forth and back between Excel files and PostgreSQL: [http://dcalvelo.free.fr/grass/pg2xls.pl pg2xls.pl] reads data from PostgreSQL and produces an excel workbook; [http://dcalvelo.free.fr/grass/xls2sql.pl xls2sql.pl] reads excel files and outputs SQL statements to be fed into an RDBMS. Both scripts need modules from [http://www.cpan.org CPAN], especially [http://search.cpan.org/dist/Spreadsheet-ParseExcel/ Spreadsheet::ParseExcel] for xls2sql.pl and [http://search.cpan.org/~tmtm/Spreadsheet-WriteExcel-FromDB Spreadsheet::WriteExcel::FromDB] and its dependencies for pg2sql.pl. Check the source headers for more info. '''Authors:''' Daniel Calvelo (xls2sql.pl), Markus Neteler (pg2xls.pl)

* [http://dream.lrrl.arch.tu-muenchen.de/~wqual/perl/dbf2sql.tgz dbf2sql] is a Perl script for translating dbf-tables into a sql-command. dbf-tables are read using dbfdump-command from dbd-xbase-perl module ([http://search.cpan.org/~janpaz/DBD-XBase-0.241/ dbd::xbase] and [http://search.cpan.org/~jv/Getopt-Long-2.35/lib/Getopt/Long.pm getopt::long] have to be installed from CPAN first). There are problems, if the last column of the table contains characters. Suggestions for improvements welcome! '''Author:'''Wolfgang Qual

* [http://www.igc.usp.br/pessoais/guano/downloads/azimuth2.c azimuth2.c] is a small C program to calculate the azimuth and length of vector lines exported by GRASS-GIS as ASCII files (like this: v.out.ascii input=vector output=ascii format=standard). It is useful for create rose diagrams of lineament maps. Improvements on the original code after suggestions by Örs Téglásy, Hungary. '''Author:''' Carlos Henrique Grohmann

==GRASS 5.x==

===Vector add-ons for GRASS 5===

* See here: http://grass.itc.it/download/addons.php

===Raster add-ons for GRASS 5===

* See here: http://grass.itc.it/download/addons.php

* [http://www.valledemexico.ambitiouslemon.com/gwmodelling.html r.gmtg] The groundwater modelling tool for grass. A module to use MODFLOW within GRASS. '''Author''': Jaime Carrera

==GRASS 6.x==

===Vector add-ons===

* [http://geni.ath.cx/grass/v.out.gmt v.out.gmt] is a shell script that exports a polygon vector file into GMT xy file. psbasemap code was copied from Hamish's r.out.gmt. '''Author:''' Huidae Cho, Hamish Bowman, Dylan Beaudette

* [http://geo4.uibk.ac.at/tilde/kindl/grass/v.strahler.tgz v.strahler] is a module that calculates the Strahler Order for all lines of a given dendritic network. '''Author:''' Florian Kindl

* [http://svg.cc/grass/index.html v.out.svg] is a module that exports SVG notation along with optional attribute data directly from GRASS 6.x vector layers. '''Author:''' Klaus Förster

* [http://les-ejk.cz/programs/trees.html v.trees3d] is a module for making 3D trees from input vector point file. '''Author:''' Jachym Cepicky

* [http://www.public.asu.edu/~cmbarton/files/grass_scripts/v.lda v.lda] is a shell script for calculating Ian Johnson's (U. Sidney) Local Density Analysis values to measure clustering of point data at different neighborhood radii. There is an option to create a simple line graph of the results. There have been reports of problems creating the line graph on Cygwin installations of GRASS. '''Author:''' Michael Barton

* [http://www.public.asu.edu/~cmbarton/files/grass_scripts/v.append v.append] is a shell script combining two vector files AND their associated attribute tables. The vector files should be of the same type and, for best results, should have identically formatted attribute tables. '''Author:''' Michael Barton

* [http://www.shockfamily.net/cedric/grass/v.group v.group] generates a new vector map with the same geometry as an existing map. The new map has categories and a table based on grouping by the values in certain columns of the existing map's table. The values in these columns are preserved in the table for the new map. It's like a v.reclass that preserves data. '''Author:''' Cedric Shock

* [http://bambi.otago.ac.nz/hamish/grass/v.out.ascii.db v.out.ascii.db] is a shell script for exporting vector point data coordinates and selected attribute columns to either a file or to the console. '''Author:''' Hamish Bowman

* [http://www.fle.czu.cz/~jachym/programs/v.rasterbounds v.rasterbounds] is a shell script for creating polygon-vector file of rasterfile boundaries. The best version of GRASS is 6.1+. If you are using GRASS < 6.1, you have to be in the same mapset as your raster maps are from. '''Author:''' Jachym Cepicky

* [http://www.fle.czu.cz/~jachym/programs/v.3Dtin v.3Dtin] is a shell script for making 3D-vector of the 2D ouput from ''v.delauny''. '''Author:''' Jachym Cepicky

* [http://www.clubwebcanada.ca/twiens/v.sample.buffer.tgz v.sample.buffer] is a shell script that samples rasters in buffers of a specified size around features in a specified vector file. Sampling results are added as attributes to the vector file. This script was designed for sampling vegetation indices and DEM derived attributes for bird point counts. Sampling results can be one or more basic statistics such as mean, range, max, etc. '''Author:''' Trevor Wiens

* [http://www.gfosservices.it/materiale_didattico/moduli/v.variogram.tar.gz v.variogram] is a script that create an omnidirectional experimental semi-variogram. This scripts require R-statistics software installed on your machine. Please see a [http://grass.itc.it/pipermail/statsgrass/2006-October/000455.html reply] on the STATGRASS list for changes need to the script to run on spgrass6 >= 0.3 and sp >= 0.9. '''Author:''' Ivan Marchesini, Pierluigi De Rosa.

* [http://www.gfosservices.it/materiale_didattico/moduli/v.krige.tar.gz v.krige] is a script that do a surface interpolation from vector point data by Kriging method.The interpolated value of a cell is determined by using an omnidirectional variogram model fitted starting from model parameter given by user desumed from the experimental semi variogram produced by v.variogram. '''Author:''' Ivan Marchesini, Pierluigi De Rosa

* [http://ngeo.de/grassstuff/v.lmeasure v.lmeasure] and [http://ngeo.de/grassstuff/v.revlmeasure v.revlmeasure] are two perl scripts that place equidistant vector points along a given arbitrary vector line starting from the beginning or end of the vector line, respectively. Resulting vector points are labeled with the distance from origin. '''Author:''' Mats Schuh

* [http://david.p.finlayson.googlepages.com/v.swathwidth v.swathwidth] creates a vector map representing the sea bottom coverage of a multibeam (swath) sonar survey. '''Author:''' David Finlayson

* [http://kufaya.googlepages.com/v.flip.tar.gz v.flip] flips the direction of selected vector lines. '''Author:''' Maciej Sieczka

* [http://phygeo7.geo.uni-augsburg.de/gis2/scripts/v.digatt v.digatt] (shell script) Interactively assign numeric table attributes to series of vector objects. It is meant to be effective by avoiding to type in the attribute value for all single objects again and again. The user is prompted for typing in an attribute value which is assigned to all objects selected by mouseclick afterwards. Next the display is redrawn after updating the table column. Zooming allows to change the region before the old value can be reused or a new one can be typed in (or copied by mouse from another object) in order to assign it to the next series of objects etc. It is tested not very extensively yet. Therefore better work with a copy of your map and consider using v.digit or d.what.vect -e alternatively. [http://phygeo7.geo.uni-augsburg.de/gis2/scripts/v.digatt.png screenshot]. '''Author:''' Andreas Philipp

* [http://k153-85.fsv.cvut.cz/cgi-bin/viewcvs.cgi/grass6/vector/v.in.gama/ v.in.gama] converts [http://www.gnu.org/software/gama/ GNU GaMa] XML output file to a GRASS vector map layer. '''Author:''' Martin Landa

===Raster add-ons===

* [http://www.igc.usp.br/pessoais/guano/downloads/r.roughness r.roughness] is a shell script to calculate the surface roughness of a DEM, using r.surf.area and v.surf.rst. (for GRASS versions 6.1 and above)
* [http://www.igc.usp.br/pessoais/guano/downloads/r.roughness60 r.roughness60] - for GRASS versions 6.0.X '''Author:''' Carlos Henrique Grohmann

* [http://les-ejk.cz/programs/grass/r.gauss.tgz r.gauss] is Gaussian and Laplacian of Gaussian filter for GRASS. It is written in C language. '''Author:''' Jachym Cepicky

* [http://les-ejk.cz/programs/grass/r.mlv.tgz r.mlv] is Mean of least variance filter for GRASS. It is an edge-preserving (or even edge-enhacing) filter, which should serve for removing additive noise from images. It is written in C language. '''Author:''' Jachym Cepicky

* [http://les-ejk.cz/programs/grass/r.bilateral.tgz r.bilateral] Bilateral filter is an edge-preserving filter, which combines domain and range filtering. It is written in C language. '''Author:''' Jachym Cepicky

* [http://les-ejk.cz/programs/zc.pl Zero crossing] is a simple Perl script, finds the ,,zero crossings`` from the Laplacian of Gaussian filter (see above). It is really very simple, the edges don't need to be really on that pixel, where they are detected, no interpolation is performed. '''Author:''' Jachym Cepicky

'''Usage:'''
zc.pl -i input -o output |r.mapcalc

* [http://les-ejk.cz/programs/local_max.pl Local maxima] is a Perl script for <code>r.mapcalc</code>. It detects local maxima of the image. '''Author:''' Jachym Cepicky

'''Usage:'''
local_maxima.pl -i input -o output -s matrix_size|r.mapcalc

* [http://bambi.otago.ac.nz/hamish/grass/r.out.gmt r.out.gmt] is a GRASS script for exporting a GRASS raster map into a [[http://www.soest.hawaii.edu/gmt/ GMT]] grid file. It also creates a GMT color table from the data and can generate some GMT commands for plotting a postscript file. (code is experimental, but functional) see also http://169.237.35.250/~dylan/grass_user_group/#GMT_and_GRASS-overview '''Authors:''' Hamish Bowman, Dylan Beaudette

* [http://geni.ath.cx/grass/r.out.gmt yet another r.out.gmt] is a modified version of Hamish's r.out.gmt. Added options for title, xlabel, ylabel, comment, and map width. Removed any settings that can be changed by gmtset for more flexibility. '''Author:''' Hamish Bowman, Huidae Cho, Dylan Beaudette

* [http://bambi.otago.ac.nz/hamish/grass/r.pack r.pack] and [http://bambi.otago.ac.nz/hamish/grass/r.unpack r.unpack] are two GRASS scripts for transfering raster maps to another computer as a single file. '''Author:''' Hamish Bowman

* [http://bambi.otago.ac.nz/hamish/grass/dominant_dir.m dominant_dir.m] and [http://bambi.otago.ac.nz/hamish/grass/calc_terraflow_dir.m calc_terraflow_dir.m] are two Matlab scripts for determining the dominant flow direction from a r.terraflow MFD map and converting into a GRASS aspect map for use with d.rast.arrow, etc. '''Author:''' Hamish Bowman

* [http://www-pool.math.tu-berlin.de/~soeren/grass/modules/ r.in.onearth] for download and import satellite images direct from the NASA onearth WMS server into GRASS. '''Author:''' Soeren Gebbert

* [http://www.shockfamily.net/cedric/grass/r.tileset r.tileset] generates a list of tiles and sizes in a source projection that cover the region in the current database with appropriate resolution. The size of individual tiles can be constrained. Only tiles intersecting the current region are returned. These tilings are appropriate for requesting data from another projection to meet the specifications of the current region. For example, it could be used to generate tile requests to a latitude / longitude WMS server like this <code>r.tileset -w sourceproj="+init=epsg:4326"</code>. '''Author:''' Cedric Shock

* [ftp://gsca.nrcan.gc.ca/outgoing/Patton/Grass/r.csr.tar.gz r.csr] integrates several Grass programs to produce colored, shaded-relief rasters in one step. Accepts single or multiple elevation/bathymetry maps as input; optionally will fill data holidays with 3x3 median filter, multiple times, if required; can apply color maps from a) input raster, b) another raster in MAPSET, or c) from a rules file; otherwise, rainbow colorbar is applied. Output colored, shaded-relief rasters can optionally be exported to tiff format and archived using tar with gzip/bzip2 compression if appropriate flags are given. Shading parameters can be modified, though useful defaults are given. (Right-click and choose 'Save Link As') '''Author:''' Eric Patton

* [ftp://gsca.nrcan.gc.ca/outgoing/Patton/Grass/r.fragment.tar.gz r.fragment] fragments a raster into a user-defined set of smaller tiles according to an input number of rows and columns. Optionally, a null value threshold can be set to filter out candidate tiles that would have a large percentage of null cells. (Right-click and choose 'Save Link As') '''Author:''' Eric Patton

* [http://david.p.finlayson.googlepages.com/r.eucdist r.eucdist] creates a raster map estimating the euclidean distance from known cells. '''Author:''' David Finlayson

* [http://david.p.finlayson.googlepages.com/r.smoothpatch r.smoothpatch] creates a composite of two rasters using a distance-weighted average across the transition to smooth the edges. '''Author:''' David Finlayson

* [http://www.faunalia.it/download/r_li/ r.li] is meant to be a more flexible and faster replacement of the old r.le. Currently under development (help welcome). 
[http://www.faunalia.com/mediawiki/index.php/R_li Wiki page] 
[http://www.faunalia.com/cgi-bin/mailman/listinfo/r.li Mailing list] 
'''Authors:''' Claudio Porta, Davide Spano, Serena Pallecchi, [http://www.faunalia.it Faunalia]

* [http://kufaya.googlepages.com/r.surf.nnbathy.tar.gz r.surf.nnbathy] interpolates surface from raster input using [http://www.marine.csiro.au/~sakov/ nn] natural neighbor intepolation library. '''Author:''' Maciej Sieczka

* [http://www.star.ait.ac.th/~yann/sebal/r.uslek.tar.gz r.uslek] creates USLE K factor (soil erodibility) from sand,clay,silt fractions and organic matter fraction. Based on USDA 1951 (p209) quoted in FAO World Soil CD, and from some generic [soil class+OM] to K conversion table.Update: Fixed input file swap and silty-clay class recognition. '''Author:''' Yann Chemin
* [http://www.star.ait.ac.th/~yann/sebal/r.albedo.tar.gz r.albedo] creates Albedo. Albedo is the shortwave surface reflectance in the range of 0.3-3 micro-meters. This module takes Modis, Aster, Landsat or AVHRR individual surface reflectance bands to calculate Albedo. This module is a precursor to r.sun or any Energy-Balance related processing. '''Author:''' Yann Chemin
* [http://www.star.ait.ac.th/~yann/sebal/ r.eb.*] are a set of GRASS modules that together perform the main functions of the SEBAL model (Bastiaanssen, 1995). Those functions include (but are not limited to) Soil heat flux, sensible heat flux, net radiation, evaporative fraction at satellite overpass, diurnal actual evapotranspiration, momentum roughness length, etc. These modules are also part of any Energy-Balance related processing. '''Author:''' Yann Chemin
* [http://www.star.ait.ac.th/~yann/sebal/r.evapo.potrad.tar.gz r.evapo.potrad] create diurnal Potential evapotranspiration assuming all net radiation becomes ET, according to SEBAL model (Bastiaanssen, 1995). This module also has a flag for diurnal net radiation as required by SEBAL in [http://www.star.ait.ac.th/~yann/sebal/r.eb.eta.tar.gz r.eb.eta]. '''Author:''' Yann Chemin
 
* [http://www.star.ait.ac.th/~yann/sebal/r.vi.tar.gz r.vi] creates a given Vegetation index from a list of 13 of them, most of them only requiring Red and NIR. Accepts DCELL only (for now). '''Authors:''' Baburao Kamble and Yann Chemin
 
* [http://www.star.ait.ac.th/~yann/sebal/r.dn2ref.l7.tar.gz r.dn2ref.l7] [http://www.star.ait.ac.th/~yann/sebal/r.dn2ref.ast.tar.gz r.dn2ref.ast] create top of atmosphere reflectance for Landsat 7ETM+ and ASTER. These modules also have a flag for radiance output. '''Author:''' Yann Chemin
 
* [http://www.star.ait.ac.th/~yann/sebal/r.biomass.tar.gz r.biomass] create biomass growth map from APAR, lightuse efficiency, water availability (or evap.fraction), Lat, doy and tsw . '''Author:''' Yann Chemin
 

===General add-ons===

* [http://www.gdf-hannover.de/dassau/g.laptop/g.laptop.sh g.laptop.sh] is an interactive shell script to extract raster and vector data from current Location into a new one. Data can be copied or extracted in current or original resolution and region extend. This script was written to extract smaller parts of a GRASS location to be able to present them on a laptop without the necessity to transfer huge data. Maps do not have to be in the same mapset. '''Author:''' Otto Dassau

* '''''Readline completion''''' for GRASS commands under the bash shell: [http://www.sorokine.info/grass-complete/ grass-complete] won't clutter the environment but needs to be installed; [http://dcalvelo.free.fr/grass/grass_rlcompleter.sh grass_rlcompleter.sh] needs almost no installation but will pollute the environment. Grass-Complete currently requires Bash version 2.05 for proper install. '''Author:''' Alexandre Sorokine (grass-complete), Daniel Calvelo (grass_rlcompleter.sh)
 
=== Imagery add-ons ===

* [http://www.star.ait.ac.th/~yann/6s/i.atcorr.1.3.1b.tar.gz i.atcorr] Atmospheric Correction using Christo Zietsman's implementation of 6s code in C/C++. The Old Page was rescued by Christo recently and copied [http://www.star.ait.ac.th/~yann/6s/ here]. Compiled in CVS but not tested. Update: The source code is somehow functional in GRASS CVS, it is processing and creates output map, but does not accept non-default input. Not Tested/Validated! '''Author:''' Christo Zietsman

* [http://bambi.otago.ac.nz/hamish/grass/gdal/i.warp61 i.warp61] is a shell script that will use gdalwarp to rectify a raw input image using thin plate splines. The map should be imported into GRASS with r.in.gdal and GCPs set with i.points. Input is the raw image (GeoTIFF, JPEG, etc). Output is a GeoTIFF in the imagery group's target location's map projection. Requires a recent (early 2006) version of GRASS 6.1, or newer. '''Author:''' Hamish Bowman
 

=== Display add-ons ===

* [http://www.ornl.gov/sci/gist/software/grass/ pd-GRASS]: Parallel Display for GRASS GIS '''Author:''' Alex Sorokine

==== [[IconSymbols]] ====
* [[IconSymbols|Symbols]] which can be used with ''d.vect, d.graph'', and ''ps.map''.

* [http://bambi.otago.ac.nz/hamish/grass/d.frame.quarter d.frame.quarter] is a shell script that will split the display into four quadrants using ''d.frame''. Individual frames are named ''uno, dos, tres, cuatro'', and ''full_screen''. '''Author:''' Hamish Bowman

* [ftp://gsca.nrcan.gc.ca/outgoing/Patton/Grass/d.hyperlink.tar.gz d.hyperlink] is an interactive shell script that allows the viewing of hyperlinked images from a vector's attribute table in an external image viewer. Queries can be made via SQL statements or interactive mouse-clicking. The attribute table must be pre-populated with a column containing the image to link the vector to; the user also specifies the image folder in the current MAPSET where the images are located. The script currently supports gimp, Eye of Gnome, gthumb, gpdf, and Inkscape image viewers. (Right-click and choose 'Save Link As') '''Author: '''Eric Patton

* [http://bambi.otago.ac.nz/hamish/grass/d.stations d.stations] is a shell script that quickly displays vector points (or sites for GRASS 5.4 and below). '''Author:''' Hamish Bowman

* [http://bambi.otago.ac.nz/hamish/grass/d.varea d.varea] is a shell script that quickly displays vector areas. '''Author:''' Hamish Bowman

===Postscript add-ons===

* [http://les-ejk.cz/programs/grass/ps.atlas ps.atlas] is a shell script that makes more maps on current region according to input *.psmap file. General map can be stored as vector file. The resulting *.eps maps can be automatically converted to *.pdf files. '''Author:''' Jachym Cepicky

* [[ps.map scripts|ps.map samples/templates]]

==== [[AreaFillPatterns]] ====
* Hatches for ps.map's vareas

===GRASS and UMN Mapserver===

* [http://www.mail-archive.com/mapserver-users@lists.umn.edu/msg00086.html See interesting posting]

[[Category:Community]]
[[Category:Development]]
[[Category:Documentation]]
[[Category:Installation]]

GRASS and Python

2006-09-24T21:04:57Z

⚠️Jachym:

==Python SIGs==
Python Special Interest Groups are focused collaborative efforts to develop, improve, or maintain specific Python resources. Each SIG has a charter, a coordinator, a mailing list, and a directory on the Python website. SIG membership is informal, defined by subscription to the SIG's mailing list. Anyone can join a SIG, and participate in the development discussions via the SIG's mailing list. Below is the list of currently active Python SIGs, with links to their resources.

See more at http://www.python.org/community/sigs/

==Writing python scripts in GRASS==
Python is between shell and C programms. For C part - it can handle GRASS C functions via swig. For shell part, it can be processed with g.parser, so automatic input check and help generation (apart from translation) can be processed.

Example of python script, which is processed by g.parser:
#!/usr/bin/python

import sys
import os

#%Module
#% description: g.parser test script
#% keywords: keyword1, keyword2
#%End
#%flag
#% key: f
#% description: a flag
#%END
#%option
#% key: raster
#% type: string
#% gisprompt: old,cell,raster
#% description: raster input map
#% required : yes
#%end
#%option
#% key: vector
#% type: string
#% gisprompt: old,vector,vector
#% description: vector input map
#% required : yes
#%end
#%option
#% key: option1
#% type: string
#% description: an option
#% required : yes
#%end

def main():

#add your code here
print ""

if ( os.getenv("GIS_FLAG_f") != "0" ):
print "Flag -f set"
else:
print "Flag -f not set"

print "Value of GIS_OPT_option1: %s" % os.getenv("GIS_OPT_option1")
print "Value of GIS_OPT_raster: %s" % os.getenv("GIS_OPT_raster")
print "Value of GIS_OPT_vect: %s" % os.getenv("GIS_OPT_vect")

#end of your code
return

if __name__ == "__main__":
args = ""
for arg in sys.argv:
args += arg+" "
try:
if ( sys.argv[1] != "@ARGS_PARSED@" ):
os.system("g.parser %s " % (args))
except IndexError:
os.system("g.parser %s" % (args))

if sys.argv[1] == "@ARGS_PARSED@":
main();
==Python extensions for GRASS GIS==
=== wxPython GUI development for GRASS ===
'''[http://www.public.asu.edu/~cmbarton/files/grass_wxpython/ Link to wxPython prototype GUI for GRASS 6]'''

'''Update 18:02, 14 August 2006 (CEST) '''New version implements double buffered drawing to fix display issues on Debian, including flickering why panning and display being erased by overlaying windows. Output to PNG file added. Better looking zoom rectangles.

'''*****The wxPython code is moving to the GRASS CVS. You should look for the newest versions there. Volunteers to help with the new GUI are welcomed!*****''' [[User:Cmbarton|Cmbarton]]

'''Update 00:50, 9 August 2006 (CEST) '''New version will run directly from GRASS prompt with new startup script. Now put gism.py and associated files into $GISBASE/etc/gmwxp and add a new script (gm.wxp) to the $GISBASE/scripts folder. Then simply type gm.wxp& from the GRASS command prompt to get the new prototype wxPython GUI for GRASS. See instructions in today's package update. [[User:Cmbarton|Cmbarton]]

'''Update 23:59, 7 August 2006 (CEST) '''New version with nearly complete raster menu by Yann Chemin. [[User:Cmbarton|Cmbarton]]

'''Update 19:02, 7 August 2006 (CEST)'''I just uploaded a new version of gism.py and related files. I'll keep an archive and so am changing the link to go to the folder rather than the file itself so I won't have to keep changing the link. This update includes the following changes:
*The biggest change in wrapping in grassgui.py. This provides autogenerated wxPython GUI dialogs for all grass commands.
This can now be called from the command console (just type in the command name with no arguments as you do now) or the
prototype menus. I updated grassgui.py to current wxPython syntax (mostly) and added methods to make it callable from
other modules.
*Methods added to gism.py and grassgui.py that automatically restart them with pythonw for the Mac
--[[User:Cmbarton|Cmbarton]] 19:02, 7 August 2006 (CEST)

Initial development has begun on the next generation UI for GRASS. wxPython is the leading contender for a platform in which to continue development of the GRASS GUI. wxPython is a Python implementation of the well known wxWidgets (formerly wxWindows) interface development platform for C++. An initial demonstration was developed by Jachym Cepicky to show the possibility of controling GRASS via wxPython. A second generation prototype has been completed, building on Jachym's work. It is available for testing and further development at link above.
--[[User:Cmbarton|Cmbarton]] 07:15, 4 August 2006 (CEST)

===Python-SWIG-GRASS interface===
There is a prototype GRASS-SWIG interface available (thanks to Sajith VK), find it in GRASS 6-CVS: '''swig/python/'''. Draft documentation is [http://mpa.itc.it/markus/grass63progman/swig/ here]. It now wraps both raster and vector data C functions plus the general GIS (G_*()) functions.

Background: [http://www.swig.org SWIG] (Simplified Wrapper and Interface Generator) is:

* A compiler that turns ANSI C/C++ declarations into scripting language interfaces.
* Completely automated (produces a fully working Python extension module).
* Language neutral. SWIG can also target Tcl, Perl, Guile, MATLAB, etc...
* Attempts to eliminate the tedium of writing extension modules.

'''TODO''': Implement modules support in a Python class using --interface-description and a Python-XML parser. This should be a generic class with module's name as parameter, returning back an object which describes the module (description, flags, parameters, status of not/required). See [http://freegis.org/cgi-bin/viewcvs.cgi/grass6/gui/wxpython/ GRASS 6 wxPython interface] for inspiration. Important is to auto-generate the GRASS-Python class at compile time with a Python script.

Sample script (use within GRASS):

import python_grass6 as g6lib

input = 'roads'
mapset = 'PERMANENT'

g6lib.G_gisinit('')
infd = g6lib.G_open_cell_old(input, mapset)

cell = g6lib.G_allocate_cell_buf()

rown=0
while 1:
myrow = g6lib.G_get_map_row_nomask(infd, cell, rown)
print rown,myrow[0:10]
rown = rown+1
if rown==476:break

g6lib.G_close_cell(infd)
g6lib.G_free(cell)

=== Python-GRASS add-ons ===

Stand-alone addons:

# Jáchym Čepický's G-ps.map, a GUI to typeset printable maps with ps.map (http://les-ejk.cz/?cat=gpsmap)
# Jáchym Čepický's v.pydigit, a GUI to v.edit (http://les-ejk.cz/?cat=vpydigit)
# Jáchym Čepický's PyWPS, GRASS-Web Processing Service (http://les-ejk.cz/?cat=pywps)

=== Using Grass gui.tcl in python ===

Here is some example code to use the grass automatically generated guis in python code. This could (should) all be bundled up and abstracted away so that the implementation can be replaced later.

import Tkinter
import os

# Startup (once):

tk = Tkinter.Tk()
tk.eval ("wm withdraw .")
tk.eval ("source $env(GISBASE)/etc/gui.tcl")
# Here you could do various things to change what the gui does
# See gui.tcl and README.GUI

# Make a gui (per dialog)
# This sets up a window for the command.
# This can be different to integrate with tkinter:
tk.eval ('set path ".dialog$dlg"')
tk.eval ('toplevel .dialog$dlg')
# Load the code for this command:
fd = os.popen ("d.vect --tcltk")
gui = fd.read()
# Run it
tk.eval(gui)
dlg = tk.eval('set dlg') # This is used later to get and set

# Get the current command in the gui we just made:
currentcommand = tk.eval ("dialog_get_command " + dlg)

# Set the command in the dialog we just made:
tk.eval ("dialog_set_command " + dlg + " {d.vect map=roads}")

== Links ==

=== Programming ===
* GRASS-SWIG interface http://mpa.itc.it/markus/grass63progman/swig/
* SWIG http://www.swig.org/
* SIP (C/C++ bindings generator) http://directory.fsf.org/all/Python-SIP.html
* Python and GDAL/OGR:
** [http://mapserver.gis.umn.edu/community/conferences/MUM3/workshop/python Open Source Python GIS Hacks Mum'03]
** http://hobu.biz/software/OSGIS_Hacks - Python OSGIS Hacks '05
** http://zcologia.com/news/categorylist_html?cat_id=8
** http://www.perrygeo.net/wordpress/?p=4
* Python bindings to PROJ:
** http://www.cdc.noaa.gov/people/jeffrey.s.whitaker/python/pyproj.html
* Other external projects
** Scientific Python: http://www.scipy.org/

=== Presentations ===

From FOSS4G2006:
* [http://www.foss4g2006.org/materialDisplay.py?contribId=136&sessionId=48&materialId=slides&confId=1 A Python sweeps in the GRASS] - A. Frigeri 2006
* [http://www.foss4g2006.org/materialDisplay.py?contribId=67&sessionId=48&materialId=slides&confId=1 GRASS goes web: PyWPS] - J. Cepicky 2006

[[Category:Development]]
[[Category:Linking to other languages]]

Time series development

2006-09-23T08:07:49Z

⚠️Jachym: /* Jachym's notes */

This page is born out of discussions in Lausanne. A lot of people seem to be interested in having some standardized, documented format for dealing with time series in GRASS, so that we can deal with data (e.g. climate station, water gauges), link with models, etc., without having to come up with a custom solution each time. This could also lead to modules to help with interpolation to deal with missing values, etc.

There was also discussion of possibly setting up a mailing list. Do we want this?
: I would vote against just-another-mailing list [[User:Neteler|Neteler]] 23:51, 18 September 2006 (CEST)

==== Ideas from MN ====

* each imported raster map get's automatically "registered" in an SQL table
** Table structure:
*** map name
*** map creator (optional)
*** time stamp of import
*** time stamp of map production (optional)
*** time range of validity (optional)
* g.list, g.rename etc. tools have a new "where" parameter do search maps in this table
* g.remove will also remove row from SQL table
* SQL commands can be used for search by time stamps

===== maxi's proposal =====
* what about a table with time series (sort of header of each time series) and another table for each time serie with a list of associated filename and related timestamp?
** time series head table structure:
*** series name
*** creator name
*** timestamp of creation
*** range of validity
*** time step
*** ....
** time serie associated map (table named like the related time serie):
*** timestamp
*** map name
*** timestamp of import

==== Soerens ideas ====

* the temporal gis extension of grass should manage:
** raster, raster3d, vector maps and groups of raster maps (imagery groups)
** the existing timestamps should be used for registration in a temporal database
** the timestamp should be automatically created if a map is created
** all maps can be registered and unregistered in the temporal database
** it should be possible to cretae several temporal tables in the database
*** '''those tables are a new datatype in grass'''
*** the tables should be used for thematic time series
*** maps and groups may be registered in different tables
*** it should be very easy to register and unregister thousands of maps in the database
*** tables will have a description, history, transaction log, ceration time and modification time
*** statistical Informations about the maps (ranges) should be stored in the database
*** if the raster map changes the table should be easily updatable (automatic update implemented in the libs -> if map is closed update the temporal table)
** the temporal database should allow temporal queries for one, several or all tables in the database

===== changes to existing libs/modules =====

* timestamps support for groups must be added
* r.timestamp, r3.timestamp and v.timestamp should be implemented in g.timestamp with group support
* support for temporal region (starttime, endtime, timesteps) in g.region
* g.remove, g.rename and g.copy will need to have access to the temporal database
** if a maps is removed and registered in temporal tables, the table entry should also be removed
** every map keeps the info in which temporal tables it is registered (additional file or info in header)
* g.list should list all temporal databases, not the registered maps (t.info should do this)
* if automatically temporal table update is requested, all the file io libs of raster, raster3d, vector maps and groups have to be extended

===== temporal database =====

* the temporal database in which the maps/groups are registered should provide temporal queries
** select all maps between 20 jan 2002 nad 13 feb 2004
** select all maps with a valid range of 3 months
** select all maps with datum < 13 sep 1999
** select all maps with a valid range of 10 years and a value range between [20:45]
** Postgresql is the only Open Source database which supports such queries and suitable temporal datatypes [[http://www.postgresql.org/files/documentation/books/pghandbuch/html/datatype-datetime.html]] and [[http://www.postgresql.org/files/documentation/books/pghandbuch/html/functions-datetime.html#FUNCTIONS-DATETIME-CURRENT]]
** another way is to implement this functionality in a double linked list

===== timestamps in temporal database =====

* the following timestamps should be created in the database
** a valid timestamp with startime or start- and endtime
** creation time
** modification time

===== temporal management tools =====

* the temporal management should be done by specific commands starting with t.*
* tools for queries, register, unregister und extraction of maps from the temporal database have to be implemented, like t.info, t.register, t.unregister and t.extract ...

Example t.register:

GRASS 6.3.cvs > t.register help

Description:
Register groups, raster, raster3d and vector maps into the temporal database

Keywords:
temporal, time

Usage:
t.register [-s] [tgroup=string[,string,...]]
[trast=string[,string,...]] [trast3d=string[,string,...]]
[tvect=string[,string,...]] [group=string[,string,...]]
[rast=string[,string,...]] [rast3d=string[,string,...]]
[vect=string[,string,...]] [date=timestamp[,timestamp,...]]
[timestep=timestep[,timestep,...]]

Flags:
-s Use the timestep between new maps.

Parameters:
tgroup Temporal group database(s) in which the group(s) should be registered
trast Temporal raster database(s) in which the raster(s) should be registered
trast3d Temporal raster3d database(s) in which the raster3d(s) should be registered
tvect Temporal vector database(s) in which the vector(s) should be registered
group Group(s) to be registered in the temporal group database
rast Raster map(s) to be registered in the temporal raster database
rast3d Raster3d map(s) to be registered in the temporal raster3d database
vect Vector map(s) to be registered in the temporal vector database
date datetime, datetime1/datetime2 for map(s)
timestep timestep between the maps

====== example ======

register 3 raster maps beginning from 20 jan 2001 with a timestep of 3 month in database Landsat
t.register -s trast=Landsat rast=LandsatJan,LandsatApr,LandsatJul date="20 jan 2001" timestep="3 mon"

Table:
1 LandsatJan 20 jan 2001 ...
2 LandsatApr 20 apr 2001 ...
3 LandsatJul 20 jul 2001 ...

===== OO Layer =====

* it should be possible to have data access with spatial-temporal functions:
** value = g4dDataObject->Get4DValue(x, y, z, timestamp) -- for volume maps
** value = g4dDataObject->Get4DValue(x, y, timestamp) -- for raster maps

* based on this functionality a 4d animation tool based on VTK should be implemented

==== Jachym's notes ====
On IRC, we discussed, that time series would be stored in database (PostgreSQL). If data format would be like YYYY-MM-DD-HH-MM-SS, the "database" could be some textfile, which would be sortable via standard 'sort' and g.* modules would not need to speek SQL - KISS, works even on a toaster.

g.list rast should print all raster maps. Raster map belonging to time serie does not stop to be raster map. New data type "times" has to be created, so that modules like g.list, g.remove ... can handle it.

If "times" is going to be new GRASS data type, new t.* group of commands has to be introduced, to have equivalent commands for r.what, d.rast, r.schmeiß.mich.tot, ...

==== Open Issues ====
* will 'g.list rast' show also rasters belonging to time series?
* how to deal with huge file number in a folder? (very long serie often deals with a huge number of maps)
** limitation: how many rasters can a folder contain ('fileno' in /etc/security/limits.conf).
** efficiency: huge number of files will tremendiously slow down each map listing procedures.
* associated color table: only one color table should serve one series (avoid multiple color table for each map)

[[Category:Development]]

Time series development

2006-09-23T08:00:23Z

⚠️Jachym: /* temporal management tools */

This page is born out of discussions in Lausanne. A lot of people seem to be interested in having some standardized, documented format for dealing with time series in GRASS, so that we can deal with data (e.g. climate station, water gauges), link with models, etc., without having to come up with a custom solution each time. This could also lead to modules to help with interpolation to deal with missing values, etc.

There was also discussion of possibly setting up a mailing list. Do we want this?
: I would vote against just-another-mailing list [[User:Neteler|Neteler]] 23:51, 18 September 2006 (CEST)

==== Ideas from MN ====

* each imported raster map get's automatically "registered" in an SQL table
** Table structure:
*** map name
*** map creator (optional)
*** time stamp of import
*** time stamp of map production (optional)
*** time range of validity (optional)
* g.list, g.rename etc. tools have a new "where" parameter do search maps in this table
* g.remove will also remove row from SQL table
* SQL commands can be used for search by time stamps

===== maxi's proposal =====
* what about a table with time series (sort of header of each time series) and another table for each time serie with a list of associated filename and related timestamp?
** time series head table structure:
*** series name
*** creator name
*** timestamp of creation
*** range of validity
*** time step
*** ....
** time serie associated map (table named like the related time serie):
*** timestamp
*** map name
*** timestamp of import

==== Soerens ideas ====

* the temporal gis extension of grass should manage:
** raster, raster3d, vector maps and groups of raster maps (imagery groups)
** the existing timestamps should be used for registration in a temporal database
** the timestamp should be automatically created if a map is created
** all maps can be registered and unregistered in the temporal database
** it should be possible to cretae several temporal tables in the database
*** '''those tables are a new datatype in grass'''
*** the tables should be used for thematic time series
*** maps and groups may be registered in different tables
*** it should be very easy to register and unregister thousands of maps in the database
*** tables will have a description, history, transaction log, ceration time and modification time
*** statistical Informations about the maps (ranges) should be stored in the database
*** if the raster map changes the table should be easily updatable (automatic update implemented in the libs -> if map is closed update the temporal table)
** the temporal database should allow temporal queries for one, several or all tables in the database

===== changes to existing libs/modules =====

* timestamps support for groups must be added
* r.timestamp, r3.timestamp and v.timestamp should be implemented in g.timestamp with group support
* support for temporal region (starttime, endtime, timesteps) in g.region
* g.remove, g.rename and g.copy will need to have access to the temporal database
** if a maps is removed and registered in temporal tables, the table entry should also be removed
** every map keeps the info in which temporal tables it is registered (additional file or info in header)
* g.list should list all temporal databases, not the registered maps (t.info should do this)
* if automatically temporal table update is requested, all the file io libs of raster, raster3d, vector maps and groups have to be extended

===== temporal database =====

* the temporal database in which the maps/groups are registered should provide temporal queries
** select all maps between 20 jan 2002 nad 13 feb 2004
** select all maps with a valid range of 3 months
** select all maps with datum < 13 sep 1999
** select all maps with a valid range of 10 years and a value range between [20:45]
** Postgresql is the only Open Source database which supports such queries and suitable temporal datatypes [[http://www.postgresql.org/files/documentation/books/pghandbuch/html/datatype-datetime.html]] and [[http://www.postgresql.org/files/documentation/books/pghandbuch/html/functions-datetime.html#FUNCTIONS-DATETIME-CURRENT]]
** another way is to implement this functionality in a double linked list

===== timestamps in temporal database =====

* the following timestamps should be created in the database
** a valid timestamp with startime or start- and endtime
** creation time
** modification time

===== temporal management tools =====

* the temporal management should be done by specific commands starting with t.*
* tools for queries, register, unregister und extraction of maps from the temporal database have to be implemented, like t.info, t.register, t.unregister and t.extract ...

Example t.register:

GRASS 6.3.cvs > t.register help

Description:
Register groups, raster, raster3d and vector maps into the temporal database

Keywords:
temporal, time

Usage:
t.register [-s] [tgroup=string[,string,...]]
[trast=string[,string,...]] [trast3d=string[,string,...]]
[tvect=string[,string,...]] [group=string[,string,...]]
[rast=string[,string,...]] [rast3d=string[,string,...]]
[vect=string[,string,...]] [date=timestamp[,timestamp,...]]
[timestep=timestep[,timestep,...]]

Flags:
-s Use the timestep between new maps.

Parameters:
tgroup Temporal group database(s) in which the group(s) should be registered
trast Temporal raster database(s) in which the raster(s) should be registered
trast3d Temporal raster3d database(s) in which the raster3d(s) should be registered
tvect Temporal vector database(s) in which the vector(s) should be registered
group Group(s) to be registered in the temporal group database
rast Raster map(s) to be registered in the temporal raster database
rast3d Raster3d map(s) to be registered in the temporal raster3d database
vect Vector map(s) to be registered in the temporal vector database
date datetime, datetime1/datetime2 for map(s)
timestep timestep between the maps

====== example ======

register 3 raster maps beginning from 20 jan 2001 with a timestep of 3 month in database Landsat
t.register -s trast=Landsat rast=LandsatJan,LandsatApr,LandsatJul date="20 jan 2001" timestep="3 mon"

Table:
1 LandsatJan 20 jan 2001 ...
2 LandsatApr 20 apr 2001 ...
3 LandsatJul 20 jul 2001 ...

===== OO Layer =====

* it should be possible to have data access with spatial-temporal functions:
** value = g4dDataObject->Get4DValue(x, y, z, timestamp) -- for volume maps
** value = g4dDataObject->Get4DValue(x, y, timestamp) -- for raster maps

* based on this functionality a 4d animation tool based on VTK should be implemented

==== Jachym's notes ====
On IRC, we discussed, that time series would be stored in database (PostgreSQL). If data format would be like YYYY-MM-DD-HH-MM-SS, the "database" could be some textfile, which would be sortable via standard 'sort' and g.* modules would not need to speek SQL - KISS, works even on a toaster.

g.list rast should print all raster maps. Raster map belonging to time serie does not stop to be raster map. New data type "times" has to be created, so that modules like g.list, g.remove ... can handle it.

==== Open Issues ====
* will 'g.list rast' show also rasters belonging to time series?
* how to deal with huge file number in a folder? (very long serie often deals with a huge number of maps)
** limitation: how many rasters can a folder contain ('fileno' in /etc/security/limits.conf).
** efficiency: huge number of files will tremendiously slow down each map listing procedures.
* associated color table: only one color table should serve one series (avoid multiple color table for each map)

[[Category:Development]]