[GRASS-dev] r.surf.contour inefficiency?

[Glynn Clements]

Hamish wrote:

> > > But, if the nature of the algorithm is such that processing time
> > > becomes a problem long before memory does, then there's no point to
> > > using any form of segmentation.
> 
> as the module gets faster, the size of map you attempt to run it on
> gets bigger and memory does start to become an issue...
> 
> FWIW the biggest actual-data region I've tried with r.surf.contour was
> 21000x13000 (this was a long while back, so god knows how long it took to
> finish, could have been a week..*). If it stores it in memory in the input
> map's CELL_TYPE, that'll take ~ 2.1gb RAM by my numbers (DCELL). If stored
> in memory as CELL, half that. I can accept that much, but it is pushing on
> needing a 'percent of map to keep in memory' option.

If you're running jobs which take days, I don't think that it's
unrealistic to require a manual tile/process/patch. It's quite likely
that you will want to do that anyhow in order to split the task over
multiple systems.

> I did the same in my tests knowing that it /shouldn't/ have an effect.
> If nothing else it's a good fail-safe sanity check. e.g. NULL support
> in 6.5 is currently borken, if r.surf.contour outputted maps containing
> NULLs it probably would have picked that up.

r.surf.contour is one of the few modules still using zero-is-null,
i.e. G_get_map_row() rather than G_get_c_raster_row().

-- 
Glynn Clements <glynn at gclements.plus.com>