Peng Du wrote: > In function static int compute_window_row(int fd, int row, int *cellRow) > in ~/grass/7.0/grass_trunk/lib/raster/get_row.c, there is a check to see > if row is in window, and if not, 0 is returned. > > I came across this function from get_map_row_nomask(...) in the same > file (which came all the way from Rast_get_row(fds[i], rowbuf, row, > maptype);), and the result of compute_window_row(...) is used to > determined whether to "read cell file row if not in memory". > > I'm a little confused about the concept 'window' here, and how does that > relate to "in memory"?
The "window", also referred to as the "region", defines a grid in cartographic space. It consists of a rectangle defined by the north, south, east and west bounds, and the number of rows and columns. All input raster maps are resampled, cropped and/or padded with nulls according to the window. This allows a module to read multiple raster maps which may have differing bounds and resolutions without having to handle the details explicitly. > My understanding is that "window" is a "visible area", and rows are only > read from disk file if it's within this "window" area. Then what would > happen if rast_get_row is used to get the exact same row in exact the > same map more than once? Does the second time NOT read the row from file > because the first time has put this row in memory? In this case the > requested row is copied from a inner buffer that was filled with the > data during the first time call? Correct. The file lib/raster/R.h defines the core data structures used by the raster library. R__.fileinfo points to an array of fileinfo structures, indexed by the map's file descriptor (this is the actual Unix file descriptor of the cell/fcell file). Within the fileinfo structure, the "data" field points to the data for the current row, after decompression but before resampling or conversion. The "cur_row" field contains the number of the row to which the data corresponds. get_map_row_nomask() (which all of the higher-level "get row" functions use) checks whether the row being requested is equal to the row which is stored; if it is, it doesnt' bother to read the row from disc again. If an input map has a larger (coarser) north-south resolution than the current region, adjacent rows within the current region will often map to the same row in the underlying map. By caching the most recent row in the fileinfo structure, redundant disc access is avoided. Note that the "processed" data cannot be cached, as it may depend upon a MASK map, which can have a finer resolution than the map itself. Also, it's permitted to change the window while a map is being read, and it's also permitted to change the requested format (CELL, FCELL or DCELL). If the processed data was cached, it would be necessary to store additional information about the cached data in order to determine whether it can be re-used. Storing the "raw" data from the file doesn't have these problems, as the only processing (the decompression) doesn't depend upon any parameters or settings. -- Glynn Clements <[email protected]> _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
