[GRASS-dev] G.proj requirements?

[Paul Kelly]

On Sun, 17 Dec 2006, Glynn Clements wrote:

>> (a) All modules have to call G_gisinit() at the start, and among other
>> things it checks for a valid current location and mapset. However the case
>> we're discussing is a rare example of where that isn't needed. Most of the
>> rest of what G_gisinit() does (from a quick skimming over the code) seems
>> related to raster modules and might possibly be possibly avoided?
>
> Note that there is also G_no_gisinit(), which doesn't check for a
> valid location/mapset.
>
> This is probably more appropriate for a module which needs to run
> without a valid mapset.

Of course. I did see G_no_gisinit() while browsing libgis but it just 
didn't occur to me that it was what I needed - I couldn't quite see what 
its purpose was.

> I do wonder whether it's appropriate for this functionality to be
> bundled into g.proj rather than being a separate module.

Yes I see where you're coming from, although the actual location-creation 
code in g.proj really just amounts to a call to G__make_location() : the 
vast bulk of the g.proj code relates to input and output of co-ordinate 
system descriptions from and to various sources and sinks - and in this 
sense the PROJ_INFO, PROJ_UNITS, WIND and DEFAULT_WIND of a new location 
can be considered just another output format for the co-ordinate system. 
So the functionality fits in here due to convenience of programming more 
than anything else.

>> (b) If the call to G_gisinit() is simply commented out, the next problem
>> is G_tempfile() [deep within GRASS gproj library] which tries to create a
>> tempfile in the current mapset as far as I remember - is this a good/bad
>> idea? Certainly bad if you don't have a current mapset.
>
> G_tempfile() uses the current mapset so that "draft" output maps can
> be moved (with either link()+remove() or rename()) into their final
> location upon closure. This requires them to reside on the same
> filesystem (partition) as the mapset directory (i.e. you can't use
> /tmp or $TMPDIR).
>
> I suggest:
>
> 1. Rename the existing G_tempfile() function.
>
> 2. Add a new G_tempfile() which uses the /tmp/grass6-<user>-<pid>
> directory (or possibly $TMPDIR) instead.

Right. It was mentioned before that tempnam() could be used - although I 
see on Linux that warns that it shouldn't---but I don't understand why. 
The /tmp/grass6-<user>-<pid> location is tied in tightly to the concurrent 
session stuff in Init.sh isn't it---I'd rather not get into complications 
of relying on this if possible because it reduces the simplicity of only 
having to set a few environment variables (GISBASE and GISRC for GRASS to 
run). E.g. in the experimental Windows version of Init.sh (init.bat) I 
have not even bothered implementing concurrent sessions yet.

tempnam() uses $TMPDIR if set, which means it seems to work on Windows, or 
a specified directory as the second choice. This seems to work OK:

char *G_tempfile_in_mapset(void)
{
     return G__tempfile(getpid());
}

char *G_tempfile(void)
{
     return G_convert_dirseps_to_host( tempnam("/tmp", "grass") );
}


but I can see deleting of temporary files after a session being a problem. 
The prefix for the temp files (in this case "grass") can be at most 5 
characters with tempnam() and I don't think it would be desirable to go 
looking in the temporary directory and deleting any files that started 
with that at the end of a session. Using the per-session directory would 
of course get round that problem, so maybe it is worth a second thought...

The other option is to keep a lookout after changing it for badly-behaved 
modules that don't delete their temp files. Also I don't think it's 
unreasonable for temp files to be left undeleted if a module crashes? 
Might be useful for debugging even.

> 3. Change close_new() (lib/gis/closecell.c, used by G_close_cell() and
> G_unopen_cell()) to use the existing (renamed) function. Ditto for
> anything else which creates temporary files with the intention of
> moving them (if there is anything else).

opencell.c seemed to be the file that actually required changing? But only 
two places to change it and very easy.

>> (c) Hard-coding the tempfile path in lib/proj/datum.c instead of calling
>> G_tempfile() gets as far as writing out the new WIND and DEFAULT_WIND.
>> This is done by a call to G__put_window() in G__make_location().
>>
>> G__fopen_new(), which is called by G__put_window(), makes a call to
>> G__check_gisinit() which fails [because we haven't called G_gisinit()].
>
> G_no_gisinit() will suffice to keep G__check_gisinit() happy.

Yes - can confirm this. Works well now.

Will not commit any G_tempfile() changes in the near future though until 
the best option becomes clearer.

Paul