[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