home / github / issue_comments

Menu
  • Search all tables
  • GraphQL API

issue_comments: 145403647

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/605#issuecomment-145403647 https://api.github.com/repos/pydata/xarray/issues/605 145403647 MDEyOklzc3VlQ29tbWVudDE0NTQwMzY0Nw== 1217238 2015-10-05T00:00:39Z 2015-10-05T00:00:39Z MEMBER

The main thing I don't like about how we handle the coordinate attribute right now is that we use it to determine the coordinate names, and throw the attribute out. I seem to remember bringing this up in the past with our discussions of the calendar attribute and still don't like that we remove attributes that we decode. Especially this once since we don't do much with it.

In the case of calendars, the information ends up on the encoding attribute. I think you're right though that we currently throw away variable specific coordinates information -- that should probably also be preserved on encoding.

There are two reasons why we do this sort of thing: 1. to make it unambiguously clear that we've "decoded" this information into xray's data model. 2. to ensure that the metadata can't get out of sync by being changed in one place but not another. For example, what would it mean if we unset xc as a coordinate on the dataset, but it remained in the coordinates attribute on mask? Or if we deleted xc entirely?

These sort of ambiguous scenarios are the part that worry me. In particular, I worry that it leads us down a path of maintaining arbitrary metadata through operations.

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