Details Ticket 887


Comment | Reply | Open


Serial Number 887
Subject Re: [GRASS5] r.neighbors: works with reclass maps?
Area none
Queue grass
Requestors neteler@itc.it
Owner gclements
Status resolved
Last User Contact Never contacted
Current Priority 30
Final Priority 70
Due No date assigned
Last Action Sun Jan 6 10:49:26 2002 (7 yr ago)
Created Fri Jan 4 18:34:51 2002 (7 yr ago)

Transaction History Ticket 887


Fri, Jan 4 2002 18:34:51    Request created by neteler@itc.it  
Return-Path <neteler@itc.it>
Delivered-To grass-bugs@lists.intevation.de
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
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=5
> 
> seems 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


Sun, Jan 6 2002 10:49:22    Taken by gclements  
Sun, Jan 6 2002 10:49:26    Status changed to resolved by gclements  
Comment | Reply | Open

You are currently authenticated as guest.
[Show Configuration] [Login as another user]

Users Guide - Mail Commands - Homepage of RequestTracker 1.0.7 - list any request