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

[Glynn Clements]

Hamish wrote:

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

No, we just need to be sure that the starting environment is selected
before calling G__tempfile(), which is how r.proj.seg was fixed.

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

You can't avoid using alternate environments if a program needs to
access another location.

The simplest defensive strategy is to ensure that you leave the
starting environment active by default. IOW, switch to the alternate
environment immediately before each call which uses it, and switch
back immediately afterwards.

The problem with r.proj.seg arose primarily due to the structure of
the original r.proj. Whereas the original readcell() function simply
read the map into memory (and thus needed to operate in the alternate
environment), the new readcell() copies it to a temporary file. Thus,
G__tempfile() ended up being called in essentially the only place
where the alternate environment was active. The rest of r.proj.seg
operates in the starting environment.

[Aside: my first attempt used a rowio-type strategy, but I discovered
that you can't switch projections while you have maps open; hence the
need to copy the map to a temporary file.]

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