EDR: Use latitude/longitude/vertical/time instead of X, Y, Z, T

[dcherian]

Using these key names will trigger matching based on standard_name, units etc, and seems more in line with the intent of the EDR API.

See https://github.com/xarray-contrib/cf-xarray/blob/8102e18f12e417a9c669b1492d76c4b669241feb/cf_xarray/criteria.py#L43

[abkfenris]

I chatted a little with @jhamman in #37 (comment) and elsewhere, and I'm thinking that I might do a bigger refactoring around selection to enable a better and more controllable hierarchy.

Something like:

1. Allow datasets to specify in a plugin specific way per variableds['funny_time'].attrs['_xpublish']['edr']['axis'] = 'T'
2. Fall back to standard nameds.cf.sel(time=)
3. Fall further to axis ds.cf.sel(T=)
4. Panic

That way anything that is supported by the current axis selection will continue working, but will be prempted by standard_name or an explicitly defined axis. Any thoughts on doing something like this?

[dcherian]

(2,3,4) sound good to me.

Re (1): EDR offers a way to specify custom dimension names: https://docs.ogc.org/is/19-086r6/19-086r6.html#_a2113fbe-7d9d-4295-bdfa-25b9cc89fa03 Seems like xpublish should encourage using that instead of adding another API

[abkfenris]

As far as I understand that spec, that's not for how an EDR server should match variables to it's standard dimensions, but instead how it should advertise new dimensions that don't match up to X, Y, Z, or T via the collections response to clients. Currently we are not supporting the OGC collections response, which as far as I understand is more than just EDR.

It is worth referencing that spec to make sure we are supporting non X, Y, Z, T dimensions in a way that is compatible (I think we are, but I haven't checked in a bit).

1 - would be more for individual datasets to be configured when loaded to nudge the EDR provider to do the right thing.

I'm thinking of treating .attrs['_xpublish'] almost as a namespace that other plugins could use for configuration, and anywhere that attrs gets publicly exposed, there is one known key to strip off.

PyGeoAPI has it's own way of specifying dimension to variable mapping.

For context, I've mainly have written this package to more follow the spirit of OGC EDR, than the exact spec and have tried to match up and extend the query and response patterns for the data retrieval itself. I haven't found much usage or clients in the wild, so I've focused on the need to get a timeseries at a point in way that is friendlier to browsers, since that seems to be the main reason that I see folks interested in it at least over here in IOOS frontend land.