issue_comments

Hey @fmaussion, is this ready for me to try out again? I wanted to let you and @shoyer iterate first.

Sounds good!

Note that the above tiff was made with something like the following code:

``` res = 0.5 nlat = 180 nlon = 360 left_lon = -180 upper_lat = 90 crs = 'epsg:4326'

profile = { 'affine': rio.Affine(res, 0.0, left_lon, 0.0, -res, upper_lat), 'dtype': 'int32', 'height': int(nlat / res), 'width': int(nlon / res), 'nodata': '-1', 'crs': crs, } ```

Hey @fmaussion, I guess my question here is as follows: if a raster was generated by rasterio (thus using a dictionary representation of the CRS object even if a string is provided), should xarrary then fail to write to netcdf with that dataset?

If so, then that means that all users will have to do

ds = open_rasterio('file.tiff') ds.attrs['crs'] = ds.attrs['crs'].to_string() ds.to_netcdf('file.nc')

Would it be better to use the string representation of the CRS internally after reading in? I think this would solve @shoyer's concern about onboarding non-primitive datatypes.

As an aside, even my above suggestion did not work.. I'm not sure why.

``` In [33]: ds = xr.open_rasterio('./isimip_centroid_0_5.tiff')

In [34]: ds Out[34]: <xarray.Dataset> Dimensions: (band: 1, x: 720, y: 360) Coordinates: * y (y) float64 90.0 89.5 89.0 88.5 88.0 87.5 87.0 86.5 86.0 85.5 ... * x (x) float64 -180.0 -179.5 -179.0 -178.5 -178.0 -177.5 -177.0 ... * band (band) int64 1 Data variables: raster (band, y, x) int32 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 ... Attributes: crs: CRS({'init': u'epsg:4326'})

In [35]: ds.attrs['crs'] = ds.attrs['crs'].to_string()

In [36]: ds Out[36]: <xarray.Dataset> Dimensions: (band: 1, x: 720, y: 360) Coordinates: * y (y) float64 90.0 89.5 89.0 88.5 88.0 87.5 87.0 86.5 86.0 85.5 ... * x (x) float64 -180.0 -179.5 -179.0 -178.5 -178.0 -177.5 -177.0 ... * band (band) int64 1 Data variables: raster (band, y, x) int32 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 ... Attributes: crs: +init=epsg:4326

In [37]: ds.to_netcdf('test.nc')

TypeError Traceback (most recent call last) <ipython-input-37-d7687fe1d488> in <module>() ----> 1 ds.to_netcdf('test.nc')

/home/gidden/.local/lib/python2.7/site-packages/xarray-0.9.5_34_g48c7268-py2.7.egg/xarray/core/dataset.pyc in to_netcdf(self, path, mode, format, group, engine, encoding, unlimited_dims) 975 return to_netcdf(self, path, mode, format=format, group=group, 976 engine=engine, encoding=encoding, --> 977 unlimited_dims=unlimited_dims) 978 979 def unicode(self):

/home/gidden/.local/lib/python2.7/site-packages/xarray-0.9.5_34_g48c7268-py2.7.egg/xarray/backends/api.pyc in to_netcdf(dataset, path_or_file, mode, format, group, engine, writer, encoding, unlimited_dims) 588 # validate Dataset keys, DataArray names, and attr keys/values 589 _validate_dataset_names(dataset) --> 590 _validate_attrs(dataset) 591 592 try:

/home/gidden/.local/lib/python2.7/site-packages/xarray-0.9.5_34_g48c7268-py2.7.egg/xarray/backends/api.pyc in _validate_attrs(dataset) 119 for variable in dataset.variables.values(): 120 for k, v in variable.attrs.items(): --> 121 check_attr(k, v) 122 123

/home/gidden/.local/lib/python2.7/site-packages/xarray-0.9.5_34_g48c7268-py2.7.egg/xarray/backends/api.pyc in check_attr(name, value) 110 'string, ndarray or a list/tuple of ' 111 'numbers/strings for serialization to netCDF ' --> 112 'files'.format(value)) 113 114 # Check attrs on the dataset itself

TypeError: Invalid value for attr: CRS({'init': u'epsg:4326'}) must be a number string, ndarray or a list/tuple of numbers/strings for serialization to netCDF files ```

Hey @fmaussion, should we also do any attribute checking, or should we let the user fails as follows? I recently was testing this out and made a *.tiff with a shapefile as read from fiona. I got the following error:

``` In [12]: ds Out[12]: <xarray.Dataset> Dimensions: (band: 1, x: 720, y: 360) Coordinates: * y (y) float64 90.0 89.5 89.0 88.5 88.0 87.5 87.0 86.5 86.0 85.5 ... * x (x) float64 -180.0 -179.5 -179.0 -178.5 -178.0 -177.5 -177.0 ... * band (band) int64 1 Data variables: raster (band, y, x) int32 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 ... Attributes: crs: CRS({'init': u'epsg:4326'})

In [13]: ds.to_netcdf('test.nc')

TypeError Traceback (most recent call last) <ipython-input-12-d7687fe1d488> in <module>() ----> 1 ds.to_netcdf('test.nc')

/home/gidden/.local/lib/python2.7/site-packages/xarray-0.9.5_34_g48c7268-py2.7.egg/xarray/core/dataset.pyc in to_netcdf(self, path, mode, format, group, engine, encoding, unlimited_dims) 975 return to_netcdf(self, path, mode, format=format, group=group, 976 engine=engine, encoding=encoding, --> 977 unlimited_dims=unlimited_dims) 978 979 def unicode(self):

/home/gidden/.local/lib/python2.7/site-packages/xarray-0.9.5_34_g48c7268-py2.7.egg/xarray/backends/api.pyc in to_netcdf(dataset, path_or_file, mode, format, group, engine, writer, encoding, unlimited_dims) 588 # validate Dataset keys, DataArray names, and attr keys/values 589 _validate_dataset_names(dataset) --> 590 _validate_attrs(dataset) 591 592 try:

/home/gidden/.local/lib/python2.7/site-packages/xarray-0.9.5_34_g48c7268-py2.7.egg/xarray/backends/api.pyc in _validate_attrs(dataset) 114 # Check attrs on the dataset itself 115 for k, v in dataset.attrs.items(): --> 116 check_attr(k, v) 117 118 # Check attrs on each variable within the dataset

/home/gidden/.local/lib/python2.7/site-packages/xarray-0.9.5_34_g48c7268-py2.7.egg/xarray/backends/api.pyc in check_attr(name, value) 110 'string, ndarray or a list/tuple of ' 111 'numbers/strings for serialization to netCDF ' --> 112 'files'.format(value)) 113 114 # Check attrs on the dataset itself

TypeError: Invalid value for attr: CRS({'init': u'epsg:4326'}) must be a number string, ndarray or a list/tuple of numbers/strings for serialization to netCDF files ```

And it seems like this happens whether I use a dictionary originally or just a string.

Perhaps this is a slightly larger issue with cleaning the CRS object such that it is netcdf compatible? Does this mean just a

crs = ' '.join('+{}={}'.format(k, v) for k, v in crs.items()) '?

I would also favour doing nothing (ie 3), because most users will already have some solution. It's also easier to change later if we don't do anything now - no need to think at all about backwards compatibility, and the design can be guided by how people are using the existing parts.

Hey @fmaussion, I personally think some lat/lon support should be included here. I would lean toward 1 personally, but would be interested in what others think.