Opened 15 years ago

Closed 9 years ago

Last modified 9 years ago

#3132 closed defect (duplicate)

Antarctic Polar Stereographic (EPSG:3031) management on GDAL: WKT's Projection is missing

Reported by: danieleromagnoli Owned by: warmerdam
Priority: normal Milestone: 2.0.0
Component: OGR_SRS Version: 1.6.0
Severity: normal Keywords: GTiff Antarctic Polar Stereographic
Cc:

Description (last modified by warmerdam)

Hi, I'm working on a geotiff image which is projected as EPSG:3031 (Antarctic Polar Stereographic). When running the last fwtools's gdalinfo, I get the following:

Coordinate System is:

PROJCS["WGS 84 / Antarctic Polar Stereographic",
    GEOGCS["WGS 84",
        DATUM["WGS_1984",
            SPHEROID["WGS 84",6378137,298.2572235630016,
                AUTHORITY["EPSG","7030"]],
            AUTHORITY["EPSG","6326"]],
        PRIMEM["Greenwich",0],
        UNIT["degree",0.0174532925199433],
        AUTHORITY["EPSG","4326"]],
    UNIT["metre",1,
        AUTHORITY["EPSG","9001"]],
    AUTHORITY["EPSG","3031"]]

It seems that the projection part is missing (taking a look here: http://spatialreference.org/ref/epsg/3031/prettywkt/) Also trying to run a gdal_translate specifying -a_srs EPSG:3031 the projection definition of the newly created tiff is still missing. Does anyone has additional information on that topic?

The sample geotiff is copyright protected, therefore I can't share it.

Change History (9)

comment:1 by drdavis, 15 years ago

Version: 1.6.0

I am working with NITF 2.10 Antarctic images which are in geographic, and need to gdalwarp to polar stereographic. When the images are "north-up", meaning the upper left latitude is a smaller negative value than lower left latitude, gdalwarp reprojects to polar stereographic correctly with "-s_srs EPSG:4326 -t_srs EPSG:3031". If they are ascending scenes, meaning upper left lat. is a larger negative value than lower left lat, gdalwarp converts to either a very long single line or circle.

Is there a way I can instruct gdal to intepret correctly without writing an API?

Input metadata:

Coordinate System is: GEOGCS["WGS 84",

DATUM["WGS_1984",

SPHEROID["WGS 84",6378137,298.257223563,

AUTHORITY["EPSG","7030"]],

TOWGS84[0,0,0,0,0,0,0], AUTHORITY["EPSG","6326"]],

PRIMEM["Greenwich",0,

AUTHORITY["EPSG","8901"]],

UNIT["degree",0.0174532925199433,

AUTHORITY["EPSG","9108"]],

AXIS["Lat",NORTH], AXIS["Long",EAST], AUTHORITY["EPSG","4326"]]

...... Corner Coordinates: Upper Left ( 159.6955107, -77.0350025) (159d41'43.84"E, 77d 2'6.01"S) Lower Left ( 159.6965108, -76.8839974) (159d41'47.44"E, 76d53'2.39"S) Upper Right ( 518.924, -77.041) (518d55'28.16"E, 77d 2'27.61"S) Lower Right ( 518.925, -76.890) (518d55'31.76"E, 76d53'23.99"S) Center ( 339.310, -76.963) (339d18'37.80"E, 76d57'45.00"S)

comment:2 by warmerdam, 14 years ago

Description: modified (diff)
Status: newassigned

I have confirmed that polar stereographic is handled properly when it is coming directly from EPSG (eg. testepsg EPSG:3031) which produces:

PROJCS["WGS 84 / Antarctic Polar Stereographic",
    GEOGCS["WGS 84",
        DATUM["WGS_1984",
            SPHEROID["WGS 84",6378137,298.257223563,
                AUTHORITY["EPSG","7030"]],
            AUTHORITY["EPSG","6326"]],
        PRIMEM["Greenwich",0,
            AUTHORITY["EPSG","8901"]],
        UNIT["degree",0.01745329251994328,
            AUTHORITY["EPSG","9122"]],
        AUTHORITY["EPSG","4326"]],
    UNIT["metre",1,
        AUTHORITY["EPSG","9001"]],
    PROJECTION["Polar_Stereographic"],
    PARAMETER["latitude_of_origin",-71],
    PARAMETER["central_meridian",0],
    PARAMETER["scale_factor",1],
    PARAMETER["false_easting",0],
    PARAMETER["false_northing",0],
    AUTHORITY["EPSG","3031"],
    AXIS["Easting",UNKNOWN],
    AXIS["Northing",UNKNOWN]]

It is possible that this is a geotiff specific issue with polar stereographic support, or possibly it is something that was fixed for another ticket recently. Digging a bit deeper...

comment:3 by warmerdam, 14 years ago

Keywords: GTiff added

I am attaching a small faked up polar stereographic GeoTIFF file and I have confirmed it is not supported by the normalization code in libgeotiff. It produces the following listgeo report with no projection parameters:

Geotiff_Information:
   Version: 1
   Key_Revision: 1.0
   Tagged_Information:
      ModelTiepointTag (2,3):
         0                0                0                
         440720           51320            0                
      ModelPixelScaleTag (1,3):
         60               60               0                
      End_Of_Tags.
   Keyed_Information:
      GTModelTypeGeoKey (Short,1): ModelTypeProjected
      GTRasterTypeGeoKey (Short,1): RasterPixelIsArea
      GeogLinearUnitsGeoKey (Short,1): Linear_Meter
      ProjectedCSTypeGeoKey (Short,1): Unknown-3031
      End_Of_Keys.
   End_Of_Geotiff.

PCS = 3031 (WGS 84 / Antarctic Polar Stereographic)
Projection = 19992 (Antarctic Polar Stereographic)
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    (  440720.000,   51320.000)
Lower Left    (  440720.000,   49400.000)
Upper Right   (  442640.000,   51320.000)
Lower Right   (  442640.000,   49400.000)
Center        (  441680.000,   50360.000)

This needs to be fixed in libgeotiff. That's a bit out of scope for the work I'm doing right now, but I hope to be able to return to it.

comment:4 by Jukka Rahkonen, 9 years ago

The "attached small faked up polar stereographic GeoTIFF file" is missing from the ticket which makes it difficult for me to check how it would behave with current GDAL version.

comment:5 by Even Rouault, 9 years ago

Milestone: 1.10.0
Resolution: fixed
Status: assignedclosed

After some trying, I think the issue has been fixed in GDAL 1.10 with r24422

comment:6 by Even Rouault, 9 years ago

Milestone: 1.10.0
Resolution: fixed
Status: closedreopened

No actually I was wrong the latitude of origin isn't correctly set.

comment:7 by Even Rouault, 9 years ago

Resolution: duplicate
Status: reopenedclosed

Actually this is the same issue as #3220 that has a proposed patch. So closing it as duplicate

comment:8 by Even Rouault, 9 years ago

Milestone: 2.0

And I've just fixed #3220

comment:9 by Even Rouault, 9 years ago

Milestone: 2.02.0.0

Milestone renamed

Note: See TracTickets for help on using tickets.