[GRASS-dev] Rast_open_update?

[Glynn Clements]

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 <glynn at gclements.plus.com>