issue_comments: 435968410

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/2539#issuecomment-435968410 https://api.github.com/repos/pydata/xarray/issues/2539 435968410 MDEyOklzc3VlQ29tbWVudDQzNTk2ODQxMA== 950575 2018-11-05T17:48:13Z 2018-12-07T20:09:18Z CONTRIBUTOR

I agree erdappy seems like good fit for an xarray backend.

Note that erddapy is not really a "client" it is a URL builder that leverages ERDDAP's RESTful Web Services and pandas or xarray to download data.

@rmendels and @jhamman please correct me if I'm wrong below:

The main advantage of ERDDAP, as @rmendels mentioned above, is that one can make requests in coordinate space. However, I don't think there is an OPeNDAP response for that a sliced request in ERDDAP, just the "full data." Also, xarray can already ingest an OPeNDAP URL and lazily slice it using high level coordinate space syntax. (At the cost of loading the coordinates but that is 99% of the time fast enough.)

The alternative would be to use the netCDF response but that means we would need to download the file and load it with xarray, which does not really justify a new backend IMO. (I do that in a very inelegant way in erddapy.)

The download limitation exists in any of the "file format" responses in ERDDAP, making the OPeNDAP the best choice. So, unless we can figure out a way for ERDDAP to serve the "sliced" URL as OPeNDAP, I believe the best we can do already exists in xarray :grimacing:

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   377096851