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`](https://github.com/pyoceans/erddapy/blob/55bf891dfa3b91fd895820f1c76ae8b7ee271e63/erddapy/erddapy.py#L161-L173) or [`xarray`](https://github.com/pyoceans/erddapy/blob/55bf891dfa3b91fd895820f1c76ae8b7ee271e63/erddapy/erddapy.py#L175-L184) 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](https://github.com/pyoceans/erddapy/blob/55bf891dfa3b91fd895820f1c76ae8b7ee271e63/erddapy/utilities.py#L149-L160).)

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