Support requests to dynamics ncWMS datasets

[jameshiebert]

@rod-glover can fill in some details, but new versions of ncWMS support dynamic datasets (where datasets are not pre-configured, and layers are scanned upon first request).

Requests for a dynamic dataset require an extra parameter, the file path, which is not presently available in the frontend. As part of this issue, one needs to:

1. Ensure that the backend returns the file path along with other dataset metadata
2. Use the file path in any relevant requests to ncWMS.

There are 4 portals that use ncWMS layers that need to be minimally updated. They are as follows:

james@basalt:~/code/git/pdp/pdp/static/js$ grep -nr "ncwms = .*OpenLayers.Layer.WMS" *
canada_ex_map.js:46:        ncwms = new OpenLayers.Layer.WMS(
gridded_observations_map.js:39:    ncwms =  new OpenLayers.Layer.WMS(
prism_demo_map.js:41:    ncwms =  new OpenLayers.Layer.WMS(
vic_map.js:51:    ncwms =  new OpenLayers.Layer.WMS(

There are a few places where the frontend requests dataset information from the backend, all of which are, unfortunately, in pdp_util. The most sensible place is probably to add the filepath (and/or rename the request to be more general) to /metadata.json?request=GetMinMaxWithUnits. But I'm open to other options.

[rod-glover]

To accommodate the same thing in climate-explorer-backend, I added a query parameter extras whose value is a comma-separated list of extra things (beyond the default contents) to include in the response. So far, you can specify filepath as an extra and it does the obvious thing.

I'm tempted to do the same thing here. I'm not a big fan of the /metadata.json API design, but I don't want to change it very much. Its name is fine; it's accurate. What I'd like to do is:

• make the default response, regardless of query parameters, contain min and max
• add aninclude query parameter that is like extras. Values include would recognize are:
  • units
  • filepath
• make request an optional query parameter with the following meanings:
  • request=GetMinMax: default response
  • request=GetMinMaxWithUnits: include units in response

This will ensure backwards compatibility (for whatever that is worth). Our desired new requests will be /metadata.json?include=units,filepath.

[jameshiebert]

Sounds fine to me.

[rod-glover]

Awesome, because I already did it. :wink:

[rod-glover]

@jameshiebert , did you intend to leave bccaq_extremes_map.js:119 out of the list of API callers to be updated?

[jameshiebert]

I did. Related to #124

[rod-glover]

:facepalm:

[rod-glover]

Note in passing: This is much harder than it at first appears. The assumption that the ncWMS layer id is a compound of the modelmeta unqiue_id and the variable id is spread throughout the code. With the introduction of dynamic datasets, this assumption is no longer valid. In the present code there is no single source of truth for layer metadata. Instead the layer id assumed == unique_id is encoded and decoded in many places. It is also bound up in the dataset selector in the UI is built, how the data to populate that UI is generated in the backend, and how selecting a dataset in the UI is implemented. This couples the backend and frontend quite tightly in this regard. In short adding the filepath to the mix is going to be more challenging because of that.

So this makes me wonder if we can't eat our cake and have it too. We could add an intervening translation service between ncWMS that translates unique_id to filepath, via metadata and passes that on to ncWMS. It would be very easy to write. (I propose this as an independent service. It could alternatively be built in to ncWMS, though I quail at the thought.)

[jameshiebert]

The assumption that the ncWMS layer id is a compound of the modelmeta unqiue_id and the variable id

Well... that's not really an assumption. That's exactly how we built the service, initially. :)

In short adding the filepath to the mix is going to be more challenging because of that.

Yep, that was part of why I was pretty cool to the introduction of file paths to begin with. But ncWMS using them pretty much forced us to do so.

We could add an intervening translation service between ncWMS that translates unique_id to filepath, via metadata and passes that on to ncWMS.

Sure, that's a good idea!

[rod-glover]

Translator service built. This is no longer an issue for PDP.