home / github / issue_comments

Menu
  • GraphQL API
  • Search all tables

issue_comments: 656789017

This data as json

html_url issue_url id node_id user created_at updated_at author_association body reactions performed_via_github_app issue
https://github.com/pydata/xarray/issues/4215#issuecomment-656789017 https://api.github.com/repos/pydata/xarray/issues/4215 656789017 MDEyOklzc3VlQ29tbWVudDY1Njc4OTAxNw== 3460034 2020-07-10T17:17:59Z 2020-07-10T17:41:31Z CONTRIBUTOR

I agree with #3689 that it makes the most sense to have decode_coords set those variables referenced in bounds as coordinates. By the same reasoning, I would think the other special variable-linked attrs of CF Section 7 should be treated similarly:

  • cell_measures
  • climatology
  • geometry
  • node_coordinates
  • node_count
  • part_node_count
  • interior_ring

grid_mapping and ancillary_variables were also brought up. grid_mapping definitely makes sense to be interpreted as a coordinate variable, since it is inherently linked to the CRS of the data. I would say no however to ancillary_variables, since those are not really about coordinates and instead about linked data variables (like uncertainties).

My one concern with #2844 is clarifying the role of encoding vs. attrs. I don't have any good conclusions about it, but I'd want to be very cautious about not having these "links" defined by the CF conventions disappear unexpectedly because they were decoded by decode_coords, moved to encoding, and then erased due to some xarray operation clearing encoding on the returned data. I'd hope to keep them around in some fashion so that they are still usable by libraries like cf-xarray and MetPy, among others.

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
  654889988
Powered by Datasette · Queries took 0.577ms · About: xarray-datasette