[GRASS5] [bug #4248] (grass) r.surf.contour: Treats 0 as NULL and other archaic problems

[Request Tracker]

this bug's URL: http://intevation.de/rt/webrt?serial_num=4248
-------------------------------------------------------------------------

Subject: r.surf.contour: Treats 0 as NULL and other archaic problems

Hi,

- If you feed r.surf.contour an input file including 0 as an elevation (say a
coastal area with the sea set to 0), it treats all the 0s as NULL and takes
days to complete. Change the 0s to -1s and it goes by relatively quickly.
Zero hasn't been NULL in GRASS for a long long time now.


- Looking at the code I see support for a MASK is hardcoded, and the module
does all sorts of bitwise operations on unmasked cells.. "w.t.f.?"


- running some time/memory trials I see there is no use for not using the -f
flag. Memory use was at most 5mb RAM during the non-default "memory intensive"
run. I think we can handle that these days. With -f it was 4 times faster:

rows:       2900
cols:       3000
total null cells: 4048763
2.8GHz Pentium4


CELL input, with the -f flag
  real    42m23.483s
  user    32m34.690s
  sys     8m5.880s
   2563 pts/6    RN+   40:37    207    19  5484 3172  0.1
================
DCELL -f
  real    41m8.144s
  user    32m21.580s
  sys     8m8.930s
  10641 pts/6    RN+   40:27    217    19  5496 3224  0.1

================
DCELL no -f
  real    178m50.506s
  user    165m21.230s
  sys     9m46.040s
  13944 pts/6    RN+  175:06    279    19  3676 2460  0.1
================
CELL no -f
  real    178m54.097s
  user    165m11.190s
  sys     9m42.560s
   1071 pts/6    RN+  174:52    270    19  3664 2412  0.1


Let's get rid of non "-f" code in the module.


- I noticed that the memory slowly grows as 'r.surf.contour -f' ran. Minor
memory leak?


- output is always CELL, regardless of input map type. If this is an indelible
feature of the module(?), it should at least be noted on the help page.


Otherwise I really like the output this module creates. I never liked having
to throw away data (by hand) to stop v.surf.rst from segmenting and aliasing
itself along the high density contour lines verticies, especially in low lying
areas & valley floors where is lots of empty space between contours.

Along with the contour lines I am lucky enough to have trig station elevations
so I don't have problems with "flat hill tops".


merging some other bugs into this one as similar issues (#1402 and #3515).


thanks,
Hamish


-------------------------------------------- Managed by Request Tracker