Hello Michael
On Fri, 15 Jun 2007, Michael Barton wrote:
On 6/14/07 5:17 PM, "Paul Kelly" <[EMAIL PROTECTED]> 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
_______________________________________________
grass-dev mailing list
[email protected]
http://grass.itc.it/mailman/listinfo/grass-dev
