Hi Paul
On 6/27/07 3:53 AM, "Paul Kelly" <paul-grass@stjohnspoint.co.uk> wrote:
On Mon, 25 Jun 2007, Michael Barton wrote:
On 6/16/07 1:12 AM, "Paul Kelly" <paul-grass@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
But it should be transparent to the user.