[GRASS-dev] Feedback from a FOSSGIS course

[Michael Barton]

A couple of other clarifications below.




On 5/23/07 12:04 AM, "Hamish" <hamish_nospam at 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