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

GRASS GIS GRASS GIS developer
1

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

2

I discovered what seems to be a similar behavior in d.his. It appears to
treat 0's as nulls. I promised Glynn to send a test data set but haven't
had a chance to do so yet. Maybe someone else can also check this.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

From: Request Tracker <grass-bugs@intevation.de>
Reply-To: Request Tracker <grass-bugs@intevation.de>
Date: Wed, 5 Apr 2006 12:24:50 +0200 (CEST)
To: <grass5@grass.itc.it>
Subject: [GRASS5] [bug #4248] (grass) r.surf.contour: Treats 0 as NULL and
other archaic problems

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