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,
1. GRASS GUI
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
https://intevation.de/rt/webrt?serial_num=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
of.
all (old,open) v.digit wishes:
https://intevation.de/rt/webrt?q_status=open&q_queue=grass&q_subject=v.digit
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.
alternatives:
* 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.
v.transform?
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
not
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,
Hamish