[GRASS-dev] GUI region setting

[Paul Kelly]

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.

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

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.

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

> And g.setproj won't run non-interactively.

As I said above, all the projection parameters are now extracted into text 
files so the GUI can access them.

> So we can (and have) replicate everything *except* actually using the values
> to create a location.
>
> Can either g.proj be extended to accept g.setproj-like values or g.setproj
> get an option to run non-interactively?

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.

Paul