-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support requests to dynamics ncWMS datasets #184
Comments
To accommodate the same thing in I'm tempted to do the same thing here. I'm not a big fan of the
This will ensure backwards compatibility (for whatever that is worth). |
Sounds fine to me. |
Awesome, because I already did it. 😉 |
@jameshiebert , did you intend to leave |
I did. Related to #124 |
🤦 |
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.) |
Well... that's not really an assumption. That's exactly how we built the service, initially. :)
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.
Sure, that's a good idea! |
Translator service built. This is no longer an issue for PDP. |
@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:
There are 4 portals that use ncWMS layers that need to be minimally updated. They are as follows:
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.The text was updated successfully, but these errors were encountered: