[GRASS-dev] Re: GRASS startup window patches

[Michael Barton]

Paul,

I did a bit of testing along with some code clean up to see that gis_set.tcl
is actually doing.


On 1/7/07 4:00 AM, "Paul Kelly" <paul-grass at stjohnspoint.co.uk> wrote:

> If we can design a GUI widget to force the user to verify/set the initial
> region after creating a new location, then this could be presented after
> the 3 different methods of creating a new location. And then we could
> simplify the "using projection values" button to running g.setproj in a
> pop-up xterm Window and do the region setting through the GUI afterwards.

I now don't think that this will work. It looks like g.setproj will only
work in already existing projected locations. That is, it won't work in xy
locations and won't work unless there is already a valid PROJ_INFO file. So
we're stuck with set_data for use in the GRASS startup.

> 
>> I don't mind committing this, but it seems like we ought to do a bit more
>> first. What about having gis_set.tcl do the running of g.setproj and then
>> return to the refreshed startup? This seems like a better, more consistent
>> way to go.
> 
> I have committed Maris's patch now, with this extra modification. The
> thing is, you still need to press Ctrl-C to exit out of it after creating
> the new location. And that isn't obvious. But, like I said, once we can do
> the initial region setting in the GUI, then we can simplify that.

I wonder if some modifications to set_data might make this easier.
Currently, it ONLY runs in interactive mode. What would it take to make
set_data also run in non-interactive mode? Here is a suggestion if this is
feasible.

Maybe make g.setdata based on the set_data module in $GISBASE/etc.

Inputs:
    database=[string; required]
    location=[string; required]
    mapset=[string (default=PERMANENT); optional]
    projclass=[xy, latlon, utm, other; required (or could have default)]
    loc_desc=[string; optional]
    datum=[string; optional (i.e., for xy)]
    datumtrans=[string; required (default=1)]
    ellipsoid=[string; optional or required? Default?]
    zone=[integer; optional]
    hemisphere=[n, s; optional]
    north=[float (accept DD:MM:SS for latlon?); required, optional, def?]
    south=[float (accept DD:MM:SS for latlon?); required, optional, def?]
    east=[float (accept DD:MM:SS for latlon?); required, optional, def?]
    west=[float (accept DD:MM:SS for latlon?); required, optional, def?]
    ewres=[float; required, optional, def?]
    nsres=[float; required, optional, def?]

Outputs:
    -d list available datums for selected projclass (projclass must be
defined)

    -e list available ellipsoids for selected datum (datum must be defined)

    -t (list available transforms for selected datums (datum must be
defined)

With something like this, a GUI wrapper could be built pretty easily.

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