issue_comments: 379593118

On Apr 8 2018 12:45 PM, Fabien Maussion wrote:

if the profile and tags were propagated through open_rasterio, then the second open would not be necessary and would be generally useful.

We have been adding new attributes like this recently (https://github.com/pydata/xarray/pull/1583 and https://github.com/pydata/xarray/pull/1740), so I don't see much trouble in adding a few more. Note that the rasterio object is available via the (undocumented) _file_obj attribute. So a quick workaround for you in the mean time would be to access the info you need directly via this object.

As for the to_rasterio method, I'm currently against it. I'm already starting to think that these kind of domain specific tools should exist in dedicated projects, not in the main xarray codebase. For rasterio in particular, it turns out that the geotiff/GDAL data model is fairly different from the xarray/NetCDF model. The rasterio folks have also shown only limited interest in our endeavor (https://github.com/mapbox/rasterio/issues/920), which is understandable. I don't have a strong opinion though, and I am curious if the @pydata/xarray crew sees it differently.

I do not care about the to_rasterio but I do care about a ''to_tiff'' (even if I have to do all the geospatial stuff outside of xarray as long as I can output the image data portion of the tiff via xarray). I also do not overly care if the xarray interface is significantly different from the rasterio/GDAL API (however someone will have to document the differences so that it does not continually trip people like me up -- I should be able to help a little with this once it gets working). Basically however it is handled I have to be able to read a GeoTIFF, process, and write back out to a GeoTIFF. If xarray has no way to output tiffs then I cannot use xarray.