[GRASS-dev] Feedback from a FOSSGIS course

[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