Closed giswqs closed 7 months ago
@spatialthoughts I encountered the same issue with your xee notebook example - extracting_time_series_xee.ipynb. Even though you open the dataset with crs='EPSG:32643'
, the XY coordinates are still in EPSG:4326
. This is problematic when trying to save the image with image.rio.to_raster()
. The output crs is always EPSG:4326
.
Yes. This is a bug. It uses the specified CRS and resolution to request the pixels, but the result is always in EPSG:4326. One must explicitly reproject it to another CRS before saving the raster. There is a FR open for this https://github.com/google/Xee/issues/45
Actually this was reported in https://github.com/google/Xee/issues/96 and seems to be fixed already.
@spatialthoughts Thank you for looking into this. I can confirm that the crs issue has been fixed by @boothmanrylan in https://github.com/google/Xee/pull/97. However, the geometry issue still exists. If the geometry
is not specified, it will fail. If the image footprint image.geometry()
is used as the geometry, the output raster will have some zero-value on the image edge, resulting in some black strips.
import ee
import xarray
ee.Initialize(opt_url='https://earthengine-highvolume.googleapis.com')
image = ee.Image("LANDSAT/LC08/C02/T1_TOA/LC08_044034_20140318")
ic = ee.ImageCollection(image)
ds = xarray.open_dataset(ic, crs='EPSG:32610', scale=300, engine='ee', geometry=image.geometry())
image = ds.isel(time=0).rename({'Y': 'y', 'X': 'x'}).transpose('y', 'x').rio.write_crs("EPSG:32610")
image.rio.to_raster('test.tif', driver='COG')
Hello @giswqs,
Can you reinstall xee as the error you mentioned above is already resolved into this new release.
Now coming to this ...
geometry is not specified, it throws an error. I would expect it to use the image geometry if it is not specified.
Please refer to tool's default behaviour :
geometry: Specify an `ee.Geometry` to define the regional bounds when opening the data. When not set, the bounds are defined by the CRS's 'area_of_use` boundaries. If those aren't present, the bounds are derived from the geometry of the first image of the collection.
Code reference.
So as per the default behaviour if you don't pass any geometry then the bounds are defined by the CRS's 'area_of_use` boundaries. But there was an issue related to how we are processing data so I have raised the #121 that will resolve it.
Thanks.
Hello,
I am not sure if my specific issue is relevant to this chain but I am having difficulties opening up an xarray dataset. I am following this example... XEE: Geospatial analysis made easier - a tutorial & code. I created a ee.Geometey.Rectangle()
and used it as a parameter to open up the xarray dataset but received the following error message: ValueError: need at least one array to concatenate
. When I removed this parameter, I was able to pass the image collection to the xarray without any problems. Here is a link to my code for reference. Am I doing something wrong here?
Hello @ESimonson95 I added the PR #121 which resolves this error.
Hey @giswqs Can you close this issue as PR #121 merged into the main which resolved this issue.
If geometry is not specified, it throws an error. I would expect it to use the image geometry if it is not specified.
By specifying the geometry, it can open the dataset successfully. However, it seems the XY coordinates are always in EPSG:4326 no matter what crs is specified.