[GRASS-dev] Re: [GRASS-user] problems using r.proj with large data set

[Hamish]

Glynn Clements wrote:
> > so will this fix the imediate problem?  G__tempfile()
> > 
> >     do
> >     {
> >         sprintf (name, "%d.%d", pid, uniq++) ;
> > -       G__file_name (path, element, name, G_mapset()) ;
> > +       G__file_name (path, element, name, G__mapset()) ;
> >     }
> 
> That will fix the general G__tempfile() issue.
> 
> My previous fix should suffice for r.proj.seg. By switching back to
> the original environment before calling G_tempfile(), G_mapset() and
> G__mapset() should produce the same results.
> 
> Actually, G__tempfile() probably shouldn't be called while the
> alternate environment is active, as it will create the temporary file
> in the location from the alternate environment (i.e. the source
> location), when you probably want it to be in the current location
> (according to $GISRC).

So $ETC/clean_temp won't be run and we need to be extra sure that the
tempfile is removed when the program exits, either successfully or
unsuccessfully.

> There's still the general issue that any other functions which use
> G_mapset() may not behave as expected while an alternate environment
> is active.

At least we are now aware of the problem, and as well we already know
well which cases invoke an alternate environment. And hopefully we can
move away from that sort of trick with time (ala Michael's georectifier).


Hamish