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
.proj.set_crs(...): like in Xvec and currently implemented
.proj.write_crs(...): like in rioxarray
.proj.assign_crs(...): like in odc-geo
I have a slight preference for option 3. This is more consistent with methods like Xarray assign_coords that also return new Dataset or DataArray objects with new or replaced coordinates.
I have a slight preference for option 3. This is more consistent with methods like Xarray assign_coords that also return new Dataset or DataArray objects with new or replaced coordinates.
I agree! Would be great to align as much as possible with existing Xarray methods and syntax
I also wonder whether we should have a allow_override=False option or no option, i.e., in the latter case just leave the responsibility to the user that assign_crs(spatial_ref=crs) may overwrite any existing CRS.
odc-geo's assign_crs() docstrings says "Assign CRS for a non-georegistered array or dataset" but I don't see anything that prevent overwriting an existing CRS in the implementation.
Activity
scottyhq commentedon Dec 4, 2024
I agree! Would be great to align as much as possible with existing Xarray methods and syntax
benbovy commentedon Dec 5, 2024
I also wonder whether we should have a
allow_override=Falseoption or no option, i.e., in the latter case just leave the responsibility to the user thatassign_crs(spatial_ref=crs)may overwrite any existing CRS.odc-geo's
assign_crs()docstrings says "Assign CRS for a non-georegistered array or dataset" but I don't see anything that prevent overwriting an existing CRS in the implementation.