Closed trchudley closed 1 year ago
I just inspected the code and don't see anything that appears to be incorrect.
For what it's worth I've noticed this behavior on microsoft planetary computer (https://planetarycomputer.microsoft.com/compute, JUPYTER_IMAGE=pcccr.azurecr.io/public/planetary-computer/python:2022.05.11.0
)
rasterio 1.2.10 py38h667dea4_5 conda-forge
gdal 3.4.2 py38hdd69c9e_6 conda-forge
rioxarray 0.11.1 pyhd8ed1ab_0 conda-forge
Figured it was something to do with caching but never looked into it. Upgrading to rasterio>1.3 / gdal>3.5 resampling behaves as expected.
Thanks Scott, good to see it's reproducible. I was ultimately able to move to a new environment with an updated rasterio/gdal that worked as desired. This is a something that's easily missable if you're not paying attention, so I'm not sure whether it might be desirable to have some sort of check or warning on the versioning - will leave it for others to decide.
Cheers.
Code Sample, a copy-pastable example if possible
Problem description
I am attempting to resample older Landsat 60 m data to match newer Landsat panchromatic (15 m) data using the
reproject_match()
function. Whilst the resampling is apparently successful, the output is identical regardless of therasterio.enums.Resampling
method I choose (I would like cubic, but I achieve identical results when specifying nearest, average, max, cubic_spline, etc.).Based upon visual inspection of the output data, I suspect that the resampling method is reverting to 'nearest'.
Expected Output
reproject_match()
output to differ according to requested resampling method.Environment Information
rioxarray 0.12.0 rasterio 1.2.10 gdal 3.4.2 python 3.10.6 xarray 2022.6.0
Installation method
Mamba/Conda
Conda environment information (if you installed with conda):
Environment (
conda list
):Details about
conda
and system (conda info
):