[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