[GRASS-dev] g.proj/g.region different UTm zones

Hi

6.3 CVS 2006.11.10

I'm wondering why the 'g.region -p' and 'g.proj -p' return different
UTM zones:

$ g.proj -p
-PROJ_INFO-------------------------------------------------
name : UTM
datum : wgs84
towgs84 : 0.000,0.000,0.000
proj : utm
ellps : wgs84
a : 6378137.0000000000
es : 0.0066943800
f : 298.2572235630
zone : 35
-PROJ_UNITS------------------------------------------------
unit : meter
units : meters
meters : 1.0

$ g.region -p
projection: 1 (UTM)
zone: 0
datum: wgs84
ellipsoid: wgs84
north: 4260094.61044678
south: 4259866.85324284
west: 591019.57338036
east: 591322.93463532
nsres: 1.99787021
ewres: 1.99579773
rows: 114
cols: 152
cells: 17328

The zone information is there in the PROJ_INFO:

name: UTM
datum: wgs84
towgs84: 0.000,0.000,0.000
proj: utm
ellps: wgs84
a: 6378137.0000000000
es: 0.0066943800
f: 298.2572235630
zone: 35

There were some changes in proj by Paul on 11.04-07.

Maciek

Hello Maciek
How and when was the location created? The inconsistency is probably from then.

Paul

On Tue, 14 Nov 2006, Maciej Sieczka wrote:

Hi

6.3 CVS 2006.11.10

I'm wondering why the 'g.region -p' and 'g.proj -p' return different
UTM zones:

$ g.proj -p
-PROJ_INFO-------------------------------------------------
name : UTM
datum : wgs84
towgs84 : 0.000,0.000,0.000
proj : utm
ellps : wgs84
a : 6378137.0000000000
es : 0.0066943800
f : 298.2572235630
zone : 35
-PROJ_UNITS------------------------------------------------
unit : meter
units : meters
meters : 1.0

$ g.region -p
projection: 1 (UTM)
zone: 0
datum: wgs84
ellipsoid: wgs84
north: 4260094.61044678
south: 4259866.85324284
west: 591019.57338036
east: 591322.93463532
nsres: 1.99787021
ewres: 1.99579773
rows: 114
cols: 152
cells: 17328

The zone information is there in the PROJ_INFO:

name: UTM
datum: wgs84
towgs84: 0.000,0.000,0.000
proj: utm
ellps: wgs84
a: 6378137.0000000000
es: 0.0066943800
f: 298.2572235630
zone: 35

There were some changes in proj by Paul on 11.04-07.

Maciek

Paul Kelly wrote:

Hello Maciek
How and when was the location created?

Just a while ago, using the interactive region setup.

Maciek

On Tue, 14 Nov 2006, Maciej Sieczka wrote:

Paul Kelly wrote:

Hello Maciek
How and when was the location created?

Just a while ago, using the interactive region setup.

Perhaps related to Glynn's recent changes to g.setproj then? The code was so complicated there it would be very easy for any changes to have unintended effects. One reason I have steered clear from g.setproj as much as possible!

Paul

Paul Kelly wrote:

On Tue, 14 Nov 2006, Maciej Sieczka wrote:

Paul Kelly wrote:

How and when was the location created?

Just a while ago, using the interactive region setup.

Perhaps related to Glynn's recent changes to g.setproj then?

The projection is set fine I guess. The UTM zone number set (35) is
present in PROJ_INFO (see my first email). The correct zone number is
reported by g.proj -p. But g.region -p returns "zone: 0" istead
of "zone: 35". Hmm.

Maciek

On Tue, 14 Nov 2006, Maciej Sieczka wrote:

Paul Kelly wrote:

On Tue, 14 Nov 2006, Maciej Sieczka wrote:

Paul Kelly wrote:

How and when was the location created?

Just a while ago, using the interactive region setup.

Perhaps related to Glynn's recent changes to g.setproj then?

The projection is set fine I guess. The UTM zone number set (35) is
present in PROJ_INFO (see my first email). The correct zone number is
reported by g.proj -p. But g.region -p returns "zone: 0" istead
of "zone: 35". Hmm.

Sorry I wasn't clear. The zone number reported by g.region is the one in the WIND file. What I was suggesting is this is no longer being set properly. I know it's a total mess having it in two places and is a remnant of the 80s when GRASS only supported UTM, but IMHO it is too much effort to wipe out all remnants of the old system so I just try to keep the two consistent whenever possible.

Paul

Paul Kelly wrote:

>> How and when was the location created?
>
> Just a while ago, using the interactive region setup.

Perhaps related to Glynn's recent changes to g.setproj then? The code was
so complicated there it would be very easy for any changes to have
unintended effects. One reason I have steered clear from g.setproj as much
as possible!

I've committed this change:

--- general/g.setproj/proj-desc.table 1 Oct 2006 21:18:05 -0000 2.1
+++ general/g.setproj/proj-desc.table 15 Nov 2006 04:16:41 -0000 2.2
@@ -40,4 +40,4 @@
WFACT:float:W:W factor
X0:float:x_0:False Easting
Y0:float:y_0:False Northing
-ZONE:int:zone:Projection Zone
+ZONE:zone:zone:Projection Zone

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