Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

reproject_match renames dims #751

Open
mwtoews opened this issue Feb 27, 2024 · 2 comments
Open

reproject_match renames dims #751

mwtoews opened this issue Feb 27, 2024 · 2 comments
Labels
bug Something isn't working

Comments

@mwtoews
Copy link
Contributor

mwtoews commented Feb 27, 2024

Code Sample

from pathlib import Path
import xarray as xr

REPO_DIR = Path("/data/mtoews/src/rioxarray")
TEST_INPUT_DATA_DIR = REPO_DIR / "test" / "test_data" / "input"
ds = xr.open_dataset(TEST_INPUT_DATA_DIR / "nonstandard_dim.nc")
da = ds.analysed_sst
da2 = da.rio.reproject_match(da)

print(da.dims)
# ('time', 'lat', 'lon')

print(da2.dims)
# ('time', 'y', 'x')

# workaround
if da.dims != da2.dims:
    da2 = da2.rename(dict(zip(da2.dims, da.dims)))
print(da2.dims)
# ('time', 'lat', 'lon')

Problem description

It is expected that reproject_match with a DataArray would keep the original x_dim and y_dim names, but they appear to always go to y and x.

Environment Information

rioxarray (0.15.0) deps:
  rasterio: 1.3.6
    xarray: 2023.11.0
      GDAL: 3.6.2
      GEOS: 3.11.1
      PROJ: 9.1.1
 PROJ DATA: C:\Users\mtoews\AppData\Local\miniforge3\envs\pyforge\Library\share\proj
 GDAL DATA: C:\Users\mtoews\AppData\Local\miniforge3\envs\pyforge\Library\share\gdal

Other python deps:
     scipy: 1.11.3
    pyproj: 3.5.0

System:
    python: 3.10.13 | packaged by conda-forge | (main, Oct 26 2023, 18:01:37) [MSC v.1935 64 bit (AMD64)]
executable: C:\Users\mtoews\AppData\Local\miniforge3\envs\pyforge\python.exe
   machine: Windows-10-10.0.19045-SP0

But also on linux with current master branch.

Installation method

  • conda, but also pip
@mwtoews mwtoews added the bug Something isn't working label Feb 27, 2024
@mwtoews
Copy link
Contributor Author

mwtoews commented Feb 27, 2024

I should note that there are relevant cases where the dimensions should be renamed from (e.g.) lat to y, for instance when projecting from a geographic CRS with distance units in degrees to a projected coordinate system like a UTM zone with distance units in meters. Not sure if keeping/renaming dims should be user-controlled or not, but I've noted a workaround above. So these new dim names and units are expected:

da3 = da.rio.reproject("EPSG:2193")
print(da3.x.attrs)
# {'axis': 'X', 'long_name': 'x coordinate of projection', 'standard_name': 'projection_x_coordinate', 'units': 'metre'}
print(da.lon.attrs)
# {'long_name': 'longitude', 'standard_name': 'longitude', 'axis': 'X', 'units': 'degrees_east', 'valid_min': -180.0, 'valid_max': 180.0, 'comment': 'geolocations inherited from the input data without correction'}

it's just this dimension name that's inconsistent:

print(da2.x.attrs)
# {'axis': 'X', 'long_name': 'longitude', 'standard_name': 'longitude', 'units': 'degrees_east'}

@snowman2
Copy link
Member

This was by design to keep the logic simple. As you demonstrated, there are cases where you would transform from geographic to projected coordinate systems or the other way around. Attempting to preserve coordinate names in some instances and not others would make the behavior somewhat unpredictable. With the current design, you always know what your dimensions will be in the output.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants