7

Does anyone have the last word on why Landsat scenes don't project in the southern hemisphere. This causes no end of trouble in GRASS, less so in QGIS.

What I mean is, take an original scene from USGS, open it in Erdas Viewfinder, go to ImageInfo|Projection and it reports;

Spheroid Name; WGS 84  
Datum Name:    WGS 84  
UTM Zone;      55  
North or South; North

For that scene I can see countryside which I am pretty sure is in the southern hemisphere, that is if I am as well (I am....I think...this is driving me crazy...)

In QGIS if I open a new project and set the CRS to UTM55S EPSG 32755 and then open the Landsat scene, it opens the layer and displays it with sensible (i.e. positive) coordinates, but in the Layer Properties it reports the Layer Spatial Reference System as

+proj=utm +zone=55 +ellps=WGS84 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs

and in the General tab the Coordinate Reference System as

EPSG:32655 - WGS 84 / UTM zone 55N

If I then set the layer CRS to the south, the map jumps out of view, I 'Zoom to extents' and the map displays but with a negative coord.

And then generally all sorts of trouble in GRASS. I am using GRASS.7.svn so perhaps not relevant to report that here. But typically will not display maps unless they are reprojected to the south before importing to GRASS.

I am working around this, but I want to know if it something that is going to 'break' with improvements to GRASS and QGIS, or is it an embedded problem in Landsat and likely that QGIS is mature enough now that this will always be the case.

Further detail comes from the _mtl.txt metadata file which comes with the bands, all of that is reproduced below.

GROUP = L1_METADATA_FILE GROUP = METADATA_FILE_INFO ORIGIN = "Image courtesy of the U.S. Geological Survey" REQUEST_ID = "0101103234777_00001" PRODUCT_CREATION_TIME = 2011-03-23T20:42:47Z STATION_ID = "EDC" LANDSAT5_XBAND = "1" GROUND_STATION = "ASA" LPS_PROCESSOR_NUMBER = 0 DATEHOUR_CONTACT_PERIOD = "1002523" SUBINTERVAL_NUMBER = "01" END_GROUP = METADATA_FILE_INFO GROUP = PRODUCT_METADATA PRODUCT_TYPE = "L1T" ELEVATION_SOURCE = "GLS2000" PROCESSING_SOFTWARE = "LPGS_11.3.0" EPHEMERIS_TYPE = "DEFINITIVE" SPACECRAFT_ID = "Landsat5" SENSOR_ID = "TM" SENSOR_MODE = "BUMPER" ACQUISITION_DATE = 2010-01-25 SCENE_CENTER_SCAN_TIME = 23:59:40.5160690Z WRS_PATH = 93 STARTING_ROW = 84 ENDING_ROW = 84 BAND_COMBINATION = "1234567" PRODUCT_UL_CORNER_LAT = -33.6323837 PRODUCT_UL_CORNER_LON = 143.9028043 PRODUCT_UR_CORNER_LAT = -33.6701041 PRODUCT_UR_CORNER_LON = 146.4800644 PRODUCT_LL_CORNER_LAT = -35.5314421 PRODUCT_LL_CORNER_LON = 143.8314666 PRODUCT_LR_CORNER_LAT = -35.5719202 PRODUCT_LR_CORNER_LON = 146.4680652 PRODUCT_UL_CORNER_MAPX = 212700.000 PRODUCT_UL_CORNER_MAPY = -3725700.000 PRODUCT_UR_CORNER_MAPX = 451800.000 PRODUCT_UR_CORNER_MAPY = -3725700.000 PRODUCT_LL_CORNER_MAPX = 212700.000 PRODUCT_LL_CORNER_MAPY = -3936600.000 PRODUCT_LR_CORNER_MAPX = 451800.000 PRODUCT_LR_CORNER_MAPY = -3936600.000 PRODUCT_SAMPLES_REF = 7971 PRODUCT_LINES_REF = 7031 PRODUCT_SAMPLES_THM = 7971 PRODUCT_LINES_THM = 7031 BAND1_FILE_NAME = "L5093084_08420100125_B10.TIF" BAND2_FILE_NAME = "L5093084_08420100125_B20.TIF" BAND3_FILE_NAME = "L5093084_08420100125_B30.TIF" BAND4_FILE_NAME = "L5093084_08420100125_B40.TIF" BAND5_FILE_NAME = "L5093084_08420100125_B50.TIF" BAND6_FILE_NAME = "L5093084_08420100125_B60.TIF" BAND7_FILE_NAME = "L5093084_08420100125_B70.TIF" GCP_FILE_NAME = "L5093084_08420100125_GCP.txt" METADATA_L1_FILE_NAME = "L5093084_08420100125_MTL.txt" CPF_FILE_NAME = "L5CPF20100101_20100331_09" END_GROUP = PRODUCT_METADATA GROUP = MIN_MAX_RADIANCE LMAX_BAND1 = 193.000 LMIN_BAND1 = -1.520 LMAX_BAND2 = 365.000 LMIN_BAND2 = -2.840 LMAX_BAND3 = 264.000 LMIN_BAND3 = -1.170 LMAX_BAND4 = 221.000 LMIN_BAND4 = -1.510 LMAX_BAND5 = 30.200 LMIN_BAND5 = -0.370 LMAX_BAND6 = 15.303 LMIN_BAND6 = 1.238 LMAX_BAND7 = 16.500 LMIN_BAND7 = -0.150 END_GROUP = MIN_MAX_RADIANCE GROUP = MIN_MAX_PIXEL_VALUE QCALMAX_BAND1 = 255.0 QCALMIN_BAND1 = 1.0 QCALMAX_BAND2 = 255.0 QCALMIN_BAND2 = 1.0 QCALMAX_BAND3 = 255.0 QCALMIN_BAND3 = 1.0 QCALMAX_BAND4 = 255.0 QCALMIN_BAND4 = 1.0 QCALMAX_BAND5 = 255.0 QCALMIN_BAND5 = 1.0 QCALMAX_BAND6 = 255.0 QCALMIN_BAND6 = 1.0 QCALMAX_BAND7 = 255.0 QCALMIN_BAND7 = 1.0 END_GROUP = MIN_MAX_PIXEL_VALUE GROUP = PRODUCT_PARAMETERS CORRECTION_METHOD_GAIN_BAND1 = "CPF" CORRECTION_METHOD_GAIN_BAND2 = "CPF" CORRECTION_METHOD_GAIN_BAND3 = "CPF" CORRECTION_METHOD_GAIN_BAND4 = "CPF" CORRECTION_METHOD_GAIN_BAND5 = "CPF" CORRECTION_METHOD_GAIN_BAND6 = "IC" CORRECTION_METHOD_GAIN_BAND7 = "CPF" CORRECTION_METHOD_BIAS = "IC" SUN_AZIMUTH = 74.7905248 SUN_ELEVATION = 52.8328918 OUTPUT_FORMAT = "GEOTIFF" END_GROUP = PRODUCT_PARAMETERS GROUP = CORRECTIONS_APPLIED STRIPING_BAND1 = "NONE" STRIPING_BAND2 = "NONE" STRIPING_BAND3 = "NONE" STRIPING_BAND4 = "NONE" STRIPING_BAND5 = "NONE" STRIPING_BAND6 = "NONE" STRIPING_BAND7 = "NONE" BANDING = "N" COHERENT_NOISE = "N" MEMORY_EFFECT = "Y" SCAN_CORRELATED_SHIFT = "Y" INOPERABLE_DETECTORS = "N" DROPPED_LINES = "N" END_GROUP = CORRECTIONS_APPLIED GROUP = PROJECTION_PARAMETERS REFERENCE_DATUM = "WGS84" REFERENCE_ELLIPSOID = "WGS84" GRID_CELL_SIZE_THM = 30.000 GRID_CELL_SIZE_REF = 30.000 ORIENTATION = "NUP" RESAMPLING_OPTION = "CC" MAP_PROJECTION = "UTM" END_GROUP = PROJECTION_PARAMETERS GROUP = UTM_PARAMETERS ZONE_NUMBER = 55 END_GROUP = UTM_PARAMETERS END_GROUP = L1_METADATA_FILE END

Improve this question

6 Answers 6

Reset to default
5

The Landsat GeoCover data use a non standard UTM projection for the Southern hemisphere.

All you need to do is assign the Northern projection to the Southern images and it will be in the correct location and you will be able to reproject the images on the fly.

Improve this answer
3
  • In GRASS? And why would USGS be doing "non standard"?
    – BWill
    Commented May 20, 2011 at 4:22
  • 2
    Why are they using non-standard...no idea, sometimes people do strange things :)
    – ujjwalesri
    Commented May 20, 2011 at 4:25
  • 1
    ujjwalesri appears to be right. You should be able to use gdal_warp -s_srs EPSG:32655 -t_srs EPSG:32755 to "fix" it. I guess the main reason there are two hemispheres for each UTM zone is to avoid negative values which isn't a problem if all your data uses the same projection, which presumably is what USGS does. Although it wouldn't surprise me if this was an oversight in the early days of LANDSAT that then had to stay.
    – MerseyViking
    Commented May 20, 2011 at 11:31
3

Problems with southern hemisphere projections for LANDSAT data in GRASS/GDAL seems to exist since long. Here are some discussions in this regard:

  1. [GRASS5] Problems with UTM/southern hemisphere
  2. r.in.gdal unclean import of southern UTM zone
  3. Win7 GRASS 7 & i.landsat.toar, here there's a mention as follows in question

I have taken care to reproject the images properly since there is incorrect metadata for Landsat in the southern hemisphere.

You could also try contacting USGS directly for information via this web form.

Improve this answer
1
  • No 3. would be me starting to tug at my hair a little. Most of it is gone nowadays or at least grey....
    – BWill
    Commented May 20, 2011 at 6:56
3

USGS Landsat imagery is supplied with a Northern Hemisphere UTM projection. Scenes that are in the Southern Hemisphere have negative Y coordinates, this means they will display in the correct location south of the equator. Basically, don't worry about it. If it bothers you, reproject your data.

Improve this answer
2
  • HI lpinner, is the use of negative Y coords consistent with the EPSG standard?
    – BWill
    Commented May 23, 2011 at 6:45
  • 2
    EPSG isn't a 'standard' just a database of well known coordinate reference system definitions. I see no problem with negative coordinates, though it is convention to avoid them.
    – user2856
    Commented May 24, 2011 at 8:28
2
+50

Apologies if this 2nd answer is a faux-pas and I should've edited my previous answer but BWill has asked a different question in his answer.

I have just tested some USGS landsat imagery (as downloaded) in ArcGIS, ENVI, QGIS and GDAL. ArcGIS and ENVI correctly identify the projection and place it correctly in the southern hemisphere. GDAL correctly identifies the projection. However, I suspect there is a bug/feature in QGIS as it is NOT recognising the projection correctly. For the couple of southern hemisphere scenes I just tried - QGIS shows "+proj=longlat +ellps=WGS84 +towgs84=0,0,0,0,0,0,0 +no_defs" which is incorrect (and not what is reported by GDAL). Which is strange, as I'm under the impression that QGIS uses GDAL as its data provider.

Improve this answer
1
  • both ultimately use PROJ.4 to handle projection issues, though they may be linked against different versions or there may be some QGIS specific issue which was introduced.
    – scw
    Commented May 26, 2011 at 3:48
2

The correct definition of 55S is:

# WGS 84 / UTM zone 55S
<32755> +proj=utm +zone=55 +south +ellps=WGS84 +datum=WGS84 +units=m +no_defs  <>

but you have omitted +south above. Hence it fails.

I have been using UTM on southern hemisphere in GRASS without problems.

Improve this answer
2
  • Hi Markus, the text in my post is reproduced from USGS. I haven't omitted anything.... Why would USGS have gone for non-standard metadata? They must have had the expectation that some systems could read the output correctly. Are GRASS and GDAL different to the standard which USGS were working to at the time?
    – BWill
    Commented May 20, 2011 at 15:04
  • I don't know about USGS but GDAL and GRASS follow the EPSG standard for many years.
    – markusN
    Commented May 22, 2011 at 15:34
2

I contacted USGS;

Hi USGS when I use Landsat imagery in GDAL GIS (GRASS and QGIS) I have trouble with scenes which should be projected into the southern hemisphere. What protocol is USGS working to? Is it consistent with EPSG? thanks.

Their reply;

Thank you for contacting the USGS Earth Resources Observation and Science (EROS) Center. The southern UTM Zone projection has been removed to avoid complications with some cartographic products. Although southern hemisphere scenes will incorrectly be tagged as northern hemisphere scenes, the data and coordinates will be accurate and displayed correctly. Best regards, Customer Services Technical Services Support Contract to the USGS Earth Resources Observation and Science Center 47914 - 252nd Street Sioux Falls, SD 57198

So who is right? They did not discuss EPSG and GDAL. Whilst I accept that these are GIS standards and not image processing protocols, what cartographic products do project Landsat correctly in the southern hemisphere?

Even though this is an answer from me the originator, as far as I know with GIS.Stackexchange the bounty still stands!

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.