[Go-essp-tech] Time metadata in ESG published files...

[Drach, Bob]

OK, I'll take a look at correcting this. --Bob

From: Roland Schweitzer <roland.schweitzer at noaa.gov<mailto:roland.schweitzer at noaa.gov>>
Date: Thu, 16 Feb 2012 12:01:12 -0800
To: "go-essp-tech at ucar.edu<mailto:go-essp-tech at ucar.edu>" <go-essp-tech at ucar.edu<mailto:go-essp-tech at ucar.edu>>
Subject: [Go-essp-tech] Time metadata in ESG published files...

Hi,

Bob, I think this is primarily addressed to you.

When looking at the data published at GFDL, I see what I think it a mistake in the time information that is in the THREDDS catalog.

With this URL: http://esgdata.gfdl.noaa.gov/thredds/esgcet/1/cmip5.output1.NOAA-GFDL.GFDL-CM3.1pctCO2.mon.atmos.Amon.r1i1p1.v20110601.xml

An aggregation looks like this:

<dataset name="cmip5.output1.NOAA-GFDL.GFDL-CM3.1pctCO2.mon.atmos.Amon.r1i1p1.ccb.20110601.aggregation"
         ID="cmip5.output1.NOAA-GFDL.GFDL-CM3.1pctCO2.mon.atmos.Amon.r1i1p1.ccb.20110601.aggregation" restrictAccess="esg-user">
  <property name="aggregation_id" value="cmip5.output1.NOAA-GFDL.GFDL-CM3.1pctCO2.mon.atmos.Amon.r1i1p1.ccb.20110601.aggregation"/>
  <variables vocabulary="CF-1.0">
    <variable name="ccb" vocabulary_name="air_pressure_at_convective_cloud_base" units="Pa">Air Pressure at Convective Cloud Base</variable>
  </variables>
  <metadata inherited="true">
    <geospatialCoverage>
      <northsouth>
        <start>-89.0</start>
        <size>178.0</size>
        <units>degrees_north</units>
      </northsouth>
      <eastwest>
        <start>1.25</start>
        <size>357.5</size>
        <units>degrees_east</units>
      </eastwest>
    </geospatialCoverage>
    <timeCoverage>
      <start>0001-01-16T12:00:00</start>
      <end>0140-12-16T12:00:00</end>
    </timeCoverage>
  </metadata>
  <access
     urlPath="?catid=55B48299F30BC9828F9E93A18AFAA2FC_ns_cmip5.output1.NOAA-GFDL.GFDL-CM3.1pctCO2.mon.atmos.Amon.r1i1p1.ccb.20110601.aggregation"
     serviceName="LASatGFDL" dataFormat="NetCDF"/>
  <dataset name="cmip5.output1.NOAA-GFDL.GFDL-CM3.1pctCO2.mon.atmos.Amon.r1i1p1.ccb.20110601.aggregation - Subset 1"
     ID="cmip5.output1.NOAA-GFDL.GFDL-CM3.1pctCO2.mon.atmos.Amon.r1i1p1.ccb.20110601.aggregation.1"
     urlPath="cmip5.output1.NOAA-GFDL.GFDL-CM3.1pctCO2.mon.atmos.Amon.r1i1p1.ccb.20110601.aggregation.1" restrictAccess="esg-user">
    <serviceName>gridded</serviceName>
    <property name="aggregation_id" value="cmip5.output1.NOAA-GFDL.GFDL-CM3.1pctCO2.mon.atmos.Amon.r1i1p1.ccb.20110601.aggregation.1"/>
    <property name="time_delta" value="1 month"/>
    <property name="calendar" value="noleap"/>
    <property name="start" value="1-1-1 0:0:0.0"/>
    <property name="time_length" value="1680"/>
    <access urlPath="?catid=55B48299F30BC9828F9E93A18AFAA2FC_ns_cmip5.output1.NOAA-GFDL.GFDL-CM3.1pctCO2.mon.atmos.Amon.r1i1p1.ccb.20110601.aggregation.1"
            serviceName="LASatGFDL" dataFormat="NetCDF"/>
  </dataset>
</dataset>

The time coverage metadata has the correct start time for the aggregation (16-Jan-0001 12:00), but the extra property which LAS depends on to initialize itself the wrong start time (01-Jan-0001).  This is causing many data sets to have their initial plot fail when LAS is started.  The reason for the failure are complicated based on trying to find the closest time point in the data for the requested time (1-jan-0001) which turns out to be the previous month which does not exist.

We can work on coding around this , but in the end I think fixing the publisher to be more strict about what it puts as the value of the start property would be a big help to us.

Roland



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ucar.edu/pipermail/go-essp-tech/attachments/20120216/5cbacbba/attachment-0001.html