Details Ticket 4598


Comment | Reply | Take | Resolve


Serial Number 4598
Subject g.region from raster wrong when crossin 180 deg
Area grass6
Queue grass
Requestors kyngchaos@kyngchaos.com
Owner none
Status open
Last User Contact Sun Oct 8 10:31:27 2006 (2 yr ago)
Current Priority 30
Final Priority 70
Due No date assigned
Last Action Sun Oct 8 13:21:51 2006 (2 yr ago)
Created Tue Jun 13 21:18:20 2006 (2 yr ago)

Transaction History Ticket 4598


Tue, Jun 13 2006 21:18:20    Request created by guest  
Subject: g.region from raster wrong when crossin 180 deg

Platform: Mac OSX
grass obtained from: Trento Italy site
grass binary for platform: Compiled from Sources
GRASS Version: CVS 2006_05_27

an example is the best way I can describe this.  I have an SRTM tile at S18W180,
that is it covers 
180W-179W/18S-17S.  Due to the cell-center alignment of SRTM, it extends 1.5"
outside this area, 
so the real region of the tile is:

north:      16:59:58.5S
south:      18:00:01.5S
west:       179:59:58.5E
east:       178:59:58.5W
nsres:      0:00:03
ewres:      0:00:03
rows:       1201
cols:       1201

I want to merge this with the nex tile over, S18W179, so I set the region from
the two rasters:

g.region rast=S18W180,S18W179

now the region is wrong:

north:      16:59:58.5S
south:      18:00:01.5S
west:       179:00:01.5W
east:       178:59:58.5W
nsres:      0:00:03
ewres:      0:00:03
rows:       1201
cols:       432001

The west edge should not change (179:59:58.5E), and the east edge should be another
degree east 
(177:59:58.5W) and the column count should be calculated from that, not spanning
the globe 
(2401).  Based on the above wrong E/W, the column count is still wrong, it should
be 1 (but it 
displays correctly in a monitor).

g.region rast=S18W180

gives the correct region for the single raster.

g.region rast=S18W180,S18E179

for a regionwith the tile to the west instead, gives the correct region.

Manually setting the region to what it should be also gives the wrong region:
g.region w=179:59:58.5E e=177:59:58.5W -p
projection: 3 (Latitude-Longitude)
zone:       0
datum:      ** unknown (default: WGS84) **
ellipsoid:  wgs84
north:      16:59:58.5S
south:      18:00:01.5S
west:       179:59:58.5E
east:       177:59:58.5W
nsres:      0:00:03
ewres:      0:00:00.000007
rows:       1201
cols:       1037234401

The extents are right, but the ewres/cols is wrong.  Forcing the resolution finally
fixes the problem:

g.region w=179:59:58.5E e=177:59:58.5W -p -a res=0:00:03
projection: 3 (Latitude-Longitude)
zone:       0
datum:      ** unknown (default: WGS84) **
ellipsoid:  wgs84
north:      16:59:57S
south:      18:00:03S
west:       179:59:57E
east:       177:59:57W
nsres:      0:00:03
ewres:      0:00:03
rows:       1202
cols:       2402

But only for manually setting e/w, with rast= it doesn't help.
Tue, Jun 13 2006 21:33:45    Comments added by guest  
Oh, that last example when setting the resolution, I should have left out the
-a option so it doesn't 
realign to the location grid:

g.region w=179:59:58.5E e=177:59:58.5W -p res=0:00:03
projection: 3 (Latitude-Longitude)
zone:       0
datum:      ** unknown (default: WGS84) **
ellipsoid:  wgs84
north:      16:59:57S
south:      18:00:03S
west:       179:59:58.5E
east:       177:59:58.5W
nsres:      0:00:03
ewres:      0:00:03
rows:       1202
cols:       2401
Sun, Oct 8 2006 10:31:27    Mail sent by msieczka  
Hi,

Can you tell if this bug has the same origin ad the
http://intevation.de/rt/webrt?serial_num=3801?

Maciek
Sun, Oct 8 2006 13:21:51    Mail sent by kyngchaos@kyngchaos.com  
Return-Path <kyngchaos@kyngchaos.com>
Delivered-To grass-bugs@lists.intevation.de
Mime-Version 1.0 (Apple Message framework v752.2)
In-Reply-To <20061008083127.60F361005A8@lists.intevation.de>
References <20061008083127.60F361005A8@lists.intevation.de>
Content-Type text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id <33FA9037-48BC-46CA-B91B-CC4315676108@kyngchaos.com>
Content-Transfer-Encoding 7bit
From William Kyngesburye <kyngchaos@kyngchaos.com>
Subject Re: [bug #4598] (grass) g.region from raster wrong when crossin 180 deg
Date Sun, 8 Oct 2006 20:21:22 +0900
To Maciek Sieczka via RT <grass-bugs@intevation.de>
X-Mailer Apple Mail (2.752.2)
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
I think I saw this one when I filed my bug.  It's similar and may be  
related.  Since it's all coming from g.region, the same calculations  
somewhere could be causing these different problems.  I never used  
the -l option on my test to see what the center was.  I don't have  
any of that data with me to look at it in the coming week.


Comment | Reply | Take | Resolve

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