[GRASS-dev] G.proj requirements?

[Glynn Clements]

Paul Kelly wrote:

> I've re-organised g.proj a bit so it doesn't read the region and 
> projection from the current location unless it has to. But the problem 
> remains, in three places:
> (a) G_gisint()
> (b) G_tempfile()
> (c) G__put_window()/G__fopen_new()
> 
> (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.

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

> (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.

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).

> (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.

Note that the only thing that G__check_gisinit() actually verifies is
that certain fields in the G__ structure have been initialised
(specifically: fp_type, fp_nbytes, auto_mask), and that the mask
buffer has been allocated.

Unlike G_gisinit(), G_no_gisinit() doesn't set the program name, which
is probably a (design) bug, as G_fatal_error() etc assume that this
has been set.

> This would need quite a bit of re-engineering to fix in an elegant way, 
> definitely worth thinking about though IMHO. For now, looks like a 
> complicated workaround is required. :(

The G_check_gisinit() issue is solved by G_no_gisinit().

> The default region is still an issue also, as Helena said. I know I should 
> copy some code from r.in.gdal and v.in.ogr to g.proj to handle this as far 
> as possible (i.e. match the default region in the new location to the 
> georeferenced file - better than doing nothing). When there's some more 
> time can maybe do that. And it will still be a problem with creating from 
> EPSG code as the user is not forced or even reminded to set the region.

Maybe lib/gis/gisinit.c needs another function which forces
initialisation, creating a temporary gisdbase/location/mapset,
including WIND and ../PERMANENT/DEFAULT_WIND files.

-- 
Glynn Clements <glynn at gclements.plus.com>