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

[Glynn Clements]

Hamish wrote:

> > Other than the memory option and module name, it doesn't really say  
> > how it operates differently from r.proj.  Some hint about situations  
> > one might want to use it would be good.  Maybe mention that there  
> > will be more disk activity.
> > 
> > Add cross-references in each to the other.  Both see-also links, and  
> > in r.proj, a hint about using r.proj.seg for large rasters and where  
> > memory is limited.
> 
> 
> Is the long term plan to fully replace r.proj with r.proj.seg after
> r.proj.seg gets enough testing?

Yes.

> > G_mapset() does one-shot initialisation, i.e. it takes a copy of the
> > value of the MAPSET variable the first time that it's called, and
> > returns the copied value thereafter. G__mapset() returns the value
> > directly.
> 
> 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).

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.

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