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

[Michael Barton]

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 at intevation.de>
> Reply-To: Request Tracker <grass-bugs at intevation.de>
> Date: Wed,  5 Apr 2006 12:24:50 +0200 (CEST)
> To: <grass5 at 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
>