[GRASS-dev] GUI region setting

[Michael Barton]

Hi Paul,


On 6/16/07 1:12 AM, "Paul Kelly" <paul-grass at stjohnspoint.co.uk> wrote:

> Hello Michael
> 
> On Fri, 15 Jun 2007, Michael Barton wrote:
> 
>> On 6/14/07 5:17 PM, "Paul Kelly" <paul-grass at stjohnspoint.co.uk> wrote:
>> 
>>> 
>>> I've mentioned this before but I really think there should be a GUI region
>>> setting widget with all the functionality of the old interactive
>>> curses-based g.region. Someone was complaining recently that there should
>>> be a quick resolution adjust facility in the GUI monitor displays - I
>>> think that would be a hack but a button to access the interactive region
>>> setting widget, with further buttons there to save the region as the
>>> active display region or the mapset working region etc. would be very
>>> useful IMHO.
>> 
>> Exactly such a location setting wizard is about 80% completed for the
>> wxPython gui.
> 
> OK that's good that it's there but I think it's utility, if implemented in
> the way I'm vaguely imagining, should extend far beyond one-time use when
> creating a new location and it could be something that would regularly be
> used all the time - for interactively managing the display regions and the
> computational region.

The wizard is for setting locations. Other tools are for changing region
settings--which operate within locations and mapsets. If these functions are
to be merged, it seems to me that it would require some fundamental changes
in the way GRASS works.

One very useful tool would be one that could allow a user to change the
working environment among different locations. There is a tool to do this
currently (I think it uses g.gisenv internally), but it doesn't work very
well due to internal issues in GRASS.


> 
>> Problem: g.proj won't accept g.setproj style values that can pulled from the
>> projection, transform, and other files in $GISBASE/etc,
> 
> I'm not sure exactly what you're asking for here. When creating a new
> location with the projection values input manually/interactively (i.e. a
> custom projection - you're not taking it from any prepared source such as
> a georeferenced file or an EPSG number) you don't really need to use much
> of the functionality of g.proj. Glynn split all the projection parameters
> that g.setproj out into separate text files (they used to be hard-coded in
> C) for the explicit purpose of making them also available to the GUI to
> prompt the user and form a valid projection definition. Probably the best
> thing to do with this would then be to pass it (as a PROJ.4 string) to
> g.proj and use it to create the location.

Maybe we just need some help in formatting then. Currently, there are text
files that have all the projection parameters used by g.setproj and the
wizard can parse them. The question is what to do with this once the user
has selected all the desired values. Are the values pulled from the text
file sufficient in and of themselves to create a valid PROJ.4 string?

> 
> There is a slight problem with this though in that the way g.setproj was
> written (and the text files of possible projection parameters have
> inherited this) doesn't properly allow for the way some projections can
> be described with complicated combinations of parameters, i.e. it isn't
> just as simple as saying which parameters are optional or not. Some day
> someone needs to read the PROJ.4 documentation in detail and re-implement
> this file. I used to think it's functionality might be included in one of
> the official PROJ distributions but as time goes on I see that as
> increasingly unlikely, even though it is a common wish.

Can't this be handled in the same way as is done now with the EPSG file
option? That is, have it run a test with g.proj and see if it needs
additional transformation parameters and present them to the user to select.

> 
>> no will it take extents.
> 
> g.proj doesn't need to set the final region extents. g.region can do that.
> What I am saying is you can run g.proj first and it will do a best a job
> as it can of writing out a default region - then you can read that back in
> with g.region and present it to the user for verification, before a final
> writing back using the new g.region -s flag.

We were trying to mirror the functionality of g.setproj, where you can
optionally set extents when you set the location. If this won't work with
g.proj, then we'll have to make it a 2-step process. BTW, what do you mean
that g.proj will try to create a default region? Does this mean that we
don't need to bother with extent setting at location-creation time?

> 
> 
> Form a PROJ.4 string from the projection values and pass it to g.proj
> using the proj4= option? I'm not really sure what you're asking here.
> 

It looks like it boils down to being able to create a valid PROJ4 string
from the values in the text files used by g.setproj.

Michael



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

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