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/4142#issuecomment-642413509,https://api.github.com/repos/pydata/xarray/issues/4142,642413509,MDEyOklzc3VlQ29tbWVudDY0MjQxMzUwOQ==,2443309,2020-06-11T05:18:37Z,2020-06-11T05:18:37Z,MEMBER,"Thanks @WeatherGod for opening this issue. It is good to have you back around these parts. 

The main thing to consider at the moment is that we are about to start a major backend refactor (#1970). So I'd suggest holding on off on any major work that builds on our current DataStore implementation.

From an API design, I think it makes sense to revisit the rasterio->DataArray convention we currently have and instead treat rasterio like most other drivers and return a Dataset by default. For most applications, the following would be true:

```python
open_rasterio(...) == open_dataarray(..., engine='rasterio') == open_dataset(..., engine='rasterio')[default_var]
```

There's also the question of where the rasterio backend should live once #1970 is implemented. I think we can make a pretty strong argument that it should move out of xarray and into a 3rd party package. Perhaps rasterio itself, or, more likely something like rio-xarray (cc @snowman2). See #3166 for a demo of how this may work. 

As you can see, there are a few big questions up in the air right now. Work on #1970 will begin this summer so now is a great time to game out the various options for the rasterio backend.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,636493109