[GRASS-dev] G.proj requirements?

[Paul Kelly]

On Fri, 15 Dec 2006, Michael Barton wrote:

> Paul,
>
> This is very helpful.
>
> On 12/15/06 3:44 AM, "Paul Kelly" <paul-grass at stjohnspoint.co.uk> wrote:
>
>> I *think* all it should need is a valid GISRC file, i.e. with the 3 fields
>> GISDBASE, LOCATION_NAME and MAPSET. The latter two won't be relevant if no
>> exising locations are there, so they can contain anything, but GISDBASE is
>> important. Look at the code in Init.sh that creates a initial GISRC if
>> none is there. So I think it should work if the file contains the 3 lines:
>> GISDBASE: C:/grassdata
>> LOCATION_NAME: <UNKNOWN>
>> MAPSET: <UNKNOWN>
>
> This is what I began to suspect.
>
>>
>> You need to set the GISRC environment variable to point to the location of
>> this file; also the GISBASE environment variable needs to point to the
>> location of the GRASS installation. I think that should be all you need.
>> Note that Init.sh will have created a GISRC file if none exists before
>> starting gis_set.tcl (AFAICT) so you should have no trouble here at all
>> and not actually need to worry about this. I think.
>
> But given this, I'm wondering now if the .gisrc6 file is the issue at all.

Yes - what was the problem exactly? If there is something else in g.proj 
or the libraries it uses it might be better to fix it rather than working 
around it. I was thinking - if the user changes the GISDBASE setting in 
the gis_set.tcl window before clicking to create a new location with 
georeferenced file or EPSG code, will gis_set.tcl update the GISRC file 
before running g.proj? I suspect not, but it needs to do so so that the 
location is created under the correct GISDBASE.

>> Just a note that you need to pay attention to what is done by Init.sh and
>> what is done by etc/set_data (text) or gis_set.tcl (GUI) and the
>> interaction between the two. E.g. where Mariss was talking about failure.
>> Failure should be handled in Init.sh I think - the key thing is for
>> gis_set.tcl to return a proper return value so Init.sh knows it has
>> failed. Of course "recoverable failures" could be handled within
>> gis_set.tcl and give the user another chance to create the location.
>
> Following your advice, I looked at what init.sh is doing with the grassrc
> file at startup. I still don't understand it completely, but it looks like
> it is creating a temporary GISRC file in all cases. If a .grassrc6 file
> already exists, this is copied to GISRC in the tmp directory and used. If
> not, a temporary GISRC is created. All this happens in init.sh before
> gis_set.tcl is called. In the case of a first time user, the current working
> directory (PWD in the bash script) is used as a GISDBASE initially. This is
> what shows up in the GRASS entry GUI the first time you run it (or if you
> run it after deleting your .grassrc6 file).
>
> AFAICT, GRASS uses the GISRC file it creates (normally by copying .grassrc6,
> but created by init.sh if needed) for all session reference to the startup
> information.

Yes I think that's all correct. But it is very hard to follow now because 
of the complications allowed by allowing concurrent GRASS sessions. 
Previously there was just the one .grassrc6 file (actually IMHO this 
should be version-specific: .grassrc60, .grassrc62, .grassrc63 etc. as it 
was with GRASS 5.x) in the home directory and everything was read from or 
written to there - no temporary copies in /tmp were involved. For the 
Windows batch file (init.bat) I wrote to duplicate the functionality of 
Init.sh, I left all this temporary copying of GISRC out to simplify 
things. It means you can only have one concurrent session but that is 
normal on Windows I suppose.

> What I'm not yet sure about is when the GISDBASE environmental variable gets
> set. Quite possibly, with the gui startup, this is not until you push the
> start grass button, even if you have a valid GISDBASE path in the startup
> gui entry widget.

Is there actually a GISDBASE environment variable? I don't think there 
should be, and if something is relying on it being there it should be 
changed. As far as I understand it the only environment variables 
absolutely necessary are GISRC and GISBASE and GISDBASE is stored in GISRC 
and read by modules using library functions or with g.gisenv.

> If this is the case, and if this is what g.proj needs to know in order to
> create its new location, it is easy to simply set GISDBASE in both the EPSG
> and georeferenced file startup scripts.

Like I said I don't think this is necessary or desirable - as far as I can 
see g.proj will get the GISDBASE value to create the new location under 
from the file specified by $GISRC.

> While I could certainly go through the procedures of making a temporary
> GISRC file, init.sh has already done this and the script will overwrite what
> is already there. I could also make the fake location, but I think that is

It can be anywhere, as long as you change the value of $GISRC to point to 
it. No need to overwrite anything. But yes, it is not clear why the 
initial/temporary file created by Init.sh doesn't work. This would be the 
main point to look at I think.

> not necessary. I don't want to copy useless code into new modules; there is
> enough of that legacy already to deal with.
>
> At a minimum, we simply need to set the GISDBASE variable. At a maximum, we
> may also need to create a .grassrc6 file by copying the existing GISRC file
> to the home directory. However, I'm not sure how that works in Windows. Is
> there anyway to see if g.proj actually reads .grassrc6 or checks for its

All modules that use the parser do. They simply won't work without a GISRC 
file. To see this, just try changing the GISRC environment variable to a 
non-existent file within a GRASS text-based session and try running any 
GRASS command. It won't work. I think setting the GISRC environment
variable and/or making sure it is set properly is the main thing to look 
at rather than creating new .grassrc6 files everywhere (the file can 
actually of course have any name---it just needs to be contained in the 
GISRC environment variable).

> existence? An intermediate step might be to replace any temporary GISDBASE
> setting in the working session GISRC file with a valid path, but I'm
> skeptical since it should already be making one.
>
> I'm not quite sure how I can test this. Maybe if I rename .grassrc6 it will
> simulate a new user.

Yes rename or delete it and on startup Init.sh will create a new one.

Paul