GRASS-Wiki - User contributions [en]

GRASS SoC Ideas 2008

2008-03-12T21:07:41Z

⚠️Paul K: Add line of sight idea from last year

= About =
This is the GRASS page for [http://wiki.osgeo.org/index.php/Google_Summer_of_Code Google Summer of Code] 2008. Here we will list project ideas and and other information related to the GRASS GSoC projects.

= Timeline =
* http://wolf.bergenheim.net/tmp/check.png Community bonding time (getting to know the students)
* Work Begins (May 28th)
* Midterm evaluation (July 14th)
* Pencils down! (August 11th)

= Required Steps =

* List ideas http://wolf.bergenheim.net/tmp/check.png
* Assign Mentors to Ideas
* Notify OSGeo
* Process Student Applications. Deadline XXX
* April 14th: Accepted Students Announced
* SVN branches and access for students
** Create a Wiki page for each accepted project, to be used as a progress reporting tool
* Coding begins...
* Students and mentors: Complete the Mid-term survey.
* Final commit and packaging for Google.

= Ideas =

Here are some ideas you can base your application on
===wxPython===
These project ideas have to do with the new GUI of GRASS

====3D Visualization====
3-D visualization in GRASS is currently achieved using the ageing "Nviz" tool. Nviz is a hybrid Tcl/TK and C application, which makes extending and improving it a very complicated task. GRASS is moving to a new wxPython-based GUI and the task of 3-D visualization needs to be integrated with this new GUI.

This is potentially a very large task, but in 3 months we would expect to have a workable demo (but release quality code ;)) to display surface(s) in 2D and smoothly transfer the view into 3D. GUI needs to be consistent with the new wxPython GUI for GRASS.

NVIZ is itself a frontend to the underlying OpenGL gsurf library (part of GRASS) which reads GRASS datasets and interfaces with OpenGL at a C API level. It is anticipated that this approach will be retained with the new GUI. Thus one approach to the task might be to "clean and tidy" this library and develop a modular interface to it, i.e. to develop individual GRASS modules to access the 3-D visualization functionality directly without having to use NVIZ. This would make the 3-D visualization capabilities of GRASS "scriptable" and possible to run in a modular way from any GUI toolkit. The development of a wxPython frontend would then be a simple exercise in user interface design and consistent with the way the GUI interfaces with other GRASS modules (other than v.digit, which is also a hybrid C application).

Other approaches may also be possible. You should keep in mind that the code has to be very well documented (even insanely well) to facilitate better expandability.

'''Willing to Mentor:'''Wolf Bergenheim, Michael Barton, Paul Kelly

* [http://trac.osgeo.org/grass/browser/grass/trunk/lib/ogsf/README Description of the capabilities of the GRASS OpenGL gsurf library]
* [http://trac.osgeo.org/grass/browser/grass/trunk/lib/ogsf/TODO Bugs and issues in the gsurf library which may need to be resolved]

====Color management====
GRASS has good color management features, but lacks a good UI to mange colors.

Your job would be to extend the wxPython GUI to
# Create a color and interval editor tool which should be able to create files which are compatible with r.reclass, r.colors and friends.
# A similar tool for vector data would also be very nice, which would simply store the colors in the GRASSRGB column of the attribute table.
# For added fun a C library that implements things such as "natural breaks" and others which could then also be used by r.reclass, v.reclass and possibly other modules that need to break number ranges into discrete classes.

'''Willing to Mentor:'''Wolf Bergenheim, Michael Barton

====SQL====
GRASS has excellent SQL support, however many people who are using GRASS are not SQL gurus.

Your job would be to create a SQL query builder to help build SQL queries. Additional cool features are welcome!

'''Willing to Mentor:'''Wolf Bergenheim, Michael Barton

====Kriging====
Currently GRASS has no native support for Kriging. Kriging is done either with the R package or with the GStat package. Both are command driven and thus a GUI could be created to control the program. R could be maybe called directly or via a script to do the variograms etc.

Your job would be to grate a GUI (in wxPython) that can:
# Do Kriging based on gstat.
#* Create and edit GStat command files
#* Call gstat to do variogram analysis
#* Call gstat to do the actual Kriging.
# Do Kriging based or R
#* Create and edit R scripts
#* Call R to do variogram analysis. For efficiency the R environment should be done
#* Call R to do the actual Kriging. This includes importing the result back to GRASS.

'''Willing to Mentor:'''Wolf Bergenheim, Michael Barton

==== Cartography ====
GRASS is mainly focused on Analysis, but it also has good map making tools. These tools lack a good GUI.

Your job would be to create a GUI for the ps.map tool which creates postscript maps. This would be a first step towards a graphical cartography tool for GRASS

'''Willing to Mentor:''' Michael Barton, Hamish Bowman

==== v.what ====
Your job would be to make v.what take xy coordinates (single xy or line of xy's with a buffer distance to find stuff within that buffer distance of the coordinates; set of at least 3 xy's to ID a polygon and find the stuff within it).

'''Willing to Mentor:''' Michael Barton

=== Raster ===
These projects involve the GRASS raster library.

====r.external====
GRASS can link to external vectors (as well as importing them) vi the GDAL OGR library. On the raster side on is unfortunately limited to importing raster maps.

Your job would be to create this r.external too for GRASS.
* See the [http://freegis.org/cgi-bin/viewcvs.cgi/grass/gips/gip-0002.txt?rev=HEAD&content-type=text/vnd.viewcvs-markup GRASS raster "live links" proposal] for more information.

This project will be done in cooperation with GDAL.

'''Willing to Mentor:''' Wolf Bergenheim (GRASS), Frank Warmerdam (GDAL)

====Improved Line of Sight Analysis====

Line of sight determination is a very important analysis to have available in a GIS. The GRASS module that currently performs this function, r.los, has a number of limitations, including being very slow to run and unable to handle large high-resolution datasets. The task: write a new r.los module based on the paper 'A Fast Algorithm for Approximate Viewshed Computation' published in 'Photogrammetric Engineering & Remote Sensing' July 2003:
http://www.asprs.org/publications/pers/2003journal/july/2003_jul_767-774.pdf
Incorporate features of r.cva (http://www.ucl.ac.uk/~tcrnmar/GIS/r.cva.html), which cannot currently be incorporated in GRASS for licensing reasons, and extend with other functionality as appropriate.

The work will involve familiarisation with the GRASS raster library for reading and writing maps, the GRASS vector library for reading analysis location sites. It is expected that the GRASS directed graph library will also be useful for implementing many features of the algorithm (specifically, determining the crossing points and distances between the cells).

'''Willing to Mentor:''' Paul Kelly

==== Raster Database ====
In GRASS vector maps can be connected to a database table as an attribute table. Many commercial GIS packages also allow this for raster maps.

Your job would be to implement this connection.

'''Willing to Mentor:''' Wolf Bergenheim

==== Raster Objects ====
Implement an equivalent of eCognition's object-based classification (in contrast to pixel-based classification)

=== Vector ===
These ideas relate to the Vector library of GRASS.

==== v.buffer and v.parallel ====
These two modules are broken and need to be reimplemented.

'''Willing to Mentor:''' Wolf Bergenheim

==== Implement file based spatial index ====
Read "Keep topology and spatial index in file instead of in memory" in [http://freegis.org/cgi-bin/viewcvs.cgi/grass6/doc/vector/TODO?rev=HEAD&content-type=text/vnd.viewcvs-markup Radim's Vector ToDo]
'''Willing to Mentor:''' Wolf Bergenheim

==== v.voronoi / v.delauny ====
These modules need to be reimplemented as they are quite old an sub-optimal. There are many good algorithms that can be used.

==== v.generalize take two ====
Last year Daniel Bundala created the v.generalize module, and implemented many line generalization algorithms.

This year we'd like to expand the module with implementing algorithms to do the following methods (as defined by McMAster)
* merging
* exaggeration
* collapse
* point aggregation

'''Willing to Mentor:''' Wolf Bergenheim

==== v.overlay ====
Extend v.overlay to allow all types of overlay operations for all types of vector (i.e. also points and lines)

'''Willing to Mentor:''' Wolf Bergenheim

==== Uniforming vector modules ====
GRASS has over 100 vector modules (many of which have multiple functions), and many of these modules very different input parameters, and lach where= and cats= parameters.

Your job would be to clean up these modules and that way ease the learning curve of GRASS

'''Willing to Mentor:''' Wolf Bergenheim

= Guidelines for Students =

How do you maximize your chances of getting picked? First read the [http://code.google.com/p/google-summer-of-code/wiki/AdviceforStudents Google SoC FAQ]. Then talk to us about your idea. Try emailing the mentor directly, or come and talk to us in IRC (#grass).

= Accepted Ideas =

GRASS SoC Ideas 2008

2008-03-12T20:58:53Z

⚠️Paul K: /* 3D Visualization */

= About =
This is the GRASS page for [http://wiki.osgeo.org/index.php/Google_Summer_of_Code Google Summer of Code] 2008. Here we will list project ideas and and other information related to the GRASS GSoC projects.

= Timeline =
* http://wolf.bergenheim.net/tmp/check.png Community bonding time (getting to know the students)
* Work Begins (May 28th)
* Midterm evaluation (July 14th)
* Pencils down! (August 11th)

= Required Steps =

* List ideas http://wolf.bergenheim.net/tmp/check.png
* Assign Mentors to Ideas
* Notify OSGeo
* Process Student Applications. Deadline XXX
* April 14th: Accepted Students Announced
* SVN branches and access for students
** Create a Wiki page for each accepted project, to be used as a progress reporting tool
* Coding begins...
* Students and mentors: Complete the Mid-term survey.
* Final commit and packaging for Google.

= Ideas =

Here are some ideas you can base your application on
===wxPython===
These project ideas have to do with the new GUI of GRASS

====3D Visualization====
3-D visualization in GRASS is currently achieved using the ageing "Nviz" tool. Nviz is a hybrid Tcl/TK and C application, which makes extending and improving it a very complicated task. GRASS is moving to a new wxPython-based GUI and the task of 3-D visualization needs to be integrated with this new GUI.

This is potentially a very large task, but in 3 months we would expect to have a workable demo (but release quality code ;)) to display surface(s) in 2D and smoothly transfer the view into 3D. GUI needs to be consistent with the new wxPython GUI for GRASS.

NVIZ is itself a frontend to the underlying OpenGL gsurf library (part of GRASS) which reads GRASS datasets and interfaces with OpenGL at a C API level. It is anticipated that this approach will be retained with the new GUI. Thus one approach to the task might be to "clean and tidy" this library and develop a modular interface to it, i.e. to develop individual GRASS modules to access the 3-D visualization functionality directly without having to use NVIZ. This would make the 3-D visualization capabilities of GRASS "scriptable" and possible to run in a modular way from any GUI toolkit. The development of a wxPython frontend would then be a simple exercise in user interface design and consistent with the way the GUI interfaces with other GRASS modules (other than v.digit, which is also a hybrid C application).

Other approaches may also be possible. You should keep in mind that the code has to be very well documented (even insanely well) to facilitate better expandability.

'''Willing to Mentor:'''Wolf Bergenheim, Michael Barton, Paul Kelly

* [http://trac.osgeo.org/grass/browser/grass/trunk/lib/ogsf/README Description of the capabilities of the GRASS OpenGL gsurf library]
* [http://trac.osgeo.org/grass/browser/grass/trunk/lib/ogsf/TODO Bugs and issues in the gsurf library which may need to be resolved]

====Color management====
GRASS has good color management features, but lacks a good UI to mange colors.

Your job would be to extend the wxPython GUI to
# Create a color and interval editor tool which should be able to create files which are compatible with r.reclass, r.colors and friends.
# A similar tool for vector data would also be very nice, which would simply store the colors in the GRASSRGB column of the attribute table.
# For added fun a C library that implements things such as "natural breaks" and others which could then also be used by r.reclass, v.reclass and possibly other modules that need to break number ranges into discrete classes.

'''Willing to Mentor:'''Wolf Bergenheim, Michael Barton

====SQL====
GRASS has excellent SQL support, however many people who are using GRASS are not SQL gurus.

Your job would be to create a SQL query builder to help build SQL queries. Additional cool features are welcome!

'''Willing to Mentor:'''Wolf Bergenheim, Michael Barton

====Kriging====
Currently GRASS has no native support for Kriging. Kriging is done either with the R package or with the GStat package. Both are command driven and thus a GUI could be created to control the program. R could be maybe called directly or via a script to do the variograms etc.

Your job would be to grate a GUI (in wxPython) that can:
# Do Kriging based on gstat.
#* Create and edit GStat command files
#* Call gstat to do variogram analysis
#* Call gstat to do the actual Kriging.
# Do Kriging based or R
#* Create and edit R scripts
#* Call R to do variogram analysis. For efficiency the R environment should be done
#* Call R to do the actual Kriging. This includes importing the result back to GRASS.

'''Willing to Mentor:'''Wolf Bergenheim, Michael Barton

==== Cartography ====
GRASS is mainly focused on Analysis, but it also has good map making tools. These tools lack a good GUI.

Your job would be to create a GUI for the ps.map tool which creates postscript maps. This would be a first step towards a graphical cartography tool for GRASS

'''Willing to Mentor:''' Michael Barton, Hamish Bowman

==== v.what ====
Your job would be to make v.what take xy coordinates (single xy or line of xy's with a buffer distance to find stuff within that buffer distance of the coordinates; set of at least 3 xy's to ID a polygon and find the stuff within it).

'''Willing to Mentor:''' Michael Barton

=== Raster ===
These projects involve the GRASS raster library.

====r.external====
GRASS can link to external vectors (as well as importing them) vi the GDAL OGR library. On the raster side on is unfortunately limited to importing raster maps.

Your job would be to create this r.external too for GRASS.
* See the [http://freegis.org/cgi-bin/viewcvs.cgi/grass/gips/gip-0002.txt?rev=HEAD&content-type=text/vnd.viewcvs-markup GRASS raster "live links" proposal] for more information.

This project will be done in cooperation with GDAL.

'''Willing to Mentor:''' Wolf Bergenheim (GRASS), Frank Warmerdam (GDAL)

==== Raster Database ====
In GRASS vector maps can be connected to a database table as an attribute table. Many commercial GIS packages also allow this for raster maps.

Your job would be to implement this connection.

'''Willing to Mentor:''' Wolf Bergenheim

==== Raster Objects ====
Implement an equivalent of eCognition's object-based classification (in contrast to pixel-based classification)

=== Vector ===
These ideas relate to the Vector library of GRASS.

==== v.buffer and v.parallel ====
These two modules are broken and need to be reimplemented.

'''Willing to Mentor:''' Wolf Bergenheim

==== Implement file based spatial index ====
Read "Keep topology and spatial index in file instead of in memory" in [http://freegis.org/cgi-bin/viewcvs.cgi/grass6/doc/vector/TODO?rev=HEAD&content-type=text/vnd.viewcvs-markup Radim's Vector ToDo]
'''Willing to Mentor:''' Wolf Bergenheim

==== v.voronoi / v.delauny ====
These modules need to be reimplemented as they are quite old an sub-optimal. There are many good algorithms that can be used.

==== v.generalize take two ====
Last year Daniel Bundala created the v.generalize module, and implemented many line generalization algorithms.

This year we'd like to expand the module with implementing algorithms to do the following methods (as defined by McMAster)
* merging
* exaggeration
* collapse
* point aggregation

'''Willing to Mentor:''' Wolf Bergenheim

==== v.overlay ====
Extend v.overlay to allow all types of overlay operations for all types of vector (i.e. also points and lines)

'''Willing to Mentor:''' Wolf Bergenheim

==== Uniforming vector modules ====
GRASS has over 100 vector modules (many of which have multiple functions), and many of these modules very different input parameters, and lach where= and cats= parameters.

Your job would be to clean up these modules and that way ease the learning curve of GRASS

'''Willing to Mentor:''' Wolf Bergenheim

= Guidelines for Students =

How do you maximize your chances of getting picked? First read the [http://code.google.com/p/google-summer-of-code/wiki/AdviceforStudents Google SoC FAQ]. Then talk to us about your idea. Try emailing the mentor directly, or come and talk to us in IRC (#grass).

= Accepted Ideas =

Module command line parser

2008-02-02T01:47:03Z

⚠️Paul K: /* GUI window parser */

GRASS's command line parser is used by just about all modules to check input values, create help pages and GUIs. With the help of the ''g.parser'' module your shell or Python scripts can automatically generate help page templates and fully functional GUI windows. (This is a frontend for the G_parser() function in the C API; see the programmer's manual if you are interested in that)

* see the [http://grass.ibiblio.org/grass63/manuals/html63_user/g.parser.html g.parser help page]

== Command line parser ==

* Options take user input (name or number) and of the style:
'''option='''''answer''
* flags are on/off switches and of the style
'''-f'''

* Run time flags and options can be mixed in any order. Special options to display help and GUI templates should appear on their own.
* Options may be tested for correct numerical value and range. For example testing if the numerical answer falls within 0-100 percent.
* Options may be limited to a discrete set of answers. This results in a pulldown menu in the GUI and a strict answer from the command line.

* The first option= listed by --help may be skiped, for example:
d.rast elevation.dem

* Option names may be shortened up to the point where they collide. Thus shortening option names in a module with color= and column= options would require at minimum colo= and colu=.
for example:
'''input=''' → '''in=''' and '''output=''' → '''out='''

* Flags may be combined behind a single "-". for example:
'''-r -f -t''' is the same as '''-rtf'''

* All modules can take the command line options --ui to force a GUI window, --overwrite to allow/force overwritting of maps and files, --quiet to make modules less noisy, --verbose to make modules more noisy, and --script to generate a shell script wrapper template.

* --quiet, --verbose, and --overwrite may be abbreviated as --q, --v, --o.

* --help or just 'help' by itself on the command line prints concise module command line option help. This help page will also be printed if there was an error parsing the command options.

== GUI window parser ==

* If a module is called with no options or flags specified then a GUI window is launched, unless the environment variable GRASS_UI_TERM is set (to any value), in which case the command-line interactive parser is launched.
* If a module is called with options and flags specified, but with the --ui flag, then a GUI window is started with those options and flags already set to the given values. (useful for interactive scripts)

* Auto-created from <tt>--tcltk</tt> or <tt>--interface-description</tt> (for XML) command line options.
* Options may be grouped into tabs by the parser settings
* Quotes to protect "special characters" from the shell are not needed here. Quotes needed to denote SQL 'strings' are still needed.

== Interactive text based UI parser ==

If the environment variable <tt>GRASS_UI_TERM</tt> is set to any value, then an interactive question/answer text based UI is launched instead of the graphical UI window.

== Help page template ==

* Auto-created with the <tt>--html-description</tt> command line option.

== Exceptions ==

Due to technical reasons some modules do not use the standard parser. These include:
* r.mapcalc
* g.parser
* the photo.* modules

[[Category: FAQ]]

WinGRASS 6 Current Status

2007-07-02T09:35:52Z

⚠️Paul K: Note about gdal-config based on feedback from Benjamin Ducke

__TOC__

This page describes the current status of winGRASS development. Precompiled winGRASS/Cygwin packages are available [http://grass.itc.it/grass62/binary/mswindows/ here], native winGRASS packages are [http://moritz.homelinux.org/grass/wingrass/ here].

== Compilation ==

(based on work from Paul Kelly - [http://grass.itc.it/pipermail/grass-dev/2006-December/027998.html his message])

Mostly on compiling the accompanying libraries GRASS absolutely needs:
XDR, Zlib, libpng, PROJ.4, GDAL.

They are available in a gzipped tar file in case anybody would like to get started quickly: http://www.stjohnspoint.co.uk/grass/ (get wingrass-extralibs.tar.gz).
In this case you would just need Msys, Mingw with bison and flex.
The prefix where you untar that file you will need to supply to the GRASS configure as:

--with-includes=prefix --with-libs=prefix

Before compilation, you need to set your path in msys in order to
add the path to the lib/ and bin/ directories of Paul's tarball before
compiling. You might also need to edit the first few lines of the gdal-config script in the bin/ directory, to reflect the path where it is actually installed.

You also have to erase $(MANDIR) $(MANPAGES) from line 13 of man/Makefile, i.e. 'default: $(MANDIR) $(MANPAGES)' -> 'default:'.

If you get an error such as 'cannot open file `/msys/share/bison/m4sugar/m4sugar.m4': No such file or directory', one solution is to move around the msys bison installation a bit, so that m4sugar.m4 is available in the indicated path.

A working configure line is:
./configure --prefix=c:/grass --bindir=c:/grass/bin \
--with-includes=/c/grass/forgrass/include \
--with-libs=/c/grass/forgrass/lib --with-cxx --without-jpeg --without-tiff \
--without-postgres --with-opengl=windows --without-fftw --without-x \
--enable-x11=no --enable-shared=yes --with-tcltk-includes=/c/tcl/include \
--with-tcltk-libs=/c/tcl/bin

After compiling you should copy libxdr.dll, libproj.dll, libpng.dll, libgdal-1.dll and libz.dll.1.2.3 into the GRASS lib directory and all the GDAL and PROJ .exe files in the bin directory into the GRASS bin directory, and then you have a more or less self-contained GRASS distribution.

You can also install Activestate Tcl/Tk 8.4.13 (in c:\tcl).

== What is missing? ==

=== Vector ===
* <strike>v.digit: implement as pure tcl</strike> (Glynn)
* <strike>Vector-DB connection</strike>:
** This has been solved for now by compiling XDRlib as a static library
** M Lennert: I had hoped that Radim's patch for dbmi_client (http://grass.itc.it/pipermail/grass5/2006-December/028118.html) might solve the issue I've had with the db protocol errors, but apparently this is not the case. When I push the 'show the attribute columns' in a vector panel, I still get
<pre>
*******
Displaying column types/names for database connection of layer 1:
dbmi: Protocol error
Cannot open table <streams>
********

and a 'v.db.select' on the same map gives me:

********
'vector/streams' was found in more mapsets (also found in user1).
dbmi: Protocol error

Cannot open select cursor
*********
</pre>
* P Kelly: I can confirm similar problems. I tried to import a Shapefile with v.in.ogr. I went quite deep into debugging it and got nowhere at all, although I should have taken better notes. I did confirm though that compiling the library with -mwindows as Radim suggested on the list made no difference either. I think trying with a different database, PostgreSQL perhaps is the next big step to debugging this. See if the behaviour is the same as with dbf and if not we can isolate it a bit more.
* Moritz: [http://grass.itc.it/pipermail/grass-dev/2007-February/029149.html followup on DB issue]: ... using db.select as the test case, the error seems to happen around a call to xdr_int() in lib/db/dbmi_base/xdrstring.c....
* Moritz: [http://grass.itc.it/pipermail/grass-dev/2007-February/029367.html followup 2 on DB issue]
* Moritz: [http://grass.itc.it/pipermail/grass-dev/2007-February/029373.html followup 3 on DB issue]
* Paul: [http://grass.itc.it/pipermail/grass-dev/2007-February/029376.html followup 4 on DB issue]
* Glynn: [http://grass.itc.it/pipermail/grass-dev/2007-February/029378.html followup 5 on DB issue]
* Glynn: [http://grass.itc.it/pipermail/grass-dev/2007-February/029380.html followup 6 on DB issue]

=== Display ===
* Display drivers: socket
** Use gis.m instead of monitors.
** Make gis.m Output window more like xterm. No need to hit Run.
** Is there any way that the Map Display in gis.m can interact with console commands? IPC? File Alteration Monitor?

=== Imagery ===
* i.class: SIGALRM, SIGTSTP (are these signals important?)
* wait() in:
** i.ortho.photo/photo.2image: wait()
** i.ortho.photo/photo.2target: wait()
** i.points: wait()
** i.vpoints: wait()
** Note: also in lib/gis/popen.c and lib/gis/system.c (use those implementations?)

=== Raster ===
* r.terraflow: getrusage()
** check this octave patch [http://osdir.com/ml/gnu.octave.maintainers/2006-03/msg00083.html email thread] (check thread msgs)

== Known problems ==

* metacharacter escape in "sh -c '$cmd'"
* modules not working: r.proj (v.proj too?), r.surf.rst, v.neighbors, v.kernel, r.cost
* Cannot open Help pages.
* Have to add c:\mingw\bin to PATH on some systems.
** You should have typed c:/mingw instead of c:\mingw when asked by the MinGW installer.
* Have to type "exit" in the console to save ~/.grassrc file. Then, close gis.m to finish the session.
* A previous installation of grass under cygwin is likely to cause problems with WinGrass. Follow the directions to remove cygwin at http://cygwin.com/faq/faq-nochunks.html#faq.setup.uninstall-all

The following items cannot be fixed in the near future:
* Cannot display a thematic layer.
** d.vect.thematic requires PNG driver, which is not available in winGRASS.
** can't read "_data(.gronsole.gronsole,4,donecmd)": no such element in array error
** Aqua TclTk solution: http://intevation.de/rt/webrt?serial_num=5096&display=History

== TclTk issues ==

* cannot run shell scripts: only .com, .exe, .bat
** sh -c '$cmd'
* var=val style argument is not valid for batch files: equal sign is a separator like a space. http://support.microsoft.com/?kbid=71247 http://www.gatago.com/alt/msdos/batch/17358926.html
** <strike>need .exe wrapper for shell scripts? grass-xterm-wrapper.exe</strike>
** We now have .bat wrappers for each shell script, which run the shell specified by the GRASS_SH environment variable and pass the full path to the script to it
* file command returns bad code (catch is needed): http://sources.redhat.com/ml/insight/2003-q1/msg00079.html
** catch {file copy}
** catch {file delete}
** catch {file rename -force} does not work. Delete old file first: catch {file delete}; catch {file rename}
* <strike>file redirection (>@stdout, 2>@stderr) does not work: http://wiki.tcl.tk/672</strike>
** Worked around by using a small C-program (grocat.exe) to combine stdout and stderr
** exec a batch file doing redirection (>&2, 2>&1)
* no -permissions file attributes
** catch {file attributes -permissions}

== Other libraries ==

GDAL
* lib/gis/OBJ.*/fmode.o is needed for any GRASS related modules.
* modified ltmain.sh to install binary files from wrapper scripts.

[[Category: Development]]

WinGRASS 6 Current Status

2007-05-24T19:49:43Z

⚠️Paul K: /* TclTk issues */

__TOC__

This page describes the current status of winGRASS development. Precompiled winGRASS/Cygwin packages are available [http://grass.itc.it/grass62/binary/mswindows/ here], native winGRASS packages are [http://moritz.homelinux.org/grass/wingrass/ here].

== Compilation ==

(based on work from Paul Kelly - [http://grass.itc.it/pipermail/grass-dev/2006-December/027998.html his message])

Mostly on compiling the accompanying libraries GRASS absolutely needs:
XDR, Zlib, libpng, PROJ.4, GDAL.

They are available in a gzipped tar file in case anybody would like to get started quickly: http://www.stjohnspoint.co.uk/grass/ (get wingrass-extralibs.tar.gz).
In this case you would just need Msys, Mingw with bison and flex.
The prefix where you untar that file you will need to supply to the GRASS configure as:

--with-includes=prefix --with-libs=prefix

Before compilation, you need to set your path in msys in order to
add the path to the lib/ and bin/ directories of Paul's tarball before
compiling.

You also have to erase $(MANDIR) $(MANPAGES) from line 13 of man/Makefile, i.e. 'default: $(MANDIR) $(MANPAGES)' -> 'default:'.

If you get an error such as 'cannot open file `/msys/share/bison/m4sugar/m4sugar.m4': No such file or directory', one solution is to move around the msys bison installation a bit, so that m4sugar.m4 is available in the indicated path.

A working configure line is:
./configure --prefix=c:/grass --bindir=c:/grass/bin \
--with-includes=/c/grass/forgrass/include \
--with-libs=/c/grass/forgrass/lib --with-cxx --without-jpeg --without-tiff \
--without-postgres --with-opengl=windows --without-fftw --without-x \
--enable-x11=no --enable-shared=yes --with-tcltk-includes=/c/tcl/include \
--with-tcltk-libs=/c/tcl/bin

After compiling you should copy libxdr.dll, libproj.dll, libpng.dll, libgdal-1.dll and libz.dll.1.2.3 into the GRASS lib directory and all the GDAL and PROJ .exe files in the bin directory into the GRASS bin directory, and then you have a more or less self-contained GRASS distribution.

You can also install Activestate Tcl/Tk 8.4.13 (in c:\tcl).

== What is missing? ==

=== Vector ===
* <strike>v.digit: implement as pure tcl</strike> (Glynn)
* <strike>Vector-DB connection</strike>:
** This has been solved for now by compiling XDRlib as a static library
** M Lennert: I had hoped that Radim's patch for dbmi_client (http://grass.itc.it/pipermail/grass5/2006-December/028118.html) might solve the issue I've had with the db protocol errors, but apparently this is not the case. When I push the 'show the attribute columns' in a vector panel, I still get
<pre>
*******
Displaying column types/names for database connection of layer 1:
dbmi: Protocol error
Cannot open table <streams>
********

and a 'v.db.select' on the same map gives me:

********
'vector/streams' was found in more mapsets (also found in user1).
dbmi: Protocol error

Cannot open select cursor
*********
</pre>
* P Kelly: I can confirm similar problems. I tried to import a Shapefile with v.in.ogr. I went quite deep into debugging it and got nowhere at all, although I should have taken better notes. I did confirm though that compiling the library with -mwindows as Radim suggested on the list made no difference either. I think trying with a different database, PostgreSQL perhaps is the next big step to debugging this. See if the behaviour is the same as with dbf and if not we can isolate it a bit more.
* Moritz: [http://grass.itc.it/pipermail/grass-dev/2007-February/029149.html followup on DB issue]: ... using db.select as the test case, the error seems to happen around a call to xdr_int() in lib/db/dbmi_base/xdrstring.c....
* Moritz: [http://grass.itc.it/pipermail/grass-dev/2007-February/029367.html followup 2 on DB issue]
* Moritz: [http://grass.itc.it/pipermail/grass-dev/2007-February/029373.html followup 3 on DB issue]
* Paul: [http://grass.itc.it/pipermail/grass-dev/2007-February/029376.html followup 4 on DB issue]
* Glynn: [http://grass.itc.it/pipermail/grass-dev/2007-February/029378.html followup 5 on DB issue]
* Glynn: [http://grass.itc.it/pipermail/grass-dev/2007-February/029380.html followup 6 on DB issue]

=== Display ===
* Display drivers: socket
** Use gis.m instead of monitors.
** Make gis.m Output window more like xterm. No need to hit Run.
** Is there any way that the Map Display in gis.m can interact with console commands? IPC? File Alteration Monitor?

=== Imagery ===
* i.class: SIGALRM, SIGTSTP (are these signals important?)
* wait() in:
** i.ortho.photo/photo.2image: wait()
** i.ortho.photo/photo.2target: wait()
** i.points: wait()
** i.vpoints: wait()
** Note: also in lib/gis/popen.c and lib/gis/system.c (use those implementations?)

=== Raster ===
* r.terraflow: getrusage()

== Known problems ==

* metacharacter escape in "sh -c '$cmd'"
* modules not working: r.proj (v.proj too?), r.surf.rst, v.neighbors, v.kernel, r.cost
* Cannot open Help pages.
* Have to add c:\mingw\bin to PATH on some systems.
** You should have typed c:/mingw instead of c:\mingw when asked by the MinGW installer.
* Have to type "exit" in the console to save ~/.grassrc file. Then, close gis.m to finish the session.
* A previous installation of grass under cygwin is likely to cause problems with WinGrass. Follow the directions to remove cygwin at http://cygwin.com/faq/faq-nochunks.html#faq.setup.uninstall-all

The following items cannot be fixed in the near future:
* Cannot display a thematic layer.
** d.vect.thematic requires PNG driver, which is not available in winGRASS.
** can't read "_data(.gronsole.gronsole,4,donecmd)": no such element in array error
** Aqua TclTk solution: http://intevation.de/rt/webrt?serial_num=5096&display=History

== TclTk issues ==

* cannot run shell scripts: only .com, .exe, .bat
** sh -c '$cmd'
* var=val style argument is not valid for batch files: equal sign is a separator like a space. http://support.microsoft.com/?kbid=71247 http://www.gatago.com/alt/msdos/batch/17358926.html
** <strike>need .exe wrapper for shell scripts? grass-xterm-wrapper.exe</strike>
** We now have .bat wrappers for each shell script, which run the shell specified by the GRASS_SH environment variable and pass the full path to the script to it
* file command returns bad code (catch is needed): http://sources.redhat.com/ml/insight/2003-q1/msg00079.html
** catch {file copy}
** catch {file delete}
** catch {file rename -force} does not work. Delete old file first: catch {file delete}; catch {file rename}
* <strike>file redirection (>@stdout, 2>@stderr) does not work: http://wiki.tcl.tk/672</strike>
** Worked around by using a small C-program (grocat.exe) to combine stdout and stderr
** exec a batch file doing redirection (>&2, 2>&1)
* no -permissions file attributes
** catch {file attributes -permissions}

== Other libraries ==

GDAL
* lib/gis/OBJ.*/fmode.o is needed for any GRASS related modules.
* modified ltmain.sh to install binary files from wrapper scripts.

[[Category: Development]]

WinGRASS 6 Current Status

2007-05-24T19:47:28Z

⚠️Paul K: /* Vector */

__TOC__

This page describes the current status of winGRASS development. Precompiled winGRASS/Cygwin packages are available [http://grass.itc.it/grass62/binary/mswindows/ here], native winGRASS packages are [http://moritz.homelinux.org/grass/wingrass/ here].

== Compilation ==

(based on work from Paul Kelly - [http://grass.itc.it/pipermail/grass-dev/2006-December/027998.html his message])

Mostly on compiling the accompanying libraries GRASS absolutely needs:
XDR, Zlib, libpng, PROJ.4, GDAL.

They are available in a gzipped tar file in case anybody would like to get started quickly: http://www.stjohnspoint.co.uk/grass/ (get wingrass-extralibs.tar.gz).
In this case you would just need Msys, Mingw with bison and flex.
The prefix where you untar that file you will need to supply to the GRASS configure as:

--with-includes=prefix --with-libs=prefix

Before compilation, you need to set your path in msys in order to
add the path to the lib/ and bin/ directories of Paul's tarball before
compiling.

You also have to erase $(MANDIR) $(MANPAGES) from line 13 of man/Makefile, i.e. 'default: $(MANDIR) $(MANPAGES)' -> 'default:'.

If you get an error such as 'cannot open file `/msys/share/bison/m4sugar/m4sugar.m4': No such file or directory', one solution is to move around the msys bison installation a bit, so that m4sugar.m4 is available in the indicated path.

A working configure line is:
./configure --prefix=c:/grass --bindir=c:/grass/bin \
--with-includes=/c/grass/forgrass/include \
--with-libs=/c/grass/forgrass/lib --with-cxx --without-jpeg --without-tiff \
--without-postgres --with-opengl=windows --without-fftw --without-x \
--enable-x11=no --enable-shared=yes --with-tcltk-includes=/c/tcl/include \
--with-tcltk-libs=/c/tcl/bin

After compiling you should copy libxdr.dll, libproj.dll, libpng.dll, libgdal-1.dll and libz.dll.1.2.3 into the GRASS lib directory and all the GDAL and PROJ .exe files in the bin directory into the GRASS bin directory, and then you have a more or less self-contained GRASS distribution.

You can also install Activestate Tcl/Tk 8.4.13 (in c:\tcl).

== What is missing? ==

=== Vector ===
* <strike>v.digit: implement as pure tcl</strike> (Glynn)
* <strike>Vector-DB connection</strike>:
** This has been solved for now by compiling XDRlib as a static library
** M Lennert: I had hoped that Radim's patch for dbmi_client (http://grass.itc.it/pipermail/grass5/2006-December/028118.html) might solve the issue I've had with the db protocol errors, but apparently this is not the case. When I push the 'show the attribute columns' in a vector panel, I still get
<pre>
*******
Displaying column types/names for database connection of layer 1:
dbmi: Protocol error
Cannot open table <streams>
********

and a 'v.db.select' on the same map gives me:

********
'vector/streams' was found in more mapsets (also found in user1).
dbmi: Protocol error

Cannot open select cursor
*********
</pre>
* P Kelly: I can confirm similar problems. I tried to import a Shapefile with v.in.ogr. I went quite deep into debugging it and got nowhere at all, although I should have taken better notes. I did confirm though that compiling the library with -mwindows as Radim suggested on the list made no difference either. I think trying with a different database, PostgreSQL perhaps is the next big step to debugging this. See if the behaviour is the same as with dbf and if not we can isolate it a bit more.
* Moritz: [http://grass.itc.it/pipermail/grass-dev/2007-February/029149.html followup on DB issue]: ... using db.select as the test case, the error seems to happen around a call to xdr_int() in lib/db/dbmi_base/xdrstring.c....
* Moritz: [http://grass.itc.it/pipermail/grass-dev/2007-February/029367.html followup 2 on DB issue]
* Moritz: [http://grass.itc.it/pipermail/grass-dev/2007-February/029373.html followup 3 on DB issue]
* Paul: [http://grass.itc.it/pipermail/grass-dev/2007-February/029376.html followup 4 on DB issue]
* Glynn: [http://grass.itc.it/pipermail/grass-dev/2007-February/029378.html followup 5 on DB issue]
* Glynn: [http://grass.itc.it/pipermail/grass-dev/2007-February/029380.html followup 6 on DB issue]

=== Display ===
* Display drivers: socket
** Use gis.m instead of monitors.
** Make gis.m Output window more like xterm. No need to hit Run.
** Is there any way that the Map Display in gis.m can interact with console commands? IPC? File Alteration Monitor?

=== Imagery ===
* i.class: SIGALRM, SIGTSTP (are these signals important?)
* wait() in:
** i.ortho.photo/photo.2image: wait()
** i.ortho.photo/photo.2target: wait()
** i.points: wait()
** i.vpoints: wait()
** Note: also in lib/gis/popen.c and lib/gis/system.c (use those implementations?)

=== Raster ===
* r.terraflow: getrusage()

== Known problems ==

* metacharacter escape in "sh -c '$cmd'"
* modules not working: r.proj (v.proj too?), r.surf.rst, v.neighbors, v.kernel, r.cost
* Cannot open Help pages.
* Have to add c:\mingw\bin to PATH on some systems.
** You should have typed c:/mingw instead of c:\mingw when asked by the MinGW installer.
* Have to type "exit" in the console to save ~/.grassrc file. Then, close gis.m to finish the session.
* A previous installation of grass under cygwin is likely to cause problems with WinGrass. Follow the directions to remove cygwin at http://cygwin.com/faq/faq-nochunks.html#faq.setup.uninstall-all

The following items cannot be fixed in the near future:
* Cannot display a thematic layer.
** d.vect.thematic requires PNG driver, which is not available in winGRASS.
** can't read "_data(.gronsole.gronsole,4,donecmd)": no such element in array error
** Aqua TclTk solution: http://intevation.de/rt/webrt?serial_num=5096&display=History

== TclTk issues ==

* cannot run shell scripts: only .com, .exe, .bat
** sh -c '$cmd'
* var=val style argument is not valid for batch files: equal sign is a separator like a space. http://support.microsoft.com/?kbid=71247 http://www.gatago.com/alt/msdos/batch/17358926.html
** need .exe wrapper for shell scripts? grass-xterm-wrapper.exe
* file command returns bad code (catch is needed): http://sources.redhat.com/ml/insight/2003-q1/msg00079.html
** catch {file copy}
** catch {file delete}
** catch {file rename -force} does not work. Delete old file first: catch {file delete}; catch {file rename}
* file redirection (>@stdout, 2>@stderr) does not work: http://wiki.tcl.tk/672
** exec a batch file doing redirection (>&2, 2>&1)
* no -permissions file attributes
** catch {file attributes -permissions}

== Other libraries ==

GDAL
* lib/gis/OBJ.*/fmode.o is needed for any GRASS related modules.
* modified ltmain.sh to install binary files from wrapper scripts.

[[Category: Development]]

GRASS SoC Ideas 2007

2007-03-12T11:23:58Z

⚠️Paul K: paragraphs?? wiki editing is new to me...

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

* Improved Line of Sight Analysis in GRASS

Line of sight determination is a very important analysis to have available in a GIS. The GRASS module that currently performs this function, r.los, has a number of limitations, including being very slow to run and unable to handle large high-resolution datasets. The task: write a new r.los module based on the paper 'A Fast Algorithm for Approximate Viewshed Computation' published in 'Photogrammetric Engineering & Remote Sensing' July 2003:
http://www.asprs.org/publications/pers/2003journal/july/2003_jul_767-774.pdf
Incorporate features of r.cva (http://www.ucl.ac.uk/~tcrnmar/GIS/r.cva.html), which cannot currently be incorporated in GRASS for licensing reasons, and extend with other functionality as appropriate.

The work will involve familiarisation with the GRASS raster library for reading and writing maps, the GRASS vector library for reading analysis location sites. It is expected that the GRASS directed graph library will also be useful for implementing many features of the algorithm (specifically, determining the crossing points and distances between the cells).

Some hints on what's involved in GRASS programming are available here: http://freegis.org/cgi-bin/viewcvs.cgi/*checkout*/grass6/SUBMITTING

Potential Mentor: Paul Kelly

* 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: [http://freegis.org/cgi-bin/viewcvs.cgi/grass/gips/gip-0002.txt?rev=HEAD&content-type=text/vnd.viewcvs-markup GRASS raster "live links" proposal]
* integrate OGR as part of GRASS vector library
:''please expand, I don't understand what you mean'' -HB

== Potential Mentors ==

* Paul Kelly (for line of sight project)

=== See also ===

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

[[Category:Development]]

GRASS SoC Ideas 2007

2007-03-12T11:23:16Z

⚠️Paul K: hints on GRASS programming

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

* Improved Line of Sight Analysis in GRASS

Line of sight determination is a very important analysis to have available in a GIS. The GRASS module that currently performs this function, r.los, has a number of limitations, including being very slow to run and unable to handle large high-resolution datasets. The task: write a new r.los module based on the paper 'A Fast Algorithm for Approximate Viewshed Computation' published in 'Photogrammetric Engineering & Remote Sensing' July 2003:
http://www.asprs.org/publications/pers/2003journal/july/2003_jul_767-774.pdf
Incorporate features of r.cva (http://www.ucl.ac.uk/~tcrnmar/GIS/r.cva.html), which cannot currently be incorporated in GRASS for licensing reasons, and extend with other functionality as appropriate.
The work will involve familiarisation with the GRASS raster library for reading and writing maps, the GRASS vector library for reading analysis location sites. It is expected that the GRASS directed graph library will also be useful for implementing many features of the algorithm (specifically, determining the crossing points and distances between the cells).
Some hints on what's involved in GRASS programming are available here: http://freegis.org/cgi-bin/viewcvs.cgi/*checkout*/grass6/SUBMITTING

Potential Mentor: Paul Kelly

* 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: [http://freegis.org/cgi-bin/viewcvs.cgi/grass/gips/gip-0002.txt?rev=HEAD&content-type=text/vnd.viewcvs-markup GRASS raster "live links" proposal]
* integrate OGR as part of GRASS vector library
:''please expand, I don't understand what you mean'' -HB

== Potential Mentors ==

* Paul Kelly (for line of sight project)

=== See also ===

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

[[Category:Development]]

GRASS SoC Ideas 2007

2007-03-12T10:54:26Z

⚠️Paul K:

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

* Improved Line of Sight Analysis in GRASS

Line of sight determination is a very important analysis to have available in a GIS. The GRASS module that currently performs this function, r.los, has a number of limitations, including being very slow to run and unable to handle large high-resolution datasets. The task: write a new r.los module based on the paper 'A Fast Algorithm for Approximate Viewshed Computation' published in 'Photogrammetric Engineering & Remote Sensing' July 2003:
http://www.asprs.org/publications/pers/2003journal/july/2003_jul_767-774.pdf
Incorporate features of r.cva (http://www.ucl.ac.uk/~tcrnmar/GIS/r.cva.html), which cannot currently be incorporated in GRASS for licensing reasons, and extend with other functionality as appropriate.
The work will involve familiarisation with the GRASS raster library for reading and writing maps, the GRASS vector library for reading analysis location sites. It is expected that the GRASS directed graph library will also be useful for implementing many features of the algorithm (specifically, determining the crossing points and distances between the cells).

Potential Mentor: Paul Kelly

* 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: [http://freegis.org/cgi-bin/viewcvs.cgi/grass/gips/gip-0002.txt?rev=HEAD&content-type=text/vnd.viewcvs-markup GRASS raster "live links" proposal]
* integrate OGR as part of GRASS vector library
:''please expand, I don't understand what you mean'' -HB

== Potential Mentors ==

* Paul Kelly (for line of sight project)

=== See also ===

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

[[Category:Development]]