[GRASS-dev] GUI region setting

[Michael Barton]

Hi Paul


On 6/27/07 3:53 AM, "Paul Kelly" <paul-grass at stjohnspoint.co.uk> wrote:

> On Mon, 25 Jun 2007, Michael Barton wrote:
> 
>> On 6/16/07 1:12 AM, "Paul Kelly" <paul-grass at stjohnspoint.co.uk> wrote:
>> 
> [...]
>>> 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.
> 
> I'm not sure what you mean. A region-setting GUI widget, if separated from
> the location creation wizard, only has to be a front-end to g.region and
> could equally well be used in the PERMANENT mapset immediately after
> setting up a new location to set the default region, or any time
> thereafter in any other mapset to set the normal working region.
> 
> It could be extended to also be a front-end to the way the GUI stores the
> display regions internally, and be a useful tool for viewing and changing
> both the display and computational regions.

How would this differ from the gui that is launched with g.region now?


> 
>>>> 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?
> 
> Yes, I think so. If they're not, we can look at improving the PROJ.4
> string to GRASS projection definition code in g.proj and lib/proj. That
> would be the quick & easy solution. However, it's worth getting this right
> and it could be that there's a better way of doing this than creating a
> PROJ string and passing it to g.proj, as that relies on GDAL to do some
> processing when we don't really need that - we could create the GRASS
> projection files directly and then we would have more control over support
> for obscure things or things that are broken in GDAL.

I should be ready to bug you about this in a few days. I finally got the
wizard to actually work last night with the EPSG option. I'll do the
georeferenced file option next. Then I'm ready to craft a PROJ.4 string out
of the projection values.

Can g.proj make an xy location?

> 
> HOWEVER, as I said the way g.setproj currently works and the way those
> parameter files (that you say the location creation wizard parses) are
> structured does not, as far as I can see, adequately describe all the
> possible combinations of parameters each projection can take*. And we
> really need to sort this out at this stage and retire g.setproj rather
> than introduce subtly broken functionality into the new location creation
> wizard for the sake of backwards compatibility.
> 
> *In particular, it's not just a matter of listing whether parameters are
> optional or not. Some parameters are dependent on others, e.g. they might
> only be meaningful if another parameter has also been specified, or they
> might be optional or not depending on whether another parameter has been
> specified.

Some of this is built in in the relationships between the projection file
and datum transform files. You'll have

> 
>>> 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.
> 
> It would still need the information on the parameter inter-dependencies of
> each projection specified in a clear way. That's the bulk of the work.
> PROJ doesn't provide this in a machine readable format, only human
> readable. And anyway once the information is there it would be much
> simpler to implement it in the GUI IMHO. But it actually needs a bit of
> real programming.
> 
>>>> 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
> 
> No, g.setproj does not create locations and never has done. All it does is
> create PROJ_INFO and PROJ_UNITS files and updates the projection and zone
> codes in DEFAULT_WIND if applicable. Setting the initial region and all
> the directory creation stuff etc. is done by $(ETC)/set_data. It just
> offloads the creation of PROJ_INFO/PROJ_UNITS to g.setproj, by calling it
> with system(). Whoever's working on this will really need to understand
> exactly what $(ETC)/set_data does in order to duplicate it correctly.
> 
>> g.proj, then we'll have to make it a 2-step process.
> 
> That's what I've been saying all along... :) But it should be transparent
> to the user.

For the first attempt to get the location wizard up and running, I've
decided not to bother with setting extents. Just get the locations made.

Thinking about it, I'm not sure if g.region can be used to set the extents
at the time a location is made. It probably needs to run within a functional
location, but this is not the case in the location-creation stage when GRASS
is still starting up.

We could just make a WIND file manually of course, but I'd rather use a
GRASS function if possible to make GUI maintenance easier.

> 
>> 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?
> 
> Exactly! There've been numerous discussions about this on the list, in
> particular about how g.proj creates locations 1 cell square if there is no
> initial source for the region information. But if creating a location from
> a geo-referenced file then it will use the extents in there for the
> initial region. But in either case that needs to be verified by the user,
> and that can be done by using a generic region-setting front-end to
> g.region as I described above. As far as I know that is the same approach
> that $(ETC)/set_data takes.

This is OK for using a georeferenced file and EPSG (I guess using the same
underlying algorithm). But it won't apply for locations made other ways
(i.e., picking projection etc).

There are some convenience functions built into the wizard currently,
including setting extents from a countries file or from a user-selected
georeferenced file. However, they requrire cs2cs and maybe some other
utilities that we may not be able to guarantee are available by default on
all platforms (e.g., on Windows versions of PROJ.4? They weren't in my path
until I specifically set them to be).

Also, how can I find out what the automatically created extents ARE in order
to present them to a user for verification? g.region -p doesn't print
extents. 

> 
>>> 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.
> 
> Yes that's definitely the easiest solution. BUT IMHO it relies too much on
> GDAL for parsing the PROJ string and as this is an inherent part of GRASS
> (creating a new location at start up) it should rely on GDAL as little as
> possible. Stuff like the plural of the units name isn't supported by GDAL,
> for example. So in the long-run it's probably best to put more effort into
> doing the work in the GRASS GUI. I'd like to have a look at doing this,
> but don't know when I'll have time as am a bit busy with non-GRASS things
> at the minute.

I'll send you more questions in awhile and hope that you can give me some
feedback. 

Thanks much for this useful info to get started with.

Michael

__________________________________________
Michael Barton, Professor of Anthropology
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