[GRASS-dev] GUI region setting

[Paul Kelly]

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.

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

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.

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

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

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

Paul