issue_comments

Table actions

1 row where author_association = "MEMBER", issue = 341331807 and user = 4160723 sorted by updated_at descending

✎ View and edit SQL

This data as json, CSV (advanced)

Suggested facets: created_at (date), updated_at (date)

user 1

  • benbovy · 1 ✖

issue 1

  • Add CRS/projection information to xarray objects · 1 ✖

author_association 1

  • MEMBER · 1 ✖
id html_url issue_url node_id user created_at updated_at ▲ author_association body reactions performed_via_github_app issue
1211331828 https://github.com/pydata/xarray/issues/2288#issuecomment-1211331828 https://api.github.com/repos/pydata/xarray/issues/2288 IC_kwDOAMm_X85IM3T0 benbovy 4160723 2022-08-10T22:05:58Z 2022-08-10T22:05:58Z MEMBER

That's great @dcherian! Some comments (notably regarding your notes in your linked notebook):

A lot of boilerplate code in your CRSIndex class (and in RasterIndex) could be moved into some PandasMetaIndex helper class that would encapsulate one or more PandasIndex. Then CRSIndex could subclass it and just implement the CRS-related logic. This would be useful for many other indexes I think.

But as you suggest it, it would be nice if we could also reuse the CRS-related logic with other kinds of index structures (like kd-trees). I've been thinking a bit about the general issue of flexible geospatial xarray indexes but I'm not sure yet how best it could be solved.

Can we support passing a CRS object directly using **kwargs? Not at the moment. This is the data model: Indexes are constructed from a subset of Coordinate variables. all necessary information should be in a coordinate variable

This should be supported with #6800 (I need to re-submit a PR targeting main, see #6849). For the case of CRSIndex, I think it might be useful to support both ways (i.e., either set the CRS via **kwargs or get it from a coordinate variable).

Index.create_variables. set_xindex tries to pass a variables kwarg but other methods don't. Seems like a bug.

Yes this should be clarified, i.e., whether the variables argument of Index.create_variables should be optional or not. I think we can make it required but I need to check.

How do we delete an existing index?

There's some discussion in #4366 about adding a new .drop_indexes() (or drop_xindexes()?) method.

error message with join='exact' is very generic.

That's a tricky one to improve.

GroupBy doesn't propagate index.

Maybe related to #6836 ?

spatial_ref is confusing. A scalar index?

I agree. The index should probably be dropped in that case (i.e., reduction of both the x and y dimensions), leaving the spatial_ref coordinate as a non-indexed coordinate. But this may be tricky to handle in general (i.e., for any index). Ideally this should also be consistent with the behavior of the index for other operations like scalar selection. 

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Add CRS/projection information to xarray objects 341331807

Advanced export

JSON shape: default, array, newline-delimited, object

CSV options: 

CREATE TABLE [issue_comments] (
   [html_url] TEXT,
   [issue_url] TEXT,
   [id] INTEGER PRIMARY KEY,
   [node_id] TEXT,
   [user] INTEGER REFERENCES [users]([id]),
   [created_at] TEXT,
   [updated_at] TEXT,
   [author_association] TEXT,
   [body] TEXT,
   [reactions] TEXT,
   [performed_via_github_app] TEXT,
   [issue] INTEGER REFERENCES [issues]([id])
);
CREATE INDEX [idx_issue_comments_issue]
    ON [issue_comments] ([issue]);
CREATE INDEX [idx_issue_comments_user]
    ON [issue_comments] ([user]);