Details Ticket 1492


Comment | Reply | Take | Open


Serial Number 1492
Subject r.in.gdal/GRASS/GDAL: coordinates confusion on southern hemisphere (UTM)
Area bug
Queue grass
Requestors neteler@itc.it
Owner none
Status resolved
Last User Contact Mon Dec 23 17:05:37 2002 (6 yr ago)
Current Priority 30
Final Priority 70
Due No date assigned
Last Action Tue Jan 7 15:17:17 2003 (6 yr ago)
Created Fri Dec 20 18:31:38 2002 (6 yr ago)

Transaction History Ticket 1492


Fri, Dec 20 2002 18:31:38    Request created by guest  
Subject: r.in.gdal/GRASS/GDAL: coordinates confusion on southern hemisphere (UTM)
grass binary for platform: Compiled from Sources

Hi,

when importing a LANDSAT-TM5 into GRASS
Botswana, UTM Zone 35
with r.in.gdal,I get a coordinates confusion.
A sample dataset is here:
ftp://ftp.glcf.umiacs.umd.edu/glcf/Landsat/WRS2/p173/r072/p173r72_5t890625.TM-EarthSat-Orthorectifie
d/
(get the 1st channel, Geotiff).

After importing the TM1 channel, the cell header contains:
proj:       1
zone:       35
north:      -1818499.5
south:      -2018512.5
east:       499120.5
west:       269040
cols:       8073
rows:       7018
e-w resol:  28.5
n-s resol:  28.5
format:     0
compressed: 1

But the region definition in "GRASS speak" is for a southern hemisphere
area:
g.region -pd
projection: 1 (UTM)
zone:       -35
datum:      ** unknown (default: WGS84) **
ellipsoid:  wgs84
north:      8230695
south:      7629900
west:       3600
east:       525060
nsres:      15
ewres:      15
rows:       40053
cols:       34764

Note (the boundary coordinates are not fully overlapping):
 - negative zone (GRASS) vs positive zone (GDAL)
 - positive N/S coordinates (GRASS) vs negative N/S coordinates (GDAL)

Do we have to fix that in GDAL or in r.in.gdal or is the convention
in GRASS for southern hemisphere bad? If the latter, how to solve the
problem (I have several data sets...).

Thanks,

 Markus
Sat, Dec 21 2002 06:26:20    Comments added by fwarmerdam  
Markus,

I downloaded and inspected p173r72_5t890625_nn1.tif.

Listgeo says:

Geotiff_Information:
   Version: 1
   Key_Revision: 1.0
   Tagged_Information:
      ModelTiepointTag (2,3):
         0                0                0                
         269040           -1818499.5       0                
      ModelPixelScaleTag (1,3):
         28.5             28.5             0                
      ModelTransformationTag (4,4):
         28.5             0                0                269040          
0                -28.5            0                -1818499.5       
         0                0                0                0               
0                0                0                1                
      End_Of_Tags.
   Keyed_Information:
      GTModelTypeGeoKey (Short,1): ModelTypeProjected
      GTRasterTypeGeoKey (Short,1): RasterPixelIsPoint
      GeogAngularUnitsGeoKey (Short,1): Angular_Degree
      ProjectedCSTypeGeoKey (Short,1): PCS_WGS84_UTM_zone_35N
      ProjLinearUnitsGeoKey (Short,1): Linear_Meter

PCS = 32635 (WGS 84 / UTM zone 35N)
Projection = 16035 (UTM zone 35N)
Projection Method: CT_TransverseMercator
   ProjNatOriginLatGeoKey: 0.000000 (  0d 0' 0.00"N)
   ProjNatOriginLongGeoKey: 27.000000 ( 27d 0' 0.00"E)
   ProjScaleAtNatOriginGeoKey: 0.999600
   ProjFalseEastingGeoKey: 500000.000000 m
   ProjFalseNorthingGeoKey: 0.000000 m
GCS: 4326/WGS 84
Datum: 6326/World Geodetic System 1984
Ellipsoid: 7030/WGS 84 (6378137.00,6356752.31)
Prime Meridian: 8901/Greenwich (0.000000/  0d 0' 0.00"E)
Projection Linear Units: 9001/metre (1.000000m)

Corner Coordinates:
Upper Left    ( 269040.000,-1818499.500)  ( 24d50'13.19"E, 16d26'12.90"S)
Lower Left    ( 269040.000,-2018512.500)  ( 24d48'56.57"E, 18d14'36.86"S)
Upper Right   ( 499120.500,-1818499.500)  ( 26d59'30.34"E, 16d26'53.05"S)
Lower Right   ( 499120.500,-2018512.500)  ( 26d59'30.05"E, 18d15'21.72"S)
Center        ( 384080.250,-1918506.000)  ( 25d54'32.35"E, 17d20'56.82"S)

The lat/long extents look fine for Botswana but the funny thing is that
the UTM coordinates are in terms of UTM 35 *North*.  That is why it has
the funky negative northing coordinates, where as the southern equivelent
zone would add 10000000 to the Y coordinates. 

Anyways, so far I don't see any obvious bug other than that the files
were generated with a preculiar (northing) projection.  
Sun, Dec 22 2002 18:38:15    Mail sent by wolfluck@mweb.co.za  
Return-Path <wolfluck@mweb.co.za>
Delivered-To grass-bugs@lists.intevation.de
To Request Tracker <grass-bugs@intevation.de>
From wolfluck@mweb.co.za
Subject Re: [GRASS5] [bug #1492] (grass) r.in.gdal/GRASS/GDAL: coordinates
Date Sun, 22 Dec 2002 17:38:05 GMT
X-Posting-IP 196.44.133.64
X-Mailer Endymion MailMan
Message-Id <E18Q9rL-0003IT-00@rammstein.mweb.co.za>
X-Spam-Status No, hits=1.6 required=5.0 tests=NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_03_05 version=2.43
X-Spam-Level *
Hi

This is not unique to GDAL, other software such as ARC/INFO and ERDAS Imagine
also define
UTM for the Southern Hemisphere differently. One should just be aware of this
and be able
to edit the coordinates of a raster file or imagery group, later on.

Wolfgang

> this bug's URL: http://intevation.de/rt/webrt?serial_num=1492
> -------------------------------------------------------------------------
> 
> Subject: r.in.gdal/GRASS/GDAL: coordinates confusion on southern hemisphere
(UTM)
> 
> grass binary for platform: Compiled from Sources
> 
> Hi,
> 
> when importing a LANDSAT-TM5 into GRASS
> Botswana, UTM Zone 35
> with r.in.gdal,I get a coordinates confusion.
> A sample dataset is here:
>
ftp://ftp.glcf.umiacs.umd.edu/glcf/Landsat/WRS2/p173/r072/p173r72_5t890625.TM-EarthSat-Orthorectifie
d/
> 
> (get the 1st channel, Geotiff).
> 
> After importing the TM1 channel, the cell header contains:
> proj:       1
> zone:       35
> north:      -1818499.5
> south:      -2018512.5
> east:       499120.5
> west:       269040
> cols:       8073
> rows:       7018
> e-w resol:  28.5
> n-s resol:  28.5
> format:     0
> compressed: 1
> 
> But the region definition in "GRASS speak" is for a southern hemisphere
> area:
> g.region -pd
> projection: 1 (UTM)
> zone:       -35
> datum:      ** unknown (default: WGS84) **
> ellipsoid:  wgs84
> north:      8230695
> south:      7629900
> west:       3600
> east:       525060
> nsres:      15
> ewres:      15
> rows:       40053
> cols:       34764
> 
> Note (the boundary coordinates are not fully overlapping):
>  - negative zone (GRASS) vs positive zone (GDAL)
>  - positive N/S coordinates (GRASS) vs negative N/S coordinates (GDAL)
> 
> Do we have to fix that in GDAL or in r.in.gdal or is the convention
> in GRASS for southern hemisphere bad? If the latter, how to solve the
> problem (I have several data sets...).
> 
> Thanks,
> 
>  Markus
> 
> 
> -------------------------------------------- Managed by Request Tracker
> 
> _______________________________________________
> grass5 mailing list
> grass5@grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass5


---------------------------------------------
This message was sent using M-Web Airmail.
JUST LIKE THAT
Are you ready for 10-digit dialling?
To find out how this will affect your Internet connection go to www.mweb.co.za/ten
http://airmail.mweb.co.za/


Mon, Dec 23 2002 10:10:00    Mail sent by neteler@itc.it  
Return-Path <neteler@itc.it>
Delivered-To grass-bugs@lists.intevation.de
Date Mon, 23 Dec 2002 10:09:56 +0100
From Markus Neteler <neteler@itc.it>
To Request Tracker <grass-bugs@intevation.de>
Cc grass5 developers list <grass5@grass.itc.it>
Subject Re: [bug #1492] (grass) r.in.gdal/GRASS/GDAL: coordinates
Message-ID <20021223100956.B1277@itc.it>
Mail-Followup-To Request Tracker <grass-bugs@intevation.de>, grass5 developers list <grass5@grass.itc.it>
References <20021222173815.754F113AD2@lists.intevation.de>
Mime-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Disposition inline
User-Agent Mutt/1.2.5.1i
In-Reply-To <20021222173815.754F113AD2@lists.intevation.de>; from grass-bugs@intevation.de on Sun, Dec 22, 2002 at 06:38:15PM +0100
X-Spam-Status No, hits=-5.1 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_SPARSE,SPAM_PHRASE_02_03,USER_AGENT, USER_AGENT_MUTT version=2.43
X-Spam-Level
On Sun, Dec 22, 2002 at 06:38:15PM +0100, Request Tracker wrote:
> Hi
> 
> This is not unique to GDAL, other software such as ARC/INFO and ERDAS Imagine
also define
> UTM for the Southern Hemisphere differently. One should just be aware of this
and be able
> to edit the coordinates of a raster file or imagery group, later on.

Hi Wolfgang, hi all,
 
perhaps we should modify r.in.gdal to take care of this modification
automagically (in case GDAL send a negative UTM zone)?

But I just see that *GDAL* gets it wrong:

gdalinfo p174r73_5t900416_nn1.tif
Driver: GTiff/GeoTIFF
Size is 8191, 7172
Coordinate System is:
PROJCS["WGS 84 / UTM zone 34N",
    GEOGCS["WGS 84",
        DATUM["WGS_1984",
            SPHEROID["WGS 84",6378137,298.2572235629972,
                AUTHORITY["EPSG","7030"]],
            AUTHORITY["EPSG","6326"]],
        PRIMEM["Greenwich",0],
        UNIT["degree",0.0174532925199433],
        AUTHORITY["EPSG","4326"]],
    AUTHORITY["EPSG","32634"],
    PROJECTION["Transverse_Mercator"],
    PARAMETER["latitude_of_origin",0],
    PARAMETER["central_meridian",21],
    PARAMETER["scale_factor",0.9996],
    PARAMETER["false_easting",500000],
    PARAMETER["false_northing",0],
    UNIT["metre",1,
        AUTHORITY["EPSG","9001"]]]
Origin = (701128.500000,-1977985.500000)
Pixel Size = (28.500000,-28.500000)
Corner Coordinates:
Upper Left  (  701128.500,-1977985.500) ( 22d53'54.03"E, 17d52'49.72"S)
Lower Left  (  701128.500,-2182387.500) ( 22d55'9.01"E, 19d43'36.50"S)
Upper Right (  934572.000,-1977985.500) ( 25d 5'55.19"E, 17d50'47.82"S)
Lower Right (  934572.000,-2182387.500) ( 25d 8'36.64"E, 19d41'21.06"S)
Center      (  817850.250,-2080186.500) ( 24d 0'54.24"E, 18d47'20.73"S)
Band 1 Block=8191x1 Type=Byte, ColorInterp=Gray
  Overviews: 1024x897

LANDSAT 173/73 is in Botswana, so GDAL should report UTM zone 34S.

I'll post this to the GDAL bugtracker.

 Markus


> > this bug's URL: http://intevation.de/rt/webrt?serial_num=1492
> > -------------------------------------------------------------------------
> > 
> > Subject: r.in.gdal/GRASS/GDAL: coordinates confusion on southern hemisphere
(UTM)
> > 
> > grass binary for platform: Compiled from Sources
> > 
> > Hi,
> > 
> > when importing a LANDSAT-TM5 into GRASS
> > Botswana, UTM Zone 35
> > with r.in.gdal,I get a coordinates confusion.
> > A sample dataset is here:
> >
> ftp://ftp.glcf.umiacs.umd.edu/glcf/Landsat/WRS2/p173/r072/p173r72_5t890625.TM-EarthSat-Orthorectif
ied/
> 
> > 
> > (get the 1st channel, Geotiff).
> > 
> > After importing the TM1 channel, the cell header contains:
> > proj:       1
> > zone:       35
> > north:      -1818499.5
> > south:      -2018512.5
> > east:       499120.5
> > west:       269040
> > cols:       8073
> > rows:       7018
> > e-w resol:  28.5
> > n-s resol:  28.5
> > format:     0
> > compressed: 1
> > 
> > But the region definition in "GRASS speak" is for a southern hemisphere
> > area:
> > g.region -pd
> > projection: 1 (UTM)
> > zone:       -35
> > datum:      ** unknown (default: WGS84) **
> > ellipsoid:  wgs84
> > north:      8230695
> > south:      7629900
> > west:       3600
> > east:       525060
> > nsres:      15
> > ewres:      15
> > rows:       40053
> > cols:       34764
> > 
> > Note (the boundary coordinates are not fully overlapping):
> >  - negative zone (GRASS) vs positive zone (GDAL)
> >  - positive N/S coordinates (GRASS) vs negative N/S coordinates (GDAL)
> > 
> > Do we have to fix that in GDAL or in r.in.gdal or is the convention
> > in GRASS for southern hemisphere bad? If the latter, how to solve the
> > problem (I have several data sets...).
> > 
> > Thanks,
> > 
> >  Markus
> > 
> > 
> > -------------------------------------------- Managed by Request Tracker
> > 
> > _______________________________________________
> > grass5 mailing list
> > grass5@grass.itc.it
> > http://grass.itc.it/mailman/listinfo/grass5
> 
> 
> ---------------------------------------------
> This message was sent using M-Web Airmail.
> JUST LIKE THAT
> Are you ready for 10-digit dialling?
> To find out how this will affect your Internet connection go to www.mweb.co.za/ten
> http://airmail.mweb.co.za/
> 
> 
> --- Headers Follow ---
> 
> >From wolfluck@mweb.co.za  Sun Dec 22 18:38:12 2002
> Return-Path: <wolfluck@mweb.co.za>
> Delivered-To: grass-bugs@lists.intevation.de
> Received: from mail.intevation.de (aktaia [212.95.126.10])
> 	by lists.intevation.de (Postfix) with ESMTP id D2C8C13942
> 	for <grass-bugs@lists.intevation.de>; Sun, 22 Dec 2002 18:38:12 +0100 (CET)
> Received: from rammstein.mweb.co.za (rammstein.mweb.co.za [196.2.53.175])
> 	by mail.intevation.de (Postfix) with ESMTP id E71B51C7F5
> 	for <grass-bugs@intevation.de>; Sun, 22 Dec 2002 18:38:09 +0100 (CET)
> Received: from air.mweb.co.za ([196.2.53.154] helo=Debug)
> 	by rammstein.mweb.co.za with smtp (Exim 3.33 #1)
> 	id 18Q9rL-0003IT-00
> 	for grass-bugs@intevation.de; Sun, 22 Dec 2002 19:25:51 +0200
> To: Request Tracker <grass-bugs@intevation.de>
> From: wolfluck@mweb.co.za
> Subject: Re: [GRASS5] [bug #1492] (grass) r.in.gdal/GRASS/GDAL: coordinates
> Date: Sun, 22 Dec 2002 17:38:05 GMT
> X-Posting-IP: 196.44.133.64
> X-Mailer: Endymion MailMan  
> Message-Id: <E18Q9rL-0003IT-00@rammstein.mweb.co.za>
> X-Spam-Status: No, hits=1.6 required=5.0
> 	tests=NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_03_05
> 	version=2.43
> X-Spam-Level: *
> 
> -------------------------------------------- Managed by Request Tracker

-- 
Markus Neteler

ITC-irst, Istituto per la Ricerca Scientifica e Tecnologica
      Project on Predictive Models for the Environment    
Via Sommarive, 18        -       38050 Povo (Trento), Italy
tel +39 0461 314 520 (fax -591)           http://mpa.itc.it


Mon, Dec 23 2002 13:23:59    Mail sent by mneteler  
Frank,

sorry, I didn't see your comment (only "Reply" is sent to the requestor,
comment is silently added to the list).

> The lat/long extents look fine for Botswana but the funny thing is that
> the UTM coordinates are in terms of UTM 35 *North*.  That is why it has
> the funky negative northing coordinates, where as the southern equivelent
> zone would add 10000000 to the Y coordinates. 
> 
> Anyways, so far I don't see any obvious bug other than that the files
> were generated with a preculiar (northing) projection.  

Do you have any suggestion to fix the data? Can I use
geotifcp
to fix the wrong UTM tag?

Markus
Mon, Dec 23 2002 17:05:37    Mail sent by warmerdam@pobox.com  
Return-Path <warmerda@gdal.velocet.ca>
Delivered-To grass-bugs@lists.intevation.de
Date Mon, 23 Dec 2002 11:05:30 -0500
From Frank Warmerdam <warmerdam@pobox.com>
To Markus Neteler via RT <grass-bugs@intevation.de>
Subject Re: [bug #1492] (grass) r.in.gdal/GRASS/GDAL: coordinates confusion on southern hemisphere (UTM)
Message-ID <20021223160530.GA32607@gdal.velocet.ca>
References <20021223122400.290F313AD1@lists.intevation.de>
Mime-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Disposition inline
In-Reply-To <20021223122400.290F313AD1@lists.intevation.de>
User-Agent Mutt/1.4i
Sender Frank Warmerdam <warmerda@gdal.velocet.ca>
X-Spam-Status No, hits=-3.3 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MUTT version=2.43
X-Spam-Level
On Mon, Dec 23, 2002 at 01:24:00PM +0100, Markus Neteler via RT wrote:
> > The lat/long extents look fine for Botswana but the funny thing is that
> > the UTM coordinates are in terms of UTM 35 *North*.  That is why it has
> > the funky negative northing coordinates, where as the southern equivelent
> > zone would add 10000000 to the Y coordinates. 
> > 
> > Anyways, so far I don't see any obvious bug other than that the files
> > were generated with a preculiar (northing) projection.  
> 
> Do you have any suggestion to fix the data? Can I use
> geotifcp
> to fix the wrong UTM tag?

Markus,

The GeoTIFF files could be fixed up with listgeo and geotiffcp.  
Alternatively, you should be able to fix it up in GRASS shouldn't you?

Later,

-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent


Mon, Dec 23 2002 17:16:37    Mail sent by neteler@itc.it  
Return-Path <neteler@itc.it>
Delivered-To grass-bugs@lists.intevation.de
Date Mon, 23 Dec 2002 17:16:34 +0100
From Markus Neteler <neteler@itc.it>
To Frank Warmerdam via RT <grass-bugs@intevation.de>
Subject Re: [bug #1492] (grass) r.in.gdal/GRASS/GDAL: coordinates confusion on southern hemisphere (UTM)
Message-ID <20021223171634.P1277@itc.it>
References <20021223160537.DA53913AD2@lists.intevation.de>
Mime-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Disposition inline
User-Agent Mutt/1.2.5.1i
In-Reply-To <20021223160537.DA53913AD2@lists.intevation.de>; from grass-bugs@intevation.de on Mon, Dec 23, 2002 at 05:05:37PM +0100
X-Spam-Status No, hits=-3.0 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT,USER_AGENT_MUTT version=2.43
X-Spam-Level
On Mon, Dec 23, 2002 at 05:05:37PM +0100, Frank Warmerdam via RT wrote:
> On Mon, Dec 23, 2002 at 01:24:00PM +0100, Markus Neteler via RT wrote:
> > > The lat/long extents look fine for Botswana but the funny thing is that
> > > the UTM coordinates are in terms of UTM 35 *North*.  That is why it has
> > > the funky negative northing coordinates, where as the southern equivelent
> > > zone would add 10000000 to the Y coordinates. 
> > > 
> > > Anyways, so far I don't see any obvious bug other than that the files
> > > were generated with a preculiar (northing) projection.  
> > 
> > Do you have any suggestion to fix the data? Can I use
> > geotifcp
> > to fix the wrong UTM tag?
> 
> Markus,
> 
> The GeoTIFF files could be fixed up with listgeo and geotiffcp.  
> Alternatively, you should be able to fix it up in GRASS shouldn't you?

Both I tried hard without success.

The 1.1.4 geotiffcp does not strip off TIFFTags as the man page says,
the CVS version doesn't compile...

I'll try harder,

 Markus


Tue, Jan 7 2003 15:17:12    Comments added by mneteler  
OK< in fact the GSFC data are wrong (wrong GeoTIFF flags).
With libgeotiff/geotiffcp I was able to fix that.

I am not yet sure of the "location=" create parameter works
well for southern hemisphere, but I don't care now.

Closing the "bug" report,

 Markus
Tue, Jan 7 2003 15:17:17    Status changed to resolved by mneteler  
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