[GRASS-dev] Rast_open_update?

[Huidae Cho]

We can edit vector maps and does it mean that vector maps don't use a
compression algorithm and have the issues you mentioned about raster maps?
On Jun 29, 2014 7:13 AM, "Glynn Clements" <glynn at gclements.plus.com> wrote:

>
> 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>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20140629/37636d4a/attachment.html>