[GRASS-dev] G.proj requirements?

[Michael Barton]

Paul,

I've run some tests and understand what g.proj is doing and I understand
why. Here are a few of the test results. I started GRASS without a .grassrc6
file and tried to create a new location, using a georeferenced file. I
modified the GISRC file in several ways prior to invoking the georeferenced
file to define a new location. As I noted before, GRASS always makes a
default GISRC file. If there is no pre-existing .grassrc6 file, the GISRC
file sets GISDBASE to the current working directory, and both LOCATION_NAME
and MAPSET to <UNKNOWN>.

Test 1: started with no .grassrc6 file; no other modification

=================================================================
If you wish to resize the X monitor, do so now. Window size is
locked while interactive modules are running.
=================================================================

access: No such file or directory
ERROR: LOCATION << /Users/cmbarton/<UNKNOWN> >> not available

ERROR: g.proj exited abnormally. Press <enter> to continue.

************************************************************

Test 2: started with no .grassrc6 file; modified /tmp/.../GISRC file to
change 

LOCATION_NAME: <UNKNOWN>

to 

LOCATION_NAME: testloc

=================================================================
If you wish to resize the X monitor, do so now. Window size is
locked while interactive modules are running.
=================================================================

access: No such file or directory
ERROR: LOCATION << /Users/cmbarton/testloc >> not available

ERROR: g.proj exited abnormally. Press <enter> to continue.

************************************************************

Test 3: started with no .grassrc6 file; modified /tmp/.../GISRC file to name
a location and mapset directory (testloc and PERMANENT); created
$HOME/testloc/PERMANENT but did not put anything in directory


=================================================================
If you wish to resize the X monitor, do so now. Window size is
locked while interactive modules are running.
=================================================================

ERROR: default region is not set

ERROR: g.proj exited abnormally. Press <enter> to continue.


So, it is clear that g.proj looks at the GISRC file, then verifies the
existence of the location and mapset specified in the file, then looks for
the WIND file inside the PERMANENT mapset of the specified location.

This makes a lot of sense for most of g.proj functionality, specifically
reporting the current projection information in various formats and
modifying the projection information of the current location.

However, it is problematic for creating a new location--that is, with the -c
flag and a new location specified in the location=[new loc name] argument.

There are ways to get around this currently, but it would be much better if
the checks for a valid location, mapset, and WIND file were bypassed for
using g.proj to create a new location. The only thing it needs to know to do
this is a valid GISDBASE, and this is always specified in a GISRC file. So
what are the chances of modifying g.proj in this way instead of requiring
the startup scripts to make some fake locations and WIND files to satify
g.proj?

To start from scratch with something other than the current working
directory, we'd need to replace this temporary GISRC file with whatever
directory is specified in the GUI startup, but this isn't too difficult.

Markus has produced a workaround in a bash script that is necessary because
of the way g.proj functions. It makes and erases temporary location, mapset,
and WIND files, and archives, replaces, and restores the .grassrc6
file--regardless of whether or not you have a valid location already in
existence. This worries me a bit as it makes more opportunities for
corruption in the .grassrc6 file or GISDBASE path if something goes wrong in
the process.



Michael


On 12/15/06 11:07 AM, "Paul Kelly" <paul-grass at stjohnspoint.co.uk> wrote:

> 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

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton