[GRASS-dev] Feedback from a FOSSGIS course

Hello all,

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,

a. Undo/Redo facility in GRASS digitisation (or GRASS-QGIS digitisation)

b. Copy-paste facility for copying features during digitisation

c. Facility for displaying Graphs and Charts in QGIS (Like
d.vect.chart in QGIS)

d. Improvements in GRASS GUI (I think no need to mention)

I am attaching a detailed note herewith. Shall I add them as feature requests
in issue tracker?


Sajith VK
Change the rules, or the rules will change you :Kumaranasan

(attachments)

FOSS_GIS_course_Feedback.odt (28.3 KB)

Sajith,

Thanks for the feedback. A few responses below.

On 5/18/07 4:43 AM, “Sajith VK” sajithvk.list@gmail.com wrote:

Hello all,

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,

a. Undo/Redo facility in GRASS digitisation (or GRASS-QGIS digitisation)

b. Copy-paste facility for copying features during digitisation

c. Facility for displaying Graphs and Charts in QGIS (Like
d.vect.chart in QGIS)

This IS in GRASS. d.vect.chart is a GRASS module, not a QGIS module. In QGIS, it is only available as a GRASS plugin. It is on the GUI menu in fact. So it’s odd that you didn’t see it.

d. Improvements in GRASS GUI (I think no need to mention)

Actually this is not very helpful. I looked at the attached text file and it is equally not helpful. TclTk indeed has it’s own “look” that may not be as slick as some. But the usability is a lot more important. Switching from TclTk to wxPython may make it look nicer, but that won’t make it necessarily more usable (though IMHO, it is no less useable than other high-end GIS systems; but we’d like to make it more useable than others).

Which version are you using. The GUI in TclTk has been updated in many ways even since 6.2.0. So it would help to learn some specifics to see if they’ve already been addressed. The fact that you have a lot of crashes makes me suspect that you are working with an early, less stable version. But it may be due to other issues. Under what circumstances go you get a crash?

I am attaching a detailed note herewith. Shall I add them as feature requests
in issue tracker?

Sajith VK
Change the rules, or the rules will change you :Kumaranasan


Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

Hello Michael,
Thanks for your response, (& sorry for the delay in responding back)

c. Facility for displaying Graphs and Charts in QGIS (Like
d.vect.chart in QGIS)

This IS in GRASS. d.vect.chart is a GRASS module, not a QGIS module. In QGIS, it is only available as a GRASS plugin. It is on the GUI menu in fact. So it’s odd that you didn’t see it.

Mis-communication!. I wanted to say that I need the feature of d.vect.chart in QGIS! I have seen this in GRASS and
found it quite useful. But we used printing in QGIS, and we need this facility there!. (Anyway, I think I need to send that to QGIS list than here.)

No problem. This script is very handy. I think someone is working on turning it into a full-fledged C-module. I hope so.

Michael

On 5/22/07 9:39 PM, “Sajith VK” sajithvk.list@gmail.com wrote:

Hello Michael,
Thanks for your response, (& sorry for the delay in responding back)

c. Facility for displaying Graphs and Charts in QGIS (Like
d.vect.chart in QGIS)

This IS in GRASS. d.vect.chart is a GRASS module, not a QGIS module. In QGIS, it is only available as a GRASS plugin. It is on the GUI menu in fact. So it’s odd that you didn’t see it.

Mis-communication!. I wanted to say that I need the feature of d.vect.chart in QGIS! I have seen this in GRASS and
found it quite useful. But we used printing in QGIS, and we need this facility there!. (Anyway, I think I need to send that to QGIS list than here.)


Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

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

Hamish wrote:

> 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.

One option would be to use wxAUI, which allows the user to move panes
around within a window, or detach them into separate top-level
windows.

The wxPython demo includes two AUI demos (AUI_DockingWindowMgr and
AUI_MDI).

> 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.

I disagree with the "default location" idea; there is no sensible
default. You cannot use GRASS without having read at least an
introduction, and trying to trick the user into believing otherwise
wouldn't be doing anyone any favours.

A more reasonable solution would be to have a prominent HELP button on
the startup screen which takes the user to an introduction describing
database, location, mapset, projection, region. This could be
especially prominent (e.g. large, flashing, bold, red text) if $GISRC
doesn't exist or no existing locations are found.

--
Glynn Clements <glynn@gclements.plus.com>

On 23/05/07 08:26, Michael Barton wrote:

No problem. This script is very handy. I think someone is working on turning it into a full-fledged C-module. I hope so.

d.vect.chart _is_ a full-fledged C-module. But QGIS does not use GRASS display modules.

Moritz

Michael

On 5/22/07 9:39 PM, "Sajith VK" <sajithvk.list@gmail.com> wrote:

    Hello Michael,
    Thanks for your response, (& sorry for the delay in responding back)

            c. Facility for displaying Graphs and Charts in QGIS (Like
            d.vect.chart in QGIS)

        This *IS* in GRASS. d.vect.chart is a GRASS module, not a QGIS
        module. In QGIS, it is only available as a GRASS plugin. It is
        on the GUI menu in fact. So it's odd that you didn't see it.

    Mis-communication!. I wanted to say that I need the feature of
    d.vect.chart in QGIS! I have seen this in GRASS and
    found it quite useful. But we used printing in QGIS, and we need
    this facility there!. (Anyway, I think I need to send that to QGIS
    list than here.)

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

------------------------------------------------------------------------

_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev

Would this enable the equivalent of gis.m "detach menu" capacity?

i.e. i would want to detach "Raster->Terrain Analysis" and keep it up for
Terrain related work during a couple of days.

if yes, +1

On Wednesday 23 May 2007 15:23, Glynn Clements wrote:

One option would be to use wxAUI, which allows the user to move panes
around within a window, or detach them into separate top-level
windows.

--
Yann Chemin
Sainte-Anne d'Auray, France

Now I was writing too late at night. I wrote d.vect.chart but thinking
d.vect.thematic.

Michael

On 5/23/07 1:26 AM, "Moritz Lennert" <mlennert@club.worldonline.be> wrote:

d.vect.chart _is_ a full-fledged C-module. But QGIS does not use GRASS
display modules.

Moritz

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

A couple of other clarifications below.

On 5/23/07 12:04 AM, "Hamish" <hamish_nospam@yahoo.com> wrote:

Sajith VK wrote:

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.

Such a module is not simple to build if we make it simple to use.

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.

The GUI georect tool uses i.rectify. AFAIK, 3rd order transformation is
broken (and has been broken for years).

alternatives:
* add GCPs with gdal_translate and rectify with gdalwarp
   (see the i.warp script on the wiki add-ons page)

This was discussed that there was some reason not to avoid this for general
purpose georectification I GRASS. I forget what the reason was, however. It
also means that a full version of GDAL must be present to run GRASS binaries
(not currently a requirement, though it is required to compile GRASS).

* 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?

The GUI georectify tool DOES run v.transform. Yea! There is a button in the
startup screen to let you choose to rectify vectors or rasters.

5. Georectification tool

I found current geo-rectification tool quite user-friendly,

Thanks.

but all
participants complaint it as confusing. Major issue was accidental
errors, especially by forgetting to select next row.

Georectification IS confusing. I automated cursor movement through the GCP
table as much as I dared with TclTK. It was a real bear to get it to move
like it does now. Sorry about not automatically moving to the next row. But
the GCP table is a lot more forgiving than the one in i.points (i.e., you
can actually edit an existing point rather than having to redo it).

(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.

I've heard arguments to leave this in or take it out. It is still not clear
exactly what it does or whether it does what it is supposed to do correctly.
Can anyone check and clarify?

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).

If I can get some help with i.rectify output, it is probably possible to put
a progress bar at the bottom of the GCP mainframe.

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.

And we're building a very nice location wizard in wxgrass to make this even
easier. We may need some enhancements of g.proj to finish it.

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.

GRASS requires you to identify your projection at startup. ArcGIS lets you
start up to a blank screen and lets you worry about projections later. It
also will try to reproject on the fly to overlay maps.

BUT...

The reports I've heard (I haven't used it much for the past few years)
indicate that if you don't get your projections correct at the outset
(raster in a projected form and vectors in latlon) it doesn't do a very
accurate job of overlaying.

So you can be forced to think about projections at the very start (essential
for all GIS work anyway) and get correct results in your working session. OR
you can have an easy startup and risk getting incorrect results unless you
think about projections after you've started.

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").

I agree that knowing what version is important here. I never (or almost
never) get GUI crashes anymore.

One item that might be considered for backporting is changes to gronsole.tcl
I did several weeks back. Due to some other change in GRASS (never
identified what it was), the progress bar functions in gronsole.tcl started
crashing the GUI anytime a module was run that generated progress output but
ran pretty fast. (instantaneous and slow processes didn't seem to cause a
problem) Examples included r.to.vect and r.colors with equalization. This
was insidious and I worked on this with Glynn periodically for several weeks
before finding a fix that seems to work.

Michael

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

This is a good discussion.

On 5/23/07 1:23 AM, "Glynn Clements" <glynn@gclements.plus.com> wrote:

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.

One option would be to use wxAUI, which allows the user to move panes
around within a window, or detach them into separate top-level
windows.

The wxPython demo includes two AUI demos (AUI_DockingWindowMgr and
AUI_MDI).

We're using wxAUI in wxgrass currently. At the moment, it permits tear off
toolbars from a display window (which of course makes *more* frames on the
screen). I was thinking that it might be a good way to create a cartography
system (drop and resize various displays inside a main display), but haven't
got beyond that preliminary concept stage.

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.

I disagree with the "default location" idea; there is no sensible
default. You cannot use GRASS without having read at least an
introduction, and trying to trick the user into believing otherwise
wouldn't be doing anyone any favours.

A more reasonable solution would be to have a prominent HELP button on
the startup screen which takes the user to an introduction describing
database, location, mapset, projection, region. This could be
especially prominent (e.g. large, flashing, bold, red text) if $GISRC
doesn't exist or no existing locations are found.

This is a nice idea. We also need an error trap for cases where someone has
deleted or renamed a location that was the last one used.

Michael

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

Michael Barton wrote:

>> 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.
>
> One option would be to use wxAUI, which allows the user to move panes
> around within a window, or detach them into separate top-level
> windows.
>
> The wxPython demo includes two AUI demos (AUI_DockingWindowMgr and
> AUI_MDI).

We're using wxAUI in wxgrass currently. At the moment, it permits tear off
toolbars from a display window (which of course makes *more* frames on the
screen). I was thinking that it might be a good way to create a cartography
system (drop and resize various displays inside a main display), but haven't
got beyond that preliminary concept stage.

I was thinking more in terms of the actual display canvases, i.e.
being able to have the whole of wxgui as a single window, with the
layer list and canvases as panes. If you have enough screen area, a
single window is easier to manage than multiple windows.

--
Glynn Clements <glynn@gclements.plus.com>

Glynn Clements wrote:

I was thinking more in terms of the actual display canvases, i.e.
being able to have the whole of wxgui as a single window, with the
layer list and canvases as panes. If you have enough screen area, a
single window is easier to manage than multiple windows.

In general, yes please.

Cautionary: if you remember the old version of Star Office 5, you'll
recall that this concept can be taken too far. (it wanted to be full
screen, had a ms windows style start button and taskbar, etc). yuk.

Hamish

Michael:

The GUI georect tool uses i.rectify. AFAIK, 3rd order transformation
is broken (and has been broken for years).

http://intevation.de/rt/webrt?serial_num=3166

And AFAIK, it is broken in gdalwarp as well. (derived from the same
code)

The GUI georectify tool DOES run v.transform. Yea! There is a button
in the startup screen to let you choose to rectify vectors or rasters.

Oh, then great.

>> 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.

I've heard arguments to leave this in or take it out. It is still not
clear exactly what it does or whether it does what it is supposed to
do correctly. Can anyone check and clarify?

Right, it's confusing, buggy, or both. It is best to work through this
in a formal bug report. (is this covered by bugs #3052 and #3296 ?)
  http://intevation.de/rt/webrt?serial_num=3052
  http://intevation.de/rt/webrt?serial_num=3296

If I can get some help with i.rectify output, it is probably possible
to put a progress bar at the bottom of the GCP mainframe.

That would be nice.

rectify.c uses G_percent(), so it is "just" a matter of using the same
progress code as the module GUIs use.

GRASS requires you to identify your projection at startup. ArcGIS lets
you start up to a blank screen and lets you worry about projections
later. It also will try to reproject on the fly to overlay maps.

The reports I've heard (I haven't used it much for the past few years)
indicate that if you don't get your projections correct at the outset
(raster in a projected form and vectors in latlon) it doesn't do a
very accurate job of overlaying.

From my observations of folks using Arc, this usually means quickly

resorting to pulling the rubber sheet until it looks "good enough",
rather than figuring out the projection and datum terms properly (if at
all).

One item that might be considered for backporting is changes to
gronsole.tcl I did several weeks back. Due to some other change in
GRASS (never identified what it was), the progress bar functions in
gronsole.tcl started crashing the GUI anytime a module was run that
generated progress output but ran pretty fast. (instantaneous and slow
processes didn't seem to cause a problem) Examples included r.to.vect
and r.colors with equalization. This was insidious and I worked on
this with Glynn periodically for several weeks before finding a fix
that seems to work.

Specific file names and revisions please. Or link to grass-commit email,
http://grass.itc.it/pipermail/grass-commit/

I don't like backporting a bunch of changes and vaguely hoping that
something in them will fix an intermittent error.

Hamish

On 5/23/07 8:23 PM, "Hamish" <hamish_nospam@yahoo.com> wrote:

Specific file names and revisions please. Or link to grass-commit email,
http://grass.itc.it/pipermail/grass-commit/

I don't like backporting a bunch of changes and vaguely hoping that
something in them will fix an intermittent error.

Here you go. These are bonafide bug fixes

http://grass.itc.it/pipermail/grass-commit/2007-April/028427.html
gronsole.tcl 29 Apr 2007 20:47:35 -0000 1.12

http://grass.itc.it/pipermail/grass-commit/2007-May/028815.html
gronsole.tcl 15 May 2007 06:53:17 -0000 1.13

Michael

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

On 5/23/07 8:23 PM, "Hamish" <hamish_nospam@yahoo.com> wrote:

I've heard arguments to leave this in or take it out. It is still not
clear exactly what it does or whether it does what it is supposed to
do correctly. Can anyone check and clarify?

Right, it's confusing, buggy, or both. It is best to work through this
in a formal bug report. (is this covered by bugs #3052 and #3296 ?)
  http://intevation.de/rt/webrt?serial_num=3052
  http://intevation.de/rt/webrt?serial_num=3296

I don't know what the bug in i.rectify is for 3rd order polynomial
rectification, so I can't say whether or not these are reporting it or not.
I suppose that it could even be fixed and the information about a problem is
incorrect. Hopefully someone knows more about this.

Michael

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

Michael Barton wrote:

>> I've heard arguments to leave this in or take it out. It is still
>> not clear exactly what it does or whether it does what it is
>> supposed to do correctly. Can anyone check and clarify?

Hamish:

> Right, it's confusing, buggy, or both. It is best to work through
> this in a formal bug report. (is this covered by bugs #3052 and
> #3296 ?)
> http://intevation.de/rt/webrt?serial_num=3052
> http://intevation.de/rt/webrt?serial_num=3296
>

Michael:

I don't know what the bug in i.rectify is for 3rd order polynomial
rectification, so I can't say whether or not these are reporting it or
not. I suppose that it could even be fixed and the information about a
problem is incorrect. Hopefully someone knows more about this.

3rd order bug was listed further up in the email, #3166

http://intevation.de/rt/webrt?serial_num=3166

And AFAIK, it is broken in gdalwarp as well. (derived from the same
code)

AFAIR, the 3rd order bug makes the -c bug worse, but it is not the sole
cause. (?)

Hamish

That looks like it.

Michael

On 5/23/07 10:57 PM, "Hamish" <hamish_nospam@yahoo.com> wrote:

Michael Barton wrote:

I've heard arguments to leave this in or take it out. It is still
not clear exactly what it does or whether it does what it is
supposed to do correctly. Can anyone check and clarify?

Hamish:

Right, it's confusing, buggy, or both. It is best to work through
this in a formal bug report. (is this covered by bugs #3052 and
#3296 ?)
  http://intevation.de/rt/webrt?serial_num=3052
  http://intevation.de/rt/webrt?serial_num=3296

Michael:

I don't know what the bug in i.rectify is for 3rd order polynomial
rectification, so I can't say whether or not these are reporting it or
not. I suppose that it could even be fixed and the information about a
problem is incorrect. Hopefully someone knows more about this.

3rd order bug was listed further up in the email, #3166

http://intevation.de/rt/webrt?serial_num=3166

And AFAIK, it is broken in gdalwarp as well. (derived from the same
code)

AFAIR, the 3rd order bug makes the -c bug worse, but it is not the sole
cause. (?)

Hamish

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton