2011/3/26, Glynn Clements <gl...@gclements.plus.com>: > > Supporting concurrent reads on a single raster map would make the code > significantly more complex. Concurrent writes would be even worse > unless compression was disabled. > -- > Glynn Clements <gl...@gclements.plus.com> > And this brings us back to question - is current GRASS raster storage the best one? Could GRASS benefit from moving to some quad-tree like storage? Current gislib doesn't expose internal data structures to most of analysis modules and thus it shouldn't require any module changes. I know - for worst case scenarios such approach could provide no speedup or worse - be slower than current implementation, still I would love to see solid numbers on different storage approaches before saying "YES/NO" to alternatives. Anybody has a CS student interested in algorithms and data storage problems?
Just 0.02 from non-CS person, Maris. _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
