[GRASS-dev] Interested in parallelization of GRASS

[Maris Nartiss]

2011/3/26, Glynn Clements <glynn at 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 <glynn at 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.