Details Ticket 3729


Comment | Reply | Take | Open


Serial Number 3729
Subject g.region zoom= off by one error on eastern side
Area grass6
Queue grass
Requestors hamish_nospam@yahoo.com
Owner none
Status resolved
Last User Contact Mon Sep 25 19:51:10 2006 (2 yr ago)
Current Priority 30
Final Priority 70
Due No date assigned
Last Action Mon Sep 25 19:51:10 2006 (2 yr ago)
Created Wed Oct 12 04:46:12 2005 (3 yr ago)

Transaction History Ticket 3729


Wed, Oct 12 2005 04:46:12    Request created by hbowman  
Subject: g.region zoom= off by one error on eastern side

If you use r.slope.aspect to make new maps, the outside cells are NULL but the
map extent remains the same as the input elevation map.

So we use `g.region zoom=slope_map` to zoom in (by one cell on all sides) on
the real data.

This works on the north, west, and southern sides but not the east.

Off by one error in g.region?

Setting a region about 50x50 cells before running r.slope.aspect makes this
obvious.


thanks,
Hamish
Sun, Sep 24 2006 16:34:26    Mail sent by msieczka  
This bug is still present and it's bad. In spearfish60:

$ g.region -a n=4916070 s=4915800 w=602940 e=603240 res=30

$ r.mapcalc 'map1=1'

$ g.region -a n=4916250 s=4915620 w=602730 e=603450 res=30

$ g.region zoom=map1

$ g.region -g
n=4916070
s=4915800
w=602940
e=603270
nsres=30
ewres=30
rows=9
cols=11

WRONG: 'e' should be '603240' -> 'cols' should be '10'.

Maciek
Mon, Sep 25 2006 17:14:01    Mail sent by glynn@gclements.plus.com  
Return-Path <glynn@gclements.plus.com>
Delivered-To grass-bugs@lists.intevation.de
From Glynn Clements <glynn@gclements.plus.com>
MIME-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Transfer-Encoding 7bit
Message-ID <17687.62003.386770.3908@cerise.gclements.plus.com>
Date Mon, 25 Sep 2006 16:13:55 +0100
To Maciek Sieczka via RT <grass-bugs@intevation.de>
Cc hamish_nospam@yahoo.com, grass-dev@grass.itc.it
Subject Re: [GRASS-dev] [bug #3729] (grass) g.region zoom= off by one error on eastern side
In-Reply-To <20060924143426.EDD871005B9@lists.intevation.de>
References <20060924143426.EDD871005B9@lists.intevation.de>
X-Mailer VM 7.07 under 21.4 (patch 15) "Security Through Obscurity" XEmacs Lucid
X-Virus-Scanned by amavisd-new at intevation.de
X-Spam-Status No, hits=-5 tagged_above=-999 required=3 tests=[BAYES_00=-5]
X-Spam-Level
Maciek Sieczka via RT wrote:

> This bug is still present and it's bad. In spearfish60:
> 
> $ g.region -a n=4916070 s=4915800 w=602940 e=603240 res=30
> 
> $ r.mapcalc 'map1=1'
> 
> $ g.region -a n=4916250 s=4915620 w=602730 e=603450 res=30
> 
> $ g.region zoom=map1
> 
> $ g.region -g
> n=4916070
> s=4915800
> w=602940
> e=603270
> nsres=30
> ewres=30
> rows=9
> cols=11
> 
> WRONG: 'e' should be '603240' -> 'cols' should be '10'.

I've committed this change:

--- general/g.region/cmd/zoom.c	20 Aug 2006 14:40:05 -0000	2.3
+++ general/g.region/cmd/zoom.c	25 Sep 2006 14:45:10 -0000
@@ -47,7 +47,7 @@
 	if (row < top) top = row;
 	if (row > bottom) bottom = row;
 	if (col < left) left = col;
-	for (mark = col++; col < ncols; col++)
+	for (mark = col; col < ncols; col++)
 	{
 	    if (!G_is_null_value(rast_ptr, map_type))
 		mark = col;


col gets incremented (the fact that we got here means that we already
know that raster[col] is non-null, so we can skip testing it again),
but rast_ptr doesn't, so the two are out of sync. Either rast_ptr
needs to be explicitly incremented along with col, or col should not
be incremented (the latter is simpler, and probably clearer; the
inefficiency is trivial).

Also, the issue is much worse than your example suggests. Because col
is one too high, the loop never examines the rightmost column. 
Consider:

	$ g.region -a n=4916070 s=4915800 w=602940 e=603240 res=30
	$ r.mapcalc 'map1 = if(col() == 1 || col() == 10,1,null())'
	$ g.region -a n=4916250 s=4915620 w=602730 e=603450 res=30
	$ g.region rast=map1
	$ g.region zoom=map1
	$ g.region -p
	projection: 1 (UTM)
	zone:       13
	datum:      nad27
	ellipsoid:  clark66
	north:      4916070
	south:      4915800
	west:       602940
	east:       603000
	nsres:      30
	ewres:      30
	rows:       9
***>	cols:       2
	cells:      18

Thus, "g.region zoom=..." can actually make the region too small,
discarding valid data.

-- 
Glynn Clements <glynn@gclements.plus.com>


Mon, Sep 25 2006 17:29:31    Mail sent by msieczka  
> Also, the issue is much worse than your example suggests. Because col
> is one too high, the loop never examines the rightmost column. 
> Consider:
> 
> 	$ g.region -a n=4916070 s=4915800 w=602940 e=603240 res=30
> 	$ r.mapcalc 'map1 = if(col() == 1 || col() == 10,1,null())'
> 	$ g.region -a n=4916250 s=4915620 w=602730 e=603450 res=30
> 	$ g.region rast=map1
> 	$ g.region zoom=map1
> 	$ g.region -p
> 	projection: 1 (UTM)
> 	zone:       13
> 	datum:      nad27
> 	ellipsoid:  clark66
> 	north:      4916070
> 	south:      4915800
> 	west:       602940
> 	east:       603000
> 	nsres:      30
> 	ewres:      30
> 	rows:       9
> ***>	cols:       2
> 	cells:      18
> 
> Thus, "g.region zoom=..." can actually make the region too small,
> discarding valid data.

Glynn,

Sorry for being slow - does your fix take care of that also?

Maciek
Mon, Sep 25 2006 19:38:05    Mail sent by glynn@gclements.plus.com  
Return-Path <glynn@gclements.plus.com>
Delivered-To grass-bugs@lists.intevation.de
From Glynn Clements <glynn@gclements.plus.com>
MIME-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Transfer-Encoding 7bit
Message-ID <17688.5114.200963.488834@cerise.gclements.plus.com>
Date Mon, 25 Sep 2006 18:38:02 +0100
To Maciek Sieczka via RT <grass-bugs@intevation.de>
Cc hamish_nospam@yahoo.com, grass-dev@grass.itc.it
Subject Re: [GRASS-dev] [bug #3729] (grass) g.region zoom= off by one error on eastern side
In-Reply-To <20060925152932.2178F1005CF@lists.intevation.de>
References <20060925152932.2178F1005CF@lists.intevation.de>
X-Mailer VM 7.07 under 21.4 (patch 15) "Security Through Obscurity" XEmacs Lucid
X-Virus-Scanned by amavisd-new at intevation.de
X-Spam-Status No, hits=-5 tagged_above=-999 required=3 tests=[BAYES_00=-5]
X-Spam-Level
Maciek Sieczka via RT wrote:

> > Also, the issue is much worse than your example suggests. Because col
> > is one too high, the loop never examines the rightmost column. 
> > Consider:

[snip]

> > Thus, "g.region zoom=..." can actually make the region too small,
> > discarding valid data.
> 
> Sorry for being slow - does your fix take care of that also?

Yes.

-- 
Glynn Clements <glynn@gclements.plus.com>


Mon, Sep 25 2006 19:51:10    Status changed to resolved by msieczka  
Mon, Sep 25 2006 19:51:10    Mail sent by msieczka  
Closing it.

Maciek
Comment | Reply | Take | 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