Add standard data object

[dopplershift]

• This is probably just a dictionary of arrays right now.
• Utilize standard names from CF to make things work automatically.
  • Might need to provide short names or something like it too
• Provide unit capabilities as well
• At least mimic iris API

This could also just be replaced wholesale by IRIS if that's deemed better.

[dopplershift]

Might even be a better idea to follow NetCDF4-Python API.

[dopplershift]

Should contain a getTimeAxis method to make it easy to get the time variable associated with an object. (This comes from the correct time variable bouncing from time to time1 on GRIB files. See Unidata/python-workshop#43)

[lesserwhirls]

Sorry I hadn't made this yet. Should also add Axis getters for all the axis
types. Here is a list of Axes that the CDM recognizes:

Time
RunTime
Ensemble
GeoX
GeoY
GeoZ
Lat
Lon
Height
Pressure
Radial Azmuith
RadialDistance
RadialElevation
Spectral

https://github.com/Unidata/thredds/blob/144f779cc20058581c660719f768fe396cd1a9c2/cdm/src/main/java/ucar/nc2/constants/AxisType.java

On Wednesday, July 15, 2015, Ryan May notifications@github.com wrote:

Should contain a getTimeAxis method to make it easy to get the time
variable associated with an object. (This comes from the correct time
variable bouncing from time to time1 on GRIB files. See
Unidata/python-workshop#43
Unidata/python-workshop#43)

—
Reply to this email directly or view it on GitHub
#10 (comment).

[dopplershift]

I think xarray is the way to go, at least as a base here. Its Dataset class is a nice container for multiple sets of data, and the DataArray class allows grouping coordinates with the data, having the dimension names, and having attributes attached.

One prominent problem that this would help solve is dimension ordering for things like geostrophic_wind. Currently, it's too easy to do the wrong thing silently; you can pass an array ordered lat, lon, while the docs say it needs to be x,y. By using the named axes on xarray, we could inquire on the data about the ordering. We could also eliminate the need to pass in delta x, y, etc. since the data would have the coordinate information. I think basing around xarray would allow much more GEMPAK-like operation, so long as you can get your data into an xarray. Fortunately, xarray construction is pretty straightforward--and is trivial if you have a netCDF file.

Another question this begs is whether we should have a Vector class for things like wind and gradients. Currently, we have the same situation, where the docs for advection specify a list of components. We could make things explicit by making use of a class to construct a vector from the components. This would allow some things like:

advection(temperature, Vector(x=u, y=v))

geo_wind = geostrophic_wind(heights, f)
print(geo_wind.x)  # Or maybe .u?