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/2288#issuecomment-1205808926,https://api.github.com/repos/pydata/xarray/issues/2288,1205808926,IC_kwDOAMm_X85H3y8e,8699967,2022-08-04T21:56:28Z,2022-08-04T21:56:28Z,CONTRIBUTOR,That's nice @dcherian :+1: ,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,341331807
https://github.com/pydata/xarray/issues/2288#issuecomment-415849716,https://api.github.com/repos/pydata/xarray/issues/2288,415849716,MDEyOklzc3VlQ29tbWVudDQxNTg0OTcxNg==,8699967,2018-08-24T18:50:44Z,2018-08-24T18:50:44Z,CONTRIBUTOR,"I was thinking just a ""simple"" library with a CRS object with utilities to create the object from WKT, PROJ.4, CF projection parameters, etc... And could take the object and convert it to any of the other formats. I wouldn't add any transform/resampling code and instead be a codebase that can be used by libraries that do those things. This way it would be useful to many different projects (geoxarray, pyresample, cartopy, metpy, ...). Thoughts?
","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,341331807
https://github.com/pydata/xarray/issues/2288#issuecomment-415842467,https://api.github.com/repos/pydata/xarray/issues/2288,415842467,MDEyOklzc3VlQ29tbWVudDQxNTg0MjQ2Nw==,8699967,2018-08-24T18:23:57Z,2018-08-24T18:23:57Z,CONTRIBUTOR,Sounds good 👍. I see the CRS code potentially being useful outside of geoxarray. What are your thoughts on moving the CRS specific code into its own package?,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,341331807
https://github.com/pydata/xarray/issues/2288#issuecomment-409566229,https://api.github.com/repos/pydata/xarray/issues/2288,409566229,MDEyOklzc3VlQ29tbWVudDQwOTU2NjIyOQ==,8699967,2018-08-01T13:00:26Z,2018-08-01T13:00:26Z,CONTRIBUTOR,"Lots of good thoughts there.

I think a lot depends on who you plan on having for a user base. I like `rasterio.crs.CRS`, but it does require GDAL. I know GDAL is a heavy dependency (solves runtime problems and it a source of installation problems), but if your users are already using it, then it isn't too big of an ask. If not, you could look into something like [pycrs](https://github.com/karimbahgat/PyCRS). But, it looks like it hasn't been touched for a while (never a good sign). Or, there are other options, (requiring a more work & maintenance) such as re-creating the `rasterio.crs.CRS` object and using cython with a copy of only the spatial reference code from GDAL in the repo (might be better to create your own repo/package if you head in this direction). Or maybe someone could ask really nicely for the GDAL maintainers to consider making the spatial reference code a package on it's own (not likely, but would be really nice).

My preference to have the CRS object something created/retrieved by the accessor based on information in the file. If it is not, users will have to remove the CRS object when using `to_netcdf()` as the object will not be serializable and `to_netcdf()` will throw errors. I think allowing the user to set the CRS on the file (by adding the `crs` to `.coords` and `grid_mapping` to `data_vars`) by passing in a valid projection string (WKT, proj.4) `geo.set_crs()` would be a good idea. This way, when the user calls, `to_netcdf()` it will happily do what they want. In addition, the CRS will still be available later with the accessor when loading in with `xr.open_dataset`.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,341331807
https://github.com/pydata/xarray/issues/2288#issuecomment-407857617,https://api.github.com/repos/pydata/xarray/issues/2288,407857617,MDEyOklzc3VlQ29tbWVudDQwNzg1NzYxNw==,8699967,2018-07-25T18:49:57Z,2018-07-25T18:49:57Z,CONTRIBUTOR,"The example I gave was just demonstrating that the *dimension* is not required for the `crs` coordinate variable.

I agree with the functionality that would support standardizing the `crs` as a coordinate variable on load for the case you specified. That way, the read in file will always behave the same and writing to netCDF it would be output correctly.

This all sounds like it is heading in a good direction. 👍 ","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,341331807
https://github.com/pydata/xarray/issues/2288#issuecomment-407748105,https://api.github.com/repos/pydata/xarray/issues/2288,407748105,MDEyOklzc3VlQ29tbWVudDQwNzc0ODEwNQ==,8699967,2018-07-25T13:08:25Z,2018-07-25T13:08:25Z,CONTRIBUTOR,"It is not in the dimension, it is the *coordinate* attribute in the variable. That is handled automatically by xarray when writing `to_netcdf` if you add the *crs* to the `coords`.

From the ncdump:
```
dimensions:
        x = 65 ;
        y = 31 ;
variables:
        double x(x) ;
                x:_FillValue = NaN ;
                x:long_name = ""x coordinate of projection"" ;
                x:standard_name = ""projection_x_coordinate"" ;
                x:units = ""m"" ;
        double y(y) ;
                y:_FillValue = NaN ;
                y:long_name = ""y coordinate of projection"" ;
                y:standard_name = ""projection_y_coordinate"" ;
                y:units = ""m"" ;
        int64 time ;
                time:units = ""seconds since 2015-04-03T17:55:19"" ;
                time:calendar = ""proleptic_gregorian"" ;
        int64 spatial_ref ;
                spatial_ref:spatial_ref = ""PROJCS[\""UTM Zone 15, Northern Hemisphere\"",GEOGCS[\""WGS 84\"",DATUM[\""WGS_1984\"",SPHEROID[\""WGS 84\"",6378137,298.257223563,AUTHORITY[\""EPSG\"",\""7030\""]],AUTHORITY[\""EPSG\"",\""6326\""]],PRIMEM[\""Greenwich\"",0,AUTHORITY[\""EPSG\"",\""8901\""]],UNIT[\""degree\"",0.0174532925199433,AUTHORITY[\""EPSG\"",\""9122\""]],AUTHORITY[\""EPSG\"",\""4326\""]],PROJECTION[\""Transverse_Mercator\""],PARAMETER[\""latitude_of_origin\"",0],PARAMETER[\""central_meridian\"",-93],PARAMETER[\""scale_factor\"",0.9996],PARAMETER[\""false_easting\"",500000],PARAMETER[\""false_northing\"",0],UNIT[\""Meter\"",1]]"" ;
        double ndvi(y, x) ;
                ndvi:_FillValue = NaN ;
                ndvi:grid_mapping = ""spatial_ref"" ;
                ndvi:coordinates = ""spatial_ref time"" ;

// global attributes:
                :creation_date = ""2018-04-11 13:14:55.401183"" ;
```

It would definitely be a good idea to ensure that the `crs` variable is a coordinate, so I agree that having support for that would be a good idea.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,341331807
https://github.com/pydata/xarray/issues/2288#issuecomment-407614809,https://api.github.com/repos/pydata/xarray/issues/2288,407614809,MDEyOklzc3VlQ29tbWVudDQwNzYxNDgwOQ==,8699967,2018-07-25T02:39:34Z,2018-07-25T02:39:34Z,CONTRIBUTOR,"That is interesting, I am definitely not an expert with non-uniform datasets. From the satellite datasets I have used, the 2D latitude and longitude coordinates are stored in the datasets and are not super useful. I usually have to use other ways to recreate the grid coordinates in the original projection (ex. SMAP uses the EASE Grid 2.0 but it stores the latitude/longitude of the points in the file) or reproject & flatten the coordinates. I have had to do this with weather data and made an xarray extension [pangaea](https://github.com/snowman2/pangaea) to handle it. So, that is what I was referring to when I misunderstood your question.

> For your example of adding a crs attribute, ...

The files I have created have the `crs` coordinate variable inside the netCDF file already and it is always there when I load it in with `xarray.open_dataset()`. The method `set_crs()` could be used to add the `crs` coordinate variable and `grid_mapping` attributes to the dataset in the proper way so that it would be there on `xarray.open_dataset()` after dumping it to the file with `to_netcdf()`.

The CF stuff is supported by rasterio, GDAL, QGIS and that is why I like it. If there is another way that is as well supported, I am not opposed to it.

> In your example of methods is to_projection a remapping/resampling operation? If not, how does it differ from set_crs?

The `to_projection()` method would be a reproject/resampling operation.
","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,341331807
https://github.com/pydata/xarray/issues/2288#issuecomment-407546587,https://api.github.com/repos/pydata/xarray/issues/2288,407546587,MDEyOklzc3VlQ29tbWVudDQwNzU0NjU4Nw==,8699967,2018-07-24T20:47:23Z,2018-07-24T20:48:17Z,CONTRIBUTOR,">  In your own projects and use of raster-like data, do you ever deal with non-uniform/non-projected data?

I have dealt with non-uniform data in the geographic projection. I have found it easiest to deal with it if you can determine the original projection and project the coordinates back to that projection so it is uniform. But, I am by no means an expert in this arena. Most if the time I work ""normal"" data.

> How do you prefer to handle/store individual lon/lat values for each pixel?

rasterio/GDAL/QGIS all seem to use the centroid.

> Also it looks like xarray would have to be updated to add the ""crs"" coordinate since currently it is not 
considered a coordinate variable. So a new library may need to have custom to_netcdf/open_dataset methods, right?

Actually, it is not difficult to add as it stands:
```python
ds.coords['crs'] = 0
ds.coords['crs'].attrs = dict(spatial_ref=""PROJCS[""UTM Zone 15, Northern Hemisphere"",GEOGCS[""WGS 84"",D..."")
```
But, if a `crs` does not already exist on the dataset, I guess that a function that adds the `crs` properly would be useful so it can also add the grid_mapping to all of the variables.

Example:
```python
ds.geo.set_crs(""+init=epsg:4326"")
```

I think that minor modifications will be needed once the crs is set properly on the xarray dataset. Because after that, the `to_netcdf()` will automatically produce georeferenced datasets.

I could see the first pass of the extension/library simply performing:
1. `ds.geo.crs`
2. `ds.geo.set_crs()`
3. `ds.geo.to_projection()`","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,341331807
https://github.com/pydata/xarray/issues/2288#issuecomment-407404131,https://api.github.com/repos/pydata/xarray/issues/2288,407404131,MDEyOklzc3VlQ29tbWVudDQwNzQwNDEzMQ==,8699967,2018-07-24T13:21:31Z,2018-07-24T13:32:42Z,CONTRIBUTOR,"Here is an example of how it would look on a dataset:
```
<xarray.Dataset>
Dimensions:      (x: 65, y: 31)
Coordinates:
  * x            (x) float64 ...
  * y            (y) float64  ...
    time         datetime64[ns] ...
    crs          int64 ...
Data variables:
    ndvi         (y, x) float64 ...
Attributes:
```
Here is how the `crs` or `spatial_ref` coodinate variable would look:
```
<xarray.DataArray 'crs' ()>
array(0)
Coordinates:
    time         datetime64[ns] ...
    crs          int64 0
Attributes:
    spatial_ref:  PROJCS[""UTM Zone 15, Northern Hemisphere"",GEOGCS[""WGS 84"",D...
```
And here is how it would look on the variables:
```
<xarray.DataArray 'ndvi' (y: 31, x: 65)>
array([[ ...]])
Coordinates:
  * x            (x) float64 ...
  * y            (y) float64 ...
    time         datetime64[ns] ...
    crs          int64 0
Attributes:
    grid_mapping:  crs
```

@djhoese Whether or not we use the CF convention is not what I am concerned about. What I think would benefit the most people is with the file format to be able to do `to_netcdf()` with the file and be able to have it read in with standard GIS tools such as rasterio, GDAL, and QGIS. With this schema, this is possible. 

Another benefit is that it keeps the `crs` or `spatial_ref` with it when you do your operations as it is a coordinate of the variable.

Also, as a side note if you use the center pixel coordinates, then GDAL, rasterio, and QGIS are able to read in the file and determine it's affine/transform without a problem.

For the new library, if you have a `crs` method attached to it, it isn't too difficult to convert it to whatever format you need it to be in. With the [rasterio.crs.CRS.from_string](https://github.com/mapbox/rasterio/blob/c96168b59167bc4f67e3e39700ac253064720718/rasterio/_crs.pyx#L154) you can ""Make a CRS from an EPSG, PROJ, or WKT string"" and you can also get back the EPSG, PROJ, or WKT string with a simple method call.

For example, using the recommended method to [extend xarray](http://xarray.pydata.org/en/stable/internals.html#extending-xarray), you could add a crs property:

```python
from rasterio.crs import CRS
........
@property
def crs(self):
    """""":obj:`rasterio.crs.CRS`:
        Projection from `xarray.DataArray`
    """"""
    if self._crs is not None:
        return self._crs
    try:
        # look in grid_mapping
        self._crs = CRS.from_string(self._obj.coords[self._obj.grid_mapping].spatial_ref)
    except AttributeError:
        raise ValueError(""Spatial reference not found."")
    return self._crs
```

And if you call your extension `geo`, all you would need to get the CRS would be:
```python
ds.geo.crs
```
To get proj.4 string:
```python
ds.geo.crs.to_string()
```
To get WKT string:
```python
ds.geo.crs.wkt
```
To get EPSG code:
```python
ds.geo.crs.to_epsg()
```
","{""total_count"": 4, ""+1"": 4, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,341331807
https://github.com/pydata/xarray/issues/2288#issuecomment-407249087,https://api.github.com/repos/pydata/xarray/issues/2288,407249087,MDEyOklzc3VlQ29tbWVudDQwNzI0OTA4Nw==,8699967,2018-07-24T01:19:26Z,2018-07-24T01:19:26Z,CONTRIBUTOR,"I am really excited about this discussion. I know of other libraries that have done the same thing and have written internal libraries myself.

If possible, I would hope that we could follow the CF convention on this as it makes the output netCDF file compatible with QGIS, GDAL, and rasterio when written using `to_netcdf()`

To do so, you add the `crs` coordinate to the dataset/dataarray.
```
int crs;
```
And then, you add the `spatial_ref` attribute to the crs which is a crs WKT string.

Next, you add the `grid_mapping` attribute to all associated variables that contains `crs` as the grid_mapping.

See an example [here](https://gis.stackexchange.com/questions/230093/set-projection-for-netcdf4-in-python).

After that, you could store all kinds of information inside the `crs` variable such as the proj4 string, the affine, etc.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,341331807