<p dir="ltr">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?</p>
<div class="gmail_quote">On Jun 29, 2014 7:13 AM, "Glynn Clements" <<a href="mailto:glynn@gclements.plus.com">glynn@gclements.plus.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Sören Gebbert wrote:<br>
<br>
Huidae Cho wrote:<br>
<br>
> Cell files have pointers to rows in the header, so maybe, we could<br>
> implement functions that can copy multiple rows at a time without<br>
> uncompressing/compressing them row by row even if MASK may not be applied<br>
> properly. This is not a true update, but at least copy can be more<br>
> efficient than now.<br>
<br>
In theory, you could just append the modified rows and update the<br>
pointers, leaving the original rows in place.<br>
<br>
However, there are other issues with updates. E.g.<br>
<br>
* If the rows which were modified contained the minimum or maximum<br>
values within the map, we'd need to re-scan the entire map to<br>
determine the correct range for the updated map (normally, the range<br>
is updated as each row is written).<br>
<br>
* If the update affects the range, the colour table would no longer be<br>
correct (many colour tables are scaled to the range of the data),<br>
and may not cover the entire range of the data.<br>
<br>
* What should happen to the history? If the map has a histogram,<br>
should it be updated (which requires re-scanning the map) or deleted?<br>
<br>
In-place modification also creates issues for processes which may be<br>
reading the map. Although there should be no more than one session for<br>
each mapset, it's allowed to read maps from other mapsets. While there<br>
may be race conditions regarding metadata, the actual map data is<br>
updated more or less atomically (the cell/fcell/null files for new<br>
maps are written to temporary files then renamed into place).<br>
<br>
It would also be problematic for GDAL-linked maps (r.external[.out]).<br>
Many formats cannot realistically support in-place update (e.g. most<br>
compressed formats). Even if the format allows it, I don't know<br>
whether the GDAL API does.<br>
<br>
It would be less problematic (although still not entirely trivial) to<br>
add extensions to allow r.patch to be optimised, e.g. a<br>
Rast_copy_row() function which could copy the raw compressed data for<br>
a row from one map to another.<br>
<br>
--<br>
Glynn Clements <<a href="mailto:glynn@gclements.plus.com">glynn@gclements.plus.com</a>><br>
</blockquote></div>