[GRASS-dev] G.proj requirements?

[Michael Barton]

Should I wait a bit then to see if this can be resolved in g.proj and not
implment a TclTk workaround yet?

Michael


On 12/17/06 8:00 AM, "Glynn Clements" <glynn at gclements.plus.com> wrote:

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

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

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