[GRASS-dev] Re: question about g.proj
Paul Kelly
paul-grass at stjohnspoint.co.uk
Fri Feb 23 14:45:02 EST 2007
Hello Michael
On Thu, 22 Feb 2007, Michael Barton wrote:
> Paul,
>
> I forgot to ask you. After your fixes to g.proj, does it still need to have
> a valid location/mapset somewhere in order to create a new location? That
> is, do I still need to create and destroy a fake location in epsg_option.tcl
> for cases of first time use?
No, it should be fine without all that now. In fact when we changed the
call to G_gisinit() to G_no_gisinit() around Christmas that was most of
the work done. The only other thing was a dependency on having a valid
mapset of G_tempfile(), but that was only relevant to theinteractive datum
prompting and it is now gone unless you specifically request it. So here's
a few thoughts on what I think gis_set.tcl or a future start-up GUI should
do:
Doesn't need to use a special temporary GISRC file. Init.sh will
automatically create one before running gis_set.tcl. Presumably it is
already read when the database location field in gis_set.tcl is
automatically filled out currently?
Only the GISDBASE line needs to be valid. LOCATION_NAME and MAPSET need to
be there, but they do not need to contain valid data just yet. But as I
said, Init.sh takes care of this automatically before starting
gis_set.tcl.
What does need to be done however, is if the user manually edits the
default database path, then this needs to be written out to the file
pointed to by GISRC *before* g.proj is run, so that g.proj will pick up
the correct database directory that it is going to write the new location
to. I'm not sure if it currently does this or not. I suspect not, but I
could be wrong.
Then my plan for how g.proj should be used is that it should be first be
run with the -c flag and location= option and datumtrans=-1. If there is
no choice of datum parameters to be made then the location will be created
straight away, nothing written to stdout and there'll be no problem.
If on the other hand there is a choice of datum parameters to be made,
then this will be written to stdout, and you can catch that and let the
user select for a second run. I think the dialog for selecting parameters
should also allow for datumtrans=0 (i.e. leave the datum parameters
unspecified and just use the default for that datum). See some of the
earlier e-mails between Hamish and I for a description of how that's
different from datumtrans=1.
And then after getting information from the user run it again as it is
currently.
Then, the new location and mapset name should be written out into GISRC
(again, I presume it does this already). Now there is a valid location so
other modules can be run. g.region should be run to read the region
information that was created by g.proj, and this presented to the user to
confirm in another dialog. I think this is important because in some cases
(creating from EPSG code is one example) g.proj will write out a default
region of one square pixel in size. This could be confusing later on. It's
important to remind the user to set the region at the start IMHO like the
text-based set_data startup does.
To do this we need another option/flag added to g.region, to allow it to
over-ride the default region. Maybe should leave it up to Martin Landa to
do that as he's currently working on it.
Hope these ideas make things clearer and not more confusing!
Paul
More information about the grass-dev
mailing list