NOAA-PMEL / LAS

Live Access Server
https://ferret.pmel.noaa.gov/LAS/
The Unlicense
13 stars 5 forks source link

configuration for time-labels in the Annotations #1773

Closed AnsleyManke closed 4 years ago

AnsleyManke commented 4 years ago

The NASA folks serve mostly monthly data and they feel that time labels like this 15-MAR-2000 00:00 or even 01-OCT-2015 14:08

should be Mar-2000 or Oct-2000. Both of these are meant to indicate just "the month of" but are listed using the timestep from the file.

There's an old ferret-property in the LAS PyFerret scripts, ferret_timelab_res which should do this if it doesn't already.

AnsleyManke commented 4 years ago

We have a Ferret property timelab_res which makes a global setting in PyFerret for all time labels it writes out. So this is just a matter of the NASA folks putting this into the configuration for their monthly time datasets and the time labels will be TIME : Feb 2020

However, some of their datasets have time axes that are defined in such a way that this needs a tweak. From my email to Penny:

For example, https://mynasadata.larc.nasa.gov/thredds/dodsC/EarthSystemLAS/atmos_temp/data_https___mynasadata.larc.nasa.gov_thredds_dodsC_MERRA2_T2M_agg_k_to_c_T2M_T2M.jnl has the time coordinates in the file defined with units of a "month", starting at the beginning of a month, in this case 1-Jan-1980. Somebody creating that data thought it seemed like a nice simple way to do it, but it doesn't do what was intended when we treat time in the standard way.

If you ask for data in Jan 1990, the date shown is 31-Dec-1989, because "month" is kind of a fuzzy definition. A month it's taken to mean 1/12 of a 365.2425-day year, so month number 121 is computed that way, and that time happens to fall at 31-DEC-1989 10:12. This means that the times never fall right on the month boundaries, but neither do they start to drift off as they would if we made them 30 days long or something. Then the data is assumed to be centered on that listed date, representing data from mid-December to mid-January. We need a rigorous way to define time so that computation using time info can be done accurately.

What we can do is compare the time requested through the UI, 1-jan-1990, with the time computed from the time-axis definition, Dec-1989, and if they're different make a correction so the TIME label is Jan 1990.

This is done in a few lines in the script reset_labels.jnl