-
Notifications
You must be signed in to change notification settings - Fork 85
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
Comments
I should note that there are relevant cases where the dimensions should be renamed from (e.g.) 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'} |
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. |
Code Sample
Problem description
It is expected that
reproject_match
with a DataArray would keep the originalx_dim
andy_dim
names, but they appear to always go toy
andx
.Environment Information
But also on linux with current
master
branch.Installation method
The text was updated successfully, but these errors were encountered: