Open rod-glover opened 5 years ago
corviday
commented
5 years ago It is definitely not the case that all the data we want to add to the PDP has time[i] == i. I wrote this data processing python script to enforce i <= time[i] < i+1. But that's a bodgy stopgap measure; it would be much better if the PDP were able to handle the common, totally legitimate case where time[i] != i.
rod-glover
commented
5 years ago That would mean we'd have to modify or create a metadata endpoint to return the maximum time value, not just the dimension of the time axis. Which would be a good thing.
corviday
commented
5 years ago I'm not very sure about this, but I think that because the PDP implements the OPeNDAP API, we unfortunately can't just modify the existing endpoints to provide the information we need, since that would deviate from the standard. We might actually have to make an DAP data call to the backend to get the maximum time value. :(
Adding new endpoints might be okay, though? It wouldn't impinge on the standardized content of existing endpoints.
Current code assumes that the length of the time axis determines the maximum (latest) time point in the axis. Specifically, the code extracts the length of the time axis from metadata, and uses that length to set the "max time". This logic is replicated in the new, calendar-aware code.
This logic is potentially flawed: There is no a priori rule that says that the time dimension has to satisfy a relation like
time[i] == i, which is pretty much what this logic assumes. In practice, I suspect this is the case, but we are asking for weird behaviour if there is any chance this is not the case.