issue_comments

That's nice @dcherian :+1:

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?

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?

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. 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.

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. 👍

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.

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 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.

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()

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 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, 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()

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.

After that, you could store all kinds of information inside the crs variable such as the proj4 string, the affine, etc.