this bug's URL: http://intevation.de/rt/webrt?serial_num=887
-------------------------------------------------------------------------
On Wed, Jan 02, 2002 at 09:35:28PM +0000, Glynn Clements wrote:
Markus Neteler wrote:
> while using r.neighbors on reclassed maps (from r.reclass)
> I got some strange results.Are you referring to the result map being almost entirely null?
E.g.
r.neighbors -z input=soils.Kfactor output=foo method=minimum size=5
produces a map which is null except for the very left-hand edge, while
r.mapcalc 'sk=soils.Kfactor'
r.neighbors -z input=sk output=foo method=minimum size=5seems to work OK.
> Is it possible that we have
> to added a test into r.neighbors? Or is it a local problem
> only?The bug is in libgis.
The call to G_get_d_raster_row() in readcell.c returns only NaN for
the original (reclass) "soils.Kfactor" map, but sensible values for
the (non-reclass) "sk" map.I've tracked this down to the double use of a static buffer
(G__.mask_buf) in G_get_raster_row().For reclass maps, G_get_raster_row() uses G__.mask_buf as a temporary
buffer. It calls G_get_c_raster_row(G__.mask_buf), which in turn calls
embed_nulls(G__.mask_buf), which calls G_get_null_value_row().
However, G_get_null_value_row uses G__.mask_buf itself (via the macro
MASK_BUF) to hold the mask row.Summary: static "work buffers" are a bad idea.
Unfortunately, some systems don't support alloca(), and some of those
which do don't make it straightforward to use. autoconf has a
solution, but it's messy. And using malloc()/free() for short-lived
buffers could significantly harm performance.For the time being, I guess that we'll have to just add another static
work buffer for the purpose of reclass maps. However, I'm not yet sure
of the mechanism used for allocating and reallocating such buffers.
Glynn,
thanks for looking into this! Do you see a chance to work
around? I have seen some malloc tests in other "configures"
such as GDAL etc. Perhaps they have a functional autoconf
implementation?
Markus
--- Headers Follow ---
From neteler@itc.it Fri Jan 4 18:34:51 2002
Return-Path: <neteler@itc.it>
Delivered-To: grass-bugs@lists.intevation.de
Received: from mail.intevation.de (aktaia [212.95.126.10])
by lists.intevation.de (Postfix) with ESMTP id ED4B3139D0
for <grass-bugs@lists.intevation.de>; Fri, 4 Jan 2002 18:34:50 +0100 (CET)
Received: from camelot.itc.it (camelot.itc.it [195.223.171.5])
by mail.intevation.de (Postfix) with ESMTP id C23191B96B
for <grass-bugs@intevation.de>; Fri, 4 Jan 2002 18:34:49 +0100 (CET)
Received: from artemide.itc.it (artemide [10.0.10.10])
by camelot.itc.it (8.11.3/8.11.3) with ESMTP id g04HYld26544;
Fri, 4 Jan 2002 18:34:47 +0100 (MET)
Received: from thuille.itc.it. (thuille [10.40.0.110])
by artemide.itc.it (8.11.3/8.11.3) with ESMTP id g04HYjx13745;
Fri, 4 Jan 2002 18:34:46 +0100 (MET)
Received: (from neteler@localhost)
by thuille.itc.it. (8.11.6/8.11.2) id g04HYj517478;
Fri, 4 Jan 2002 18:34:45 +0100
Date: Fri, 4 Jan 2002 18:34:45 +0100
From: Markus Neteler <neteler@itc.it>
To: Glynn Clements <glynn.clements@virgin.net>
Cc: grass5 developers list <grass5@grass.itc.it>,
grass-bugs@intevation.de
Subject: Re: [GRASS5] r.neighbors: works with reclass maps?
Message-ID: <20020104183445.A3608@itc.it>
Mail-Followup-To: Glynn Clements <glynn.clements@virgin.net>,
grass5 developers list <grass5@grass.itc.it>,
grass-bugs@intevation.de
References: <20020102181947.J3608@itc.it> <15411.32032.689209.584267@cerise.nosuchdomain.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <15411.32032.689209.584267@cerise.nosuchdomain.co.uk>; from glynn.clements@virgin.net on Wed, Jan 02, 2002 at 09:35:28PM +0000
X-Spam-Status: No, hits=0 required=5 tests=SUBJ_ENDS_IN_Q_MARK
-------------------------------------------- Managed by Request Tracker