[GRASS5] Re: [STATSGRASS] kriging, R and GRASS

[Glynn Clements]

Roger Bivand wrote:

> > > On Mon, 17 Jan 2005, Roger Bivand wrote:
> > > 
> > > ... and also wanted show that rastput() would scale well to much finer
> > > grids - which it does - and found a bug in rastput() and other functions
> > > that has led to the layer being written to the GRASS database with the
> > > wrong window if system("g.region ... ") is used. This is the same bug that
> > > affected gmeta() until Bodo Ahrens found it 18 months ago. The problem was
> > > that the GRASS library function tries to be too clever (I think disk
> > > access was very slow when it was written), and stores a local version of
> > > the data in memory in a cache of sorts. It does not check, though, whether
> > > the data on disk have changed - it just returns the cached values! Using a 
> > > lower-level function, and conditionally altering G__init_window () seems 
> > > to have fixed it. The new version should reach CRAN soon.
> > 
> > Roger,
> > 
> > is there any change which should go into GRASS-CVS?
> 
> G__init_window () in src/libes/gis/window_map.c does the same as in my
> local copy, that is calls G_get_window (), rather than G__get_window ().  
> What usually causes trouble for non-exiting use of libgis.a is the number
> of places things are saved in a global variable (like G__.) which do not
> get refreshed when the data on disk change. You can see it happening in
> G_get_window () and its use of static int first (get_window.c), which uses
> the cached dbwindow without checking the disk version write time. My guess
> would be that I don't loose much in time by doing G__get_window () always,
> but this time I hadn't realised that G__init_window () called in opening
> and closing cells imposes the stale header, from G_get_window ().
> 
> Is checking the write time faster than just reading the current window? If 
> so, G_get_window () could be altered to record its last refresh time, and 
> if the window had been written since then, re-read. If not, G_get_window ()
> should just read anyway. How would this play when the GRASS database is 
> across a network? 

G_get_window() shouldn't be re-reading the WIND file. For the vast
majority of programs, it's essential that repeated calls to
G_get_window() always return the same data.

Changing it for the benefit of a long-running program will break
normal programs.

If you need to force a re-read, add a new function which clears the
G__.window_set flag, so that a subsequent call to G_get_window() will
re-read the WIND file.

That will ensure that existing code doesn't break if the WIND file
changes during execution.

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