[GRASS-dev] r.surf.contour inefficiency?
Hamish
hamish_b at yahoo.com
Mon Feb 9 18:45:47 EST 2009
Glynn wrote:
> 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.
mmph. for me the pain threshold is usually if the job is not done yet
by the time I return monday morning. But computers get faster & faster..
Hamish:
> > 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().
that is true, but not what I meant: (trac #392)
G65> r.mapcalc 'nullmap = null()'
100%
G65> r.info -r nullmap
min=-2147483648
max=-2147483648
G65> r.univar nullmap
100%
total null and non-null cells: 2654802
total null cells: 0
Of the non-null cells:
----------------------
n: 2654802
minimum: 0
maximum: 0
range: 0
mean: 0
mean of absolute values: 0
standard deviation: 0
variance: 0
variation coefficient: nan %
sum: 0
:-(
Hamish
More information about the grass-dev
mailing list