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