Thu, May 18 2006
17:17:10
|
|
Request created by guest
|
|
Subject: g.region: nsres & ewres are rounded differently
Platform: GNU/Linux/x86
grass obtained from: CVS
grass binary for platform: Compiled from Sources
GRASS Version: 2006-05-18
Hi
nsres & ewres are rounded differently when setting res to something near the
decimal places limit.
In [1] both nsres & ewres are rounded-down to 1.12345678 when requested res=1.123456784.
That's OK.
But in [2], when requested one decimal point higher res=1.123456785, nsres is
rounded-up to 1.12345679 while ewres is rounded-down to 1.12345678.
Moreover, next g.region run [3] with settings identical like in [2] results in
ewres=nsres=1.12345678, and, naturaly, different region extent.
Is this all OK? I thought each single, identical g.region run should result in
the exactly same region settings.
[1]
$ g.region res=1.123456784 -ap
projection: 1 (UTM)
zone: 33
datum: wgs84
ellipsoid: wgs84
north: 5687680.84554222
south: 5673969.0554935
west: 593389.65108669
east: 603210.91029242
nsres: 1.12345678
ewres: 1.12345678
rows: 12205
cols: 8742
[2]
$ g.region res=1.123456785 -ap
projection: 1 (UTM)
zone: 33
datum: wgs84
ellipsoid: wgs84
north: 5687680.85060488
south: 5673967.93708717
west: 593388.52815808
east: 603210.91082934
nsres: 1.12345678
ewres: 1.12345679
rows: 12206
cols: 8743
[3]
$ g.region res=1.123456785 -ap
projection: 1 (UTM)
zone: 33
datum: wgs84
ellipsoid: wgs84
north: 5687680.85060488
south: 5673966.81363039
west: 593387.4047013
east: 603212.03428612
nsres: 1.12345679
ewres: 1.12345679
rows: 12207
cols: 8745
Maciek
|
|
Thu, May 18 2006
18:54:38
|
|
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 |
<17516.42696.506068.75491@cerise.gclements.plus.com>
|
Date |
Thu, 18 May 2006 17:54:32 +0100
|
To |
Request Tracker <grass-bugs@intevation.de>
|
Cc |
grass-dev@grass.itc.it
|
Subject |
Re: [GRASS-dev] [bug #4469] (grass) g.region: nsres & ewres are rounded differently
|
In-Reply-To |
<20060518151710.BDCDF1006C5@lists.intevation.de>
|
References |
<20060518151710.BDCDF1006C5@lists.intevation.de>
|
X-Mailer |
VM 7.07 under 21.4 (patch 15) "Security Through Obscurity" XEmacs Lucid
|
X-Spam-Status |
No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
|
X-Spam-Level |
|
Request Tracker wrote:
> this bug's URL: http://intevation.de/rt/webrt?serial_num=4469
> -------------------------------------------------------------------------
>
> Subject: g.region: nsres & ewres are rounded differently
>
> Platform: GNU/Linux/x86
> grass obtained from: CVS
> grass binary for platform: Compiled from Sources
> GRASS Version: 2006-05-18
>
> Hi
>
> nsres & ewres are rounded differently when setting res to something
> near the decimal places limit.
>
> In [1] both nsres & ewres are rounded-down to 1.12345678 when
> requested res=1.123456784. That's OK.
>
> But in [2], when requested one decimal point higher res=1.123456785,
> nsres is rounded-up to 1.12345679 while ewres is rounded-down to
> 1.12345678.
>
> Moreover, next g.region run [3] with settings identical like in [2]
> results in ewres=nsres=1.12345678, and, naturaly, different region
> extent.
>
> Is this all OK? I thought each single, identical g.region run should
> result in the exactly same region settings.
If you only specify the res= option, the new bounds will depend upon
the previous bounds.
Ultimately, a region is defined by its bounds and the number of rows
and columns. The resolution is derived from those values, and it may
not be possible to get exactly the value which you requested (as the
result of dividing a floating-point number by an integer may not be
exactly representable as a floating-point number).
The alternative (i.e. to define a region by one corner, the
resolution, and the number of rows and columns, with the other corner
being derived), would be signficantly more awkward to write code for.
--
Glynn Clements <glynn@gclements.plus.com>
|
|
Thu, May 18 2006
19:56:29
|
|
Mail sent by adanner@cs.duke.edu
|
|
Return-Path |
<adanner@cs.duke.edu>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
Subject |
Re: [GRASS-dev] [bug #4469] (grass) g.region: nsres & ewres are rounded differently
|
From |
Andrew Danner <adanner@cs.duke.edu>
|
To |
Glynn Clements <glynn@gclements.plus.com>
|
Cc |
Request Tracker <grass-bugs@intevation.de>, grass-dev@grass.itc.it
|
In-Reply-To |
<17516.42696.506068.75491@cerise.gclements.plus.com>
|
References |
<20060518151710.BDCDF1006C5@lists.intevation.de> <17516.42696.506068.75491@cerise.gclements.plus.com>
|
Content-Type |
text/plain
|
Date |
Thu, 18 May 2006 13:56:12 -0400
|
Message-Id |
<1147974972.6378.73.camel@stuck.cs.duke.edu>
|
Mime-Version |
1.0
|
X-Mailer |
Evolution 2.4.2.1
|
Content-Transfer-Encoding |
7bit
|
X-Spam-Status |
No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
|
X-Spam-Level |
|
I was going to suggest adding a flag to support keeping the resolution
fixed and adjusting the bounds instead, but it appears it is already
there. The -a flag aligns to bounds, so if you type
g.region res=1.23456 -a
the n,s,e, and w bounds will adjust slightly (less than one pixel width)
to keep the resolution fixed at the user specified value.
Though the -a flag works in a strange way in my opinion, it shifts the
boundaries instead of expanding/contracting the boundaries.
Example
g.region rast=test -p
north: 603580
south: 590120
west: 2455900
east: 2465980
nsres: 20
ewres: 20
rows: 673
cols: 504
//nsres gets re-adjusted
g.region rast=test res=40 -p
north: 603580
south: 590120
west: 2455900
east: 2465980
nsres: 39.94065282
ewres: 40
rows: 337
cols: 252
//nsres stays fixed, north and south are shifted
//east and west are also shifted even though they didn't need
//to be adjusted
g.region rast=test res=40 -ap
north: 603600
south: 590120
west: 2455880
east: 2466000
nsres: 40
ewres: 40
rows: 337
cols: 253
I would prefer that either the region boundary be expanded or contracted
by a small amount and not shifted. Let say your original raster is just
the right size and data fills every pixel. If you enlarge the boundary
(rounding up) on the res adjustment, some pixels extend into regions of
possible no data. If you contract the region (round down), you will have
valid data for the entire boundary. If you shift, as is currently the
case, the west/south edges are ok, but east and north may extend into a
no data region.
I think the -a flag is useful for when you want to preserve a particular
res= setting, but the behavior is a little odd.
-Andy
On Thu, 2006-05-18 at 17:54 +0100, Glynn Clements wrote:
> Request Tracker wrote:
>
> > this bug's URL: http://intevation.de/rt/webrt?serial_num=4469
> > -------------------------------------------------------------------------
> >
> > Subject: g.region: nsres & ewres are rounded differently
> >
> > Platform: GNU/Linux/x86
> > grass obtained from: CVS
> > grass binary for platform: Compiled from Sources
> > GRASS Version: 2006-05-18
> >
> > Hi
> >
> > nsres & ewres are rounded differently when setting res to something
> > near the decimal places limit.
> >
> > In [1] both nsres & ewres are rounded-down to 1.12345678 when
> > requested res=1.123456784. That's OK.
> >
> > But in [2], when requested one decimal point higher res=1.123456785,
> > nsres is rounded-up to 1.12345679 while ewres is rounded-down to
> > 1.12345678.
> >
> > Moreover, next g.region run [3] with settings identical like in [2]
> > results in ewres=nsres=1.12345678, and, naturaly, different region
> > extent.
> >
> > Is this all OK? I thought each single, identical g.region run should
> > result in the exactly same region settings.
>
> If you only specify the res= option, the new bounds will depend upon
> the previous bounds.
>
> Ultimately, a region is defined by its bounds and the number of rows
> and columns. The resolution is derived from those values, and it may
> not be possible to get exactly the value which you requested (as the
> result of dividing a floating-point number by an integer may not be
> exactly representable as a floating-point number).
>
> The alternative (i.e. to define a region by one corner, the
> resolution, and the number of rows and columns, with the other corner
> being derived), would be signficantly more awkward to write code for.
>
|
|
Fri, May 19 2006
07:26:21
|
|
Mail sent by hamish_nospam@yahoo.com
|
|
Return-Path |
<hamish_nospam@yahoo.com>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
Date |
Fri, 19 May 2006 17:25:59 +1200
|
From |
Hamish <hamish_nospam@yahoo.com>
|
To |
Andrew Danner <adanner@cs.duke.edu>
|
Cc |
grass-bugs@intevation.de, grass-dev@grass.itc.it
|
Subject |
Re: [GRASS-dev] [bug #4469] (grass) g.region: nsres & ewres are rounded differently
|
Message-Id |
<20060519172559.6e7b7b14.hamish_nospam@yahoo.com>
|
In-Reply-To |
<1147974972.6378.73.camel@stuck.cs.duke.edu>
|
References |
<20060518151710.BDCDF1006C5@lists.intevation.de> <17516.42696.506068.75491@cerise.gclements.plus.com> <1147974972.6378.73.camel@stuck.cs.duke.edu>
|
X-Mailer |
Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu)
|
X-Face |
M<EoB)"*Z~u!,vFhXmw}R_KbdBta*P_=T|rbBL'e1/CQ9;/1g\BU3&!=y8ria$2Uk!HT&BB 8i?|X_+7~1jsy}F~g$2va%3fV`*=L(*cem[@3\yg,G,@rg6/QMJ
|
Mime-Version |
1.0
|
Content-Type |
text/plain; charset=US-ASCII
|
Content-Transfer-Encoding |
7bit
|
X-Spam-Status |
No, hits=-4.0 tagged_above=-999.0 required=3.0 tests=BAYES_00, FORGED_YAHOO_RCVD
|
X-Spam-Level |
|
> I would prefer that either the region boundary be expanded or
> contracted by a small amount and not shifted. Let say your original
> raster is just the right size and data fills every pixel. If you
> enlarge the boundary (rounding up) on the res adjustment, some pixels
> extend into regions of possible no data. If you contract the region
> (round down), you will have valid data for the entire boundary. If you
> shift, as is currently the case, the west/south edges are ok, but east
> and north may extend into a no data region.
>
> I think the -a flag is useful for when you want to preserve a
> particular res= setting, but the behavior is a little odd.
It should crop to fit in the x-monitor display?
also watch out for the situation where cells don't align with 10^x,
(grid coords vs cell center conventions)
g.region s=100025 n=101075 res=50
d.zoom will shift to s=100000 n=101050 and data will be shifted in both
x,y by 25m.
Hamish
|
|
Wed, Jul 26 2006
18:41:29
|
|
User changed to tutey@o2.pl by msieczka
|
|
Wed, Jul 26 2006
18:42:09
|
|
User changed to adanner@cs.duke.edu,tutey@o2.pl by msieczka
|
|