[GRASS5] New release candidate 3 of GIS Manager 2

[Michael Barton]

Maciek,

I fixed this in the version I just released. Thanks for noting and explaing
this.

Michael
______________________________
Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ  85287-2402
USA

voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton


> From: Maciek Sieczka <werchowyna at epf.pl>
> Date: Fri, 17 Feb 2006 19:21:32 +0100
> To: Michael Barton <michael.barton at asu.edu>
> Cc: <grass5 at grass.itc.it>, <GRASSLIST at baylor.edu>
> Subject: Re: [GRASS5] New release candidate 3 of GIS Manager 2
> 
> On Wed, 15 Feb 2006 16:59:15 -0700
> Michael Barton <michael.barton at asu.edu> wrote:
> 
> Michael,
> 
>> Maciek,
>> 
>> I see what you are talking about. But the GIS Manager is NOT doing
>> this. The zooming in the new GIS Manager does NOT use d.zoom.
> 
> I know. I'm not saying it is. But I'm wondering if gis.m could follow
> it, as it is doing the good thing (except
> https://intevation.de/rt/webrt?serial_num=3961, but this is another
> story).
> 
>> It simply resets the region extents--extents ONLY--by issuing a
>> g.region n=y1 s=y2 e=x1 w=x2 (no change to resolution)
>> 
>> I tried adding the -a flag and it makes no difference.
> 
> When you need to preserve resolution, but the given extents would not
> let you to, you need to specify the input resolution explicitely, which
> you want to be preserved after g.region:
> 
> 
> ### The initial region:
> 
> $ g.region -p
> projection: 1 (UTM)
> zone:       33
> datum:      wgs84
> ellipsoid:  wgs84
> north:      5679546
> south:      5678732
> west:       598654
> east:       599761
> nsres:      1
> ewres:      1
> rows:       814
> cols:       1107
> 
> ### Let's zoom out - not preserving the res, like gis.m does it (bad):
> 
> $ g.region n=5680762.10112026 s=5677880.44652981 w=598415.29951403
> e=600978.962345 -p projection: 1 (UTM)
> zone:       33
> datum:      wgs84
> ellipsoid:  wgs84
> north:      5680762.10112026
> south:      5677880.44652981
> west:       598415.29951403
> east:       600978.962345
> nsres:      0.99988015
> ewres:      0.9998685
> rows:       2882
> cols:       2564
> 
> ### And now zoom out preserving the res, like d.zoom does it (good):
> 
> $ g.region n=5680762.10112026 s=5677880.44652981 w=598415.29951403
> e=600978.962345 res=1 -ap projection: 1 (UTM)
> zone:       33
> datum:      wgs84
> ellipsoid:  wgs84
> north:      5680763
> south:      5677880
> west:       598415
> east:       600979
> nsres:      1
> ewres:      1
> rows:       2883
> cols:       2564
> 
> 
>> It looks like it is some kind of a rounding issue in g.region (or
>> possibly in the OS).
> 
> I guess it's not. Simply g.region does exactly what you are telling it
> to do. Maybe telling it to preserve the input res then would be all that
> we need.
> 
>> In a working context the change is a tiny fraction of a mm in
>> your example below. So it wouldn't make any meaningful difference in
>> most cases.
> 
> It's not about millimeters during display or else. It's about preserving
> the current resolution when zooming. This is a must I believe. You can't
> let your zooming tool to change the working region resolution. Why
> should you?
> 
>> However, it is odd that it happens. Maybe someone who
>> understands the g.region code can explain it.
> 
> I hope so to. I know what I'm seeing only.
> 
> Maciek
> 
> --------------------
> W polskim Internecie s? setki milion?w stron. My przekazujemy Tobie tylko
> najlepsze z nich!
> http://katalog.panoramainternetu.pl/
>