The PDP front end accesses metadata about the time variable of file in order to know how to translate a user's request for data from certain calendar dates to which indexes of the time variable in the file it needs to send.
Currently in pdp_raster_map.js, the front end consults the two PyDAP metadata APIs, DAS and DDS.
The DAS API provides it metadata on all variables, including the time variable:
Attributes {
NC_GLOBAL {
String domain "Canada";
String method_id "BCCAQv2";
...
}
lon {
,,,
}
lat {
...
}
time {
String long_name "Time";
String standard_name "Time";
String NAME "time";
String units "days since 1950-01-01";
Int32 _Netcdf4Dimid 2;
String calendar "365_day";
String CLASS "DIMENSION_SCALE";
}
tasmax {
...
}
}
The DDS API tells it how many timestamps the file has.
So the front end knows how many timestamps there are, and the units of the timestamps (days since 1950-01-01) but it has no way to tell from the metadata what the actual first timestamp is. So it always assumes the first timestamp is less than 1 and greater than or equal to zero.
Historically, when we've added new datasets to the PDP, we've normalized the time variable so that the first timestamp is in that range. We could skip that step if the PDP front end was a little smarter about time variables.
In order for the front end to handle files with offsettimevariables, it would need to look at the actual time data, and not just the time metadata.
The PDP front end accesses metadata about the
time
variable of file in order to know how to translate a user's request for data from certain calendar dates to which indexes of the time variable in the file it needs to send.Currently in pdp_raster_map.js, the front end consults the two PyDAP metadata APIs, DAS and DDS.
The DAS API provides it metadata on all variables, including the
time
variable:The DDS API tells it how many timestamps the file has.
So the front end knows how many timestamps there are, and the units of the timestamps (
days since 1950-01-01
) but it has no way to tell from the metadata what the actual first timestamp is. So it always assumes the first timestamp is less than 1 and greater than or equal to zero.The front end will correctly handle this file:
But not this one:
Historically, when we've added new datasets to the PDP, we've normalized the
time
variable so that the first timestamp is in that range. We could skip that step if the PDP front end was a little smarter abouttime
variables.In order for the front end to handle files with offset
time
variables, it would need to look at the actualtime
data, and not just thetime
metadata.