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" <[email protected]> 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 <[email protected]> >
_______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
