home / github

Menu
  • GraphQL API
  • Search all tables

issue_comments

Table actions
  • GraphQL API for issue_comments

11 rows where author_association = "MEMBER", issue = 109665577 and user = 1217238 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

  • shoyer · 11 ✖

issue 1

  • allow passing coordinate names as x and y to plot methods · 11 ✖

author_association 1

  • MEMBER · 11 ✖
id html_url issue_url node_id user created_at updated_at ▲ author_association body reactions performed_via_github_app issue
146407349 https://github.com/pydata/xarray/pull/608#issuecomment-146407349 https://api.github.com/repos/pydata/xarray/issues/608 MDEyOklzc3VlQ29tbWVudDE0NjQwNzM0OQ== shoyer 1217238 2015-10-08T03:23:35Z 2015-11-15T21:50:18Z MEMBER

I think pcolormesh is slightly more likely to yield correct and consistent results for plotting different types of data than our current hybrid of imshow/contourf. In my experience, pcolormesh also works better with cartopy. For default behavior, I would lean towards being correct rather than fast. Of course, waiting ~0.5 seconds per plot does start to add up when you're faceting, but it's not much more trouble to type .imshow.

On Wed, Oct 7, 2015 at 7:04 PM, Joe Hamman notifications@github.com wrote:

This is a good point. For me, its not a deal breaker though and the benefits of using pcolormesh all the time (simpler code, broad applicability) are worth the wait.

Reply to this email directly or view it on GitHub: https://github.com/xray/xray/pull/608#issuecomment-146393127

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
  allow passing coordinate names as x and y to plot methods 109665577
146761411 https://github.com/pydata/xarray/pull/608#issuecomment-146761411 https://api.github.com/repos/pydata/xarray/issues/608 MDEyOklzc3VlQ29tbWVudDE0Njc2MTQxMQ== shoyer 1217238 2015-10-09T05:57:22Z 2015-10-09T05:57:22Z MEMBER

LGTM

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
  allow passing coordinate names as x and y to plot methods 109665577
146730555 https://github.com/pydata/xarray/pull/608#issuecomment-146730555 https://api.github.com/repos/pydata/xarray/issues/608 MDEyOklzc3VlQ29tbWVudDE0NjczMDU1NQ== shoyer 1217238 2015-10-09T01:19:05Z 2015-10-09T01:19:05Z MEMBER

I'm OK with changing the default to yincrease=True. We might consider making this a globally settable option, if, for example, we start to get lots of people familiar with the other convention (popular for images) using xray.

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
  allow passing coordinate names as x and y to plot methods 109665577
146636071 https://github.com/pydata/xarray/pull/608#issuecomment-146636071 https://api.github.com/repos/pydata/xarray/issues/608 MDEyOklzc3VlQ29tbWVudDE0NjYzNjA3MQ== shoyer 1217238 2015-10-08T17:48:10Z 2015-10-08T17:48:10Z MEMBER

I'm conflicted about what the default xincrease/yincrease keyword values should be. In practice, it seems like some datasets need them, and some don't. But it also depends on the specific application.

@jhamman could you please explain your reasoning a little more for why we need this switch? Do you have a comprehensive sense of the ways that people organize their data cubes?

With climate data, it does seem pretty common that datasets have decreasing latitude values (e.g., 90, 80, 70, ...). This works well with the default behavior of imshow, but not pcolormesh (unless yincrease=True). I suppose this is your motivation?

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
  allow passing coordinate names as x and y to plot methods 109665577
146369228 https://github.com/pydata/xarray/pull/608#issuecomment-146369228 https://api.github.com/repos/pydata/xarray/issues/608 MDEyOklzc3VlQ29tbWVudDE0NjM2OTIyOA== shoyer 1217238 2015-10-07T23:49:42Z 2015-10-07T23:49:42Z MEMBER

Originally, we only had imshow and contourf. We picked imshow as the default because it shows individual pixels. But pcolormesh also meets that criteria, and has the convenience of also working on non-evenly spaced grid.

The only reason to possibly not pick pcolormesh is that it has a different convention from imshow in terms of the image orientation (top-left vs bottom-left origin). Given that xray is largely used for data with meaningful coordinate labels (rather than images), I think it's probably a better choice to use the bottom-left origin as a default. It composing better, for example, with 1D plots.

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
  allow passing coordinate names as x and y to plot methods 109665577
146341309 https://github.com/pydata/xarray/pull/608#issuecomment-146341309 https://api.github.com/repos/pydata/xarray/issues/608 MDEyOklzc3VlQ29tbWVudDE0NjM0MTMwOQ== shoyer 1217238 2015-10-07T21:41:29Z 2015-10-07T21:41:29Z MEMBER

OK, works for me :)

On Wed, Oct 7, 2015 at 2:40 PM, Joe Hamman notifications@github.com wrote:

I started to go down the road of removing the squeeze you were talking about but _infer_interval_breaks got in my way (when len(coord) == 1). I think this is an important corner case but this PR is getting pretty cluttered so maybe it is best to save that for another.

— Reply to this email directly or view it on GitHub https://github.com/xray/xray/pull/608#issuecomment-146341080.

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
  allow passing coordinate names as x and y to plot methods 109665577
146316910 https://github.com/pydata/xarray/pull/608#issuecomment-146316910 https://api.github.com/repos/pydata/xarray/issues/608 MDEyOklzc3VlQ29tbWVudDE0NjMxNjkxMA== shoyer 1217238 2015-10-07T20:21:48Z 2015-10-07T20:21:48Z MEMBER

so you would have a DataArray of shape (1, 5) be plotted via pcolormesh (by default)?

Either that, or we should extract the row and col arguments first, to ensure they aren't squeezed out.

On the other hand, it's not so terrible to encourage people use to explicit plot method in applications instead of the generic .plot, so maybe this isn't entirely necessary.

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
  allow passing coordinate names as x and y to plot methods 109665577
146313271 https://github.com/pydata/xarray/pull/608#issuecomment-146313271 https://api.github.com/repos/pydata/xarray/issues/608 MDEyOklzc3VlQ29tbWVudDE0NjMxMzI3MQ== shoyer 1217238 2015-10-07T20:06:05Z 2015-10-07T20:06:05Z MEMBER

While you're at it -- maybe the default .plot method shouldn't start with darray.squeeze()? That sort of behavior starts to make things behavior to predict. In particular, faceting should still work consistently even if one of the dimensions only has length 1.

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
  allow passing coordinate names as x and y to plot methods 109665577
146312066 https://github.com/pydata/xarray/pull/608#issuecomment-146312066 https://api.github.com/repos/pydata/xarray/issues/608 MDEyOklzc3VlQ29tbWVudDE0NjMxMjA2Ng== shoyer 1217238 2015-10-07T20:02:01Z 2015-10-07T20:02:01Z MEMBER

How about making the default pcolormesh since that works in all cases?

:+1:

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
  allow passing coordinate names as x and y to plot methods 109665577
146310353 https://github.com/pydata/xarray/pull/608#issuecomment-146310353 https://api.github.com/repos/pydata/xarray/issues/608 MDEyOklzc3VlQ29tbWVudDE0NjMxMDM1Mw== shoyer 1217238 2015-10-07T19:55:41Z 2015-10-07T19:56:30Z MEMBER

Can we make it so the generic .plot(x='lon', y='lat') works? Right now it defaults to imshow is the dimensions are equally spaced but that logic isn't probably right anymore if we allow different x/y labels: https://github.com/xray/xray/blob/cb4e4138fdb52078d27341dadf0feedb15e1de80/xray/plot/plot.py#L161

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
  allow passing coordinate names as x and y to plot methods 109665577
146082141 https://github.com/pydata/xarray/pull/608#issuecomment-146082141 https://api.github.com/repos/pydata/xarray/issues/608 MDEyOklzc3VlQ29tbWVudDE0NjA4MjE0MQ== shoyer 1217238 2015-10-07T05:42:07Z 2015-10-07T05:42:07Z MEMBER

Maybe instead of the complex fallback logic to handle specifying x and/or y, we should rewrite this to only handle two cases: 1. Both x and y are provided explicitly. They can be any coordinate variables. 2. Neither x nor y is provided, so use dims to provide default values.

Something like this...

python def _infer_xy_labels(plotfunc, darray, x, y): if x is None and y is None: if darray.ndim != 2: raise ValueError('must be 2d') x, y = darray.dims elif x is None or y is None: raise ValueError('cannot supply only one of x and y') elif any(k not in darray.coords for k in (x, y)): raise ValueError('x and y must be coordinate variables') return x, y

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
  allow passing coordinate names as x and y to plot methods 109665577

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]);
Powered by Datasette · Queries took 474.004ms · About: xarray-datasette