Earth Engine CRS – Why Google Earth Engine Chooses Different CRS for Different Days

coordinate systemcoordinatesgoogle-earth-enginemappingpython

I'm using Google Earth Engine (GEE) with Python API.

I have this polygon:

{"type":"FeatureCollection","features":[{"type":"Feature","properties":{},"geometry":{"type":"Polygon","coordinates":[[[35.470985770225525,32.86172261307505],[35.470733642578125,32.86186680551963],[35.46989679336548,32.86167304686806],[35.469011664390564,32.861911865610494],[35.468518137931824,32.86207858774762],[35.468480587005615,32.858532295271665],[35.470706820487976,32.858446677817426],[35.470985770225525,32.86172261307505]]]}}]}

I downloaded (using ee.batch.Export.image.toDrive) two Sentinel-1 images clipped to the geometry of the polygon:

COPERNICUS/S1_GRD/S1A_IW_GRDH_1SDV_20211217T033539_20211217T033604_041043_04E032_1544
COPERNICUS/S1_GRD/S1A_IW_GRDH_1SDV_20211222T034407_20211222T034432_041116_04E297_CE51

When downloading images this way, GEE saves them as GeoTIFF in local UTM CRS. However, for the first image, the CRS is EPSG:32637 and for the second image, the CRS is EPSG:32636 (which is the correct one).

I wonder why this happens, is it a bug/error maybe?

I know I can specify the CRS in ee.batch.Export.image.toDrive function, but let's assume I have many polygons and I don't know the CRS of each one.

Best Answer

Your polygon intersects with several different Sentinel 1 tiles. The UTM zone (shown in red) is probably taken from the center of a tile, in which case it makes sense they are different for different dates. You could reproject your images to WGS before exporting but it's probably better to keep them in their native UTM projections.

Should you wish to reproject your image collection:

poly = ee.Geometry.Polygon([[35.470985770225525,32.86172261307505],[35.470733642578125,32.86186680551963],[35.46989679336548,32.86167304686806],[35.469011664390564,32.861911865610494],[35.468518137931824,32.86207858774762],[35.468480587005615,32.858532295271665],[35.470706820487976,32.858446677817426],[35.470985770225525,32.86172261307505]])

collection = (ee.ImageCollection("COPERNICUS/S1_GRD")
              .filterBounds(poly)
              .filterDate('2021-01-01', '2022-01-01'))

collectionWGS84 = collection.map(lambda image: image.reproject('EPSG:4326'))

Reproducible example

Your code was unfortunately not reproducible, see here a simple and dummy code, showing the issue with Landsat data:

var geometry = /* color: #0b4a8b */ee.Geometry.Polygon(
        [[[-104.1558837890625, 42.950391774502876],
          [-104.13665771484375, 42.83569550641452],
          [-103.831787109375, 42.85784648372956],
          [-103.84002685546875, 42.95441233121331]]]);

var imageCollection = ee.ImageCollection("LANDSAT/LE07/C01/T2_SR");
var image_one = ee.Image(imageCollection.first())



//Calculating VIs
var ndvi = image_one.normalizedDifference(['B3', 'B4']).rename('NDVI');
var image_one_withNDVI = image_one.addBands(ndvi)
print(image_one_withNDVI, "image_one_withNDVI")

First try: export without toFloat():

Export.image.toDrive({
  image: image_one_withNDVI,
  description: "test_task", 
  fileNamePrefix: "test", 
  region: geometry, 
  scale:30
})

This will return: Error: Exported bands must have compatible data types; found inconsistent types: Int16 and Byte.

Second try, use: ge_one_withNDVI.toFloat()

Export.image.toDrive({
  image: image_one_withNDVI.toFloat(),
  description: "test_task_OK", 
  fileNamePrefix: "test_OK", 
  region: geometry, 
  scale:30
})

Coordinate System – Define Export CRS Option in Google Earth Engine

Earth Engine generates reduced-resolution versions of each image when it is ingested. Part of the upload process involves specifying how the reduced-resolution pixels should be derived -- "mean" is the most common answer, but for categorical data like this "mode" is more appropriate.

I believe the problem here is that (a) this GSW data was inappropriately pyramided with "mean", and (b) because of the somewhat distorted pixels at the high latitudes Earth Engine is choosing to derive your 30m UTM57 pixels from 60m EPSG:4326 pixels.

You can avoid this issue by forcing Earth Engine to work with the full resolution data:

https://code.earthengine.google.com/6ff685f6d52e893701969e42acb60c36

(Note that if you zoom out here things will get very slow and/or run out of memory, since you'll be using a very large number of input pixels for each output pixel, but as long as you view or export at close to 30m you should be fine.)

Best Answer

Related Solutions

Google Earth Engine – How to Make Data Consistent for Exporting with Different Data Types

Reproducible example

Coordinate System – Define Export CRS Option in Google Earth Engine

Related Question