[GRASS-dev] Feedback from a FOSSGIS course

Hamish hamish_nospam at yahoo.com
Wed May 23 03:04:55 EDT 2007

Sajith VK wrote:
> I have been using FOSS GIS tools, especially GRASS, for last few
> years. We are trying to promote the use of FOSS GIS over here. As part
> of this, we have conducted a course on "FOSS GIS", conducted by my
> organisation, Kerala State Electronics Development Corporation
> (KELTRON), for a transport research and development organisation named
> NATPAC over here. This mail is to share the experience, and some
> feedbacks and suggestions we got.
> It was a seven day course, conducted in two batches, having around 10
> participants per batch. The group included a few AutoCAD digitisation
> people, a few ArcGIS experts and some scientists. In general, FOSS GIS
> has been accepted by the all participants. Almost all requirements of
> the people could easily be done in FOSS GIS, and some are much better
> than proprietary counter parts (GRASS vector architecture, etc). They
> will be using FOSS GIS for some of their projects.
> We used Ubuntu GNU/Linux as operating system. A custom CD covering
> major FOSS GIS tools was created to support the course. Major
> suggestions from the participants are,

> Shall I add them as feature requests in issue tracker?

Yes. One problem per request please.

> I am attaching a detailed note herewith.

Copied below in plain text,

> Peoples felt that GRASS GUI is least user-friendly and is confusing.
> Major issues where the tcl/tk style, and many windows. So majority of
> things, including digitisation was introduced through QGIS. I hope
> that upcoming Wx-python GUI shall solve this issue.

I too find it ugly and a pain to have 4-6 windows cluttering the
desktop. IIUC in the new wx GUI the output window is a tab on the GIS
Manager window, and if the command prompt window is minimized, then
there is usually just the display and control panel to deal with.

> 2. GRASS QGIS plug-in
> Using GRASS digitisation through QGIS, also made some confusions, as
> all QGIS documentation speaks only on its native digitisation.

Issue for QGIS.
> 3. Digitisation
> Two significant issues were pointed out,
> a. Lack of Undo/Redo, especially as accidental deletions was common
> initially

This is v.digit wish #1171

> b. Lack of copy-paste of features. v.extract + v.patch can do this,
> but simple copying a feature, and pasting in another layer shall be
> far better. Just copying feature without attributes is sufficient.

Yes, this has been requested before, but no formal wish report I know

all (old,open) v.digit wishes:

> 4. Raster Alignment
> GRASS has a proper mechanism for gap free combining of scanned maps,

r.patch, r.series, r.fillnulls

> by geo-rectifying. However, this requires GCPs distributed all over
> the maps. in practical cases (for example, in the map these people
> brought) sufficient overlapping may not be there, and only two or
> three points may be identifiable. Transforming the second image based
> on these two or three points should be possible. ArcGIS has this
> feature.
> I have written a small module for the same, which is based on a
> /trick/. What we need is that instead of polynomial
> transformation, we need transformation with lesser parameters (only
> four parameters, scale sx=sy, translation in x, translation in y and
> rotation). Such a simple module is essential in GRASS.

rectification order is limited by number of points; from the i.rectify
man page:

"The number of control points required for a selected order of
transformation (represented by n) is ((n + 1) * (n + 2) / 2)"

So for 1st order:  (2*3)/2 = 3 points needed.

At least for i.points+i.rectify. I don't have much experience with the
new GUI georect tool.

* add GCPs with gdal_translate and rectify with gdalwarp
   (see the i.warp script on the wiki add-ons page)
* compose a .tfw "World File" before r.in.gdal import.
* reset bounds with r.region after import.
* import as points, then use v.transform or v.proj, then v.to.rast

> The same thing is applicable for vector also.

It would be great if the georect GUI could calc transforms parms from 
GCPs and run v.transform?

> 5. Georectification tool
> I found current geo-rectification tool quite user-friendly, but all
> participants complaint it as confusing. Major issue was accidental
> errors, especially by forgetting to select next row.

(I take it this is in regards the TclTk GUI georectification tool and
i.points, i.vpoints)

> The i.rectify uses arguments as -ca. In all cases we tested,
> geo-rectified images was to be in a different region. Hence it failed
> always. When I removed -c from the argument, it works, as does not
> apply current region settings.

Please file this as a bug.

> The tool seems to be /hang/ed once rectification start. GUI
> resumes operation once i.rectify is complete.

Probably a red "Please Wait..." message and greying out the button
controls ("-state disabled"?) could help make it more obvious what's
happening? (avoids users hitting the "Go" button multiple times; they
need some indication (beyond `top`) that it's actually running).

> 6. Projection
> Making proj string is a little bit complex. People should be allowed
> to select projection, ellipsoid, datum et directly than asking to
> construct a proj string (+ellps=..... +proj=.... etc).

use g.setproj for that (from an xterm).
> Creating new locations using projection values is quite complex for
> new persons.

Michael's new EPSG GUI code picker should make this a lot easier. This
has been backported to the 6.2 line and will be in 6.2.2.

> 7. GRASS startup
> First time use of GRASS is confusing, as we need to a location to
> start with. I suggest to copy the spearfish location and use it as a
> base. It is better if GRASS provides a demo location by defult, even
> without any data.

Package download size. Probably the startup text could be more helpful
explaining where to get data and what to do with it.

> 8. GRASS map printing
> It was almost impossible to introduce concept of ps.map to the people

d.out.file in GRASS 6.3 makes PostScript output easier (new PS driver);
there are some plans for a GUI ps.map frontend for the new wx GUI, and
already a prototype, but this is for the future. I still believe in
ps.map as the best way to make high quality hardcopies from GRASS, even
though it is not point-and-click simple.

tip: give them a simple working template to start with, and then let
them tweak that.

> 9. QGIS print settings
> Excellent, but confuses in the beginning. Also need feature to
> represent some data in the form of charts etc. (The feature of
> d.vect.chart in GRASS is needed in QGIS)

Issue for QGIS.
> 10. Not so stable
> GRASS GUI (gis.m) crashes very frequently (may be an issue only in the
> version I used)

which version? when does it crash? 6.2.2 will be more robust. (better
use of catch statements; small errors don't bring down the entrire GUI
with "exit 1").

thanks for the feedback,


More information about the grass-dev mailing list