You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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: