Sören Gebbert wrote: Huidae Cho wrote:
> Cell files have pointers to rows in the header, so maybe, we could > implement functions that can copy multiple rows at a time without > uncompressing/compressing them row by row even if MASK may not be applied > properly. This is not a true update, but at least copy can be more > efficient than now. In theory, you could just append the modified rows and update the pointers, leaving the original rows in place. However, there are other issues with updates. E.g. * If the rows which were modified contained the minimum or maximum values within the map, we'd need to re-scan the entire map to determine the correct range for the updated map (normally, the range is updated as each row is written). * If the update affects the range, the colour table would no longer be correct (many colour tables are scaled to the range of the data), and may not cover the entire range of the data. * What should happen to the history? If the map has a histogram, should it be updated (which requires re-scanning the map) or deleted? In-place modification also creates issues for processes which may be reading the map. Although there should be no more than one session for each mapset, it's allowed to read maps from other mapsets. While there may be race conditions regarding metadata, the actual map data is updated more or less atomically (the cell/fcell/null files for new maps are written to temporary files then renamed into place). It would also be problematic for GDAL-linked maps (r.external[.out]). Many formats cannot realistically support in-place update (e.g. most compressed formats). Even if the format allows it, I don't know whether the GDAL API does. It would be less problematic (although still not entirely trivial) to add extensions to allow r.patch to be optimised, e.g. a Rast_copy_row() function which could copy the raw compressed data for a row from one map to another. -- Glynn Clements <[email protected]> _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
