Error configuring annual WOA data into UAF LAS using addXML

[karlmsmith]

Reported by @kevin-obrien on 14 May 2010 19:39 UTC I'm noticing a problem in the v7.1.1 UI in regards to some Annual world ocean atlas data that I'm trying to configure. Basically, addXML creates a time axis (example below), that for some reason the las v7.1.1 UI doesn't seem to understand. This problem was solved in the NVODS server by simply removing any references to the time axis for the grid definition of the particular variable. I can accomplish the same thing for the UAF server, but it seems like this should be reported as an error.

Thing is, I'm not sure if the error is in addXML or the UI (which is why I set Roland as owner and cc'd Jeremy). The UI doesn't throw any error messages that I'm aware, it just doesn't understand the dates, I guess, so won't actually do anything with the particular data.

Here's a specific example: Running this addXML command:

> sh bin/addXML.sh -n http://ferret.pmel.noaa.gov/thredds/dodsC/data/PMEL/WOA01/english/annual/AOU_ann_anal_1deg.nc

Creates this las config XML:

<datasets>
  <id-8888bbb3ef name="World Ocean Atlas 2001 1x1 degree Annual means" url="http://ferret.pmel.noaa.gov/thredds/dodsC/data/PMEL/WOA01/english/annual/AOU_ann_anal_1deg.nc">
    <variables>
      <a00an1-id-8888bbb3ef name="apparent oxygen utilization" units="ml/l" url="#a00an1">
        <link match="/lasdata/grids/grid-Longitude-Latitude-Depth-Annual-id-8888bbb3ef" />
      </a00an1-id-8888bbb3ef>
    </variables>
  </id-8888bbb3ef>
</datasets>
<grids>
  <grid-Longitude-Latitude-Depth-Annual-id-8888bbb3ef>
    <link match="/lasdata/axes/Longitude-x-id-8888bbb3ef" />
    <link match="/lasdata/axes/Latitude-y-id-8888bbb3ef" />
    <link match="/lasdata/axes/Depth-z-id-8888bbb3ef" />
    <link match="/lasdata/axes/Annual-t-id-8888bbb3ef" />
  </grid-Longitude-Latitude-Depth-Annual-id-8888bbb3ef>
</grids>
<axes>
  <Longitude-x-id-8888bbb3ef type="x" units="degrees_east">
    <arange start="0.5" size="360" step="1" />
  </Longitude-x-id-8888bbb3ef>
  <Latitude-y-id-8888bbb3ef type="y" units="degrees_north">
    <arange start="-89.5" size="180" step="1" />
  </Latitude-y-id-8888bbb3ef>
  <Depth-z-id-8888bbb3ef type="z" units="m">
    <v>0</v>
    <v>10</v>
    <v>20</v>
    <v>30</v>
    <v>50</v>
    <v>75</v>
    <v>100</v>
    <v>125</v>
    <v>150</v>
    <v>200</v>
    <v>250</v>
    <v>300</v>
    <v>400</v>
    <v>500</v>
    <v>600</v>
    <v>700</v>
    <v>800</v>
    <v>900</v>
    <v>1000</v>
    <v>1100</v>
    <v>1200</v>
    <v>1300</v>
    <v>1400</v>
    <v>1500</v>
    <v>1750</v>
    <v>2000</v>
    <v>2500</v>
    <v>3000</v>
    <v>3500</v>
    <v>4000</v>
    <v>4500</v>
    <v>5000</v>
    <v>5500</v>
  </Depth-z-id-8888bbb3ef>
  <Annual-t-id-8888bbb3ef type="t" units="DAYS">
    <arange start="0001-07-01 14:00:00" size="1" step="1" />
  </Annual-t-id-8888bbb3ef>
</axes>

The time axis, I ''guess'', is wrong above. Since this is an annual average, there is only one step - but the UI seems to be confused, I'm guessing, with the units of DAYS - I'm not really sure where the disconnect is, actually...

As I said above, the work around for this for me is to remove the time axis so the grid definition looks like:

<grids>
  <grid-Longitude-Latitude-Depth-Annual-id-8888bbb3ef>
    <link match="/lasdata/axes/Longitude-x-id-8888bbb3ef" />
    <link match="/lasdata/axes/Latitude-y-id-8888bbb3ef" />
    <link match="/lasdata/axes/Depth-z-id-8888bbb3ef" />
  </grid-Longitude-Latitude-Depth-Annual-id-8888bbb3ef>
</grids>

But this shouldn't have to be a manual process in general, I don't think....

Migrated-From: http://dunkel.pmel.noaa.gov/trac/las/ticket/792

[karlmsmith]

Comment by @noaaroland on 15 May 2010 02:13 UTC In the V6 UI you could put whatever junk you wanted into the time axis if it only had one time step because the UI would just eliminate it from the interface. For now I'm just leaving the axis out of the definition since all components can deal with the fact that it is missing. r5198.

[karlmsmith]

Comment by steven.c.hankin on 17 May 2010 18:30 UTC Some perspectives:

It is commonly the case that the single point time axis in the file is the only documentation that places the dataset at its position in time. (Unless you rely on the filename. Ouch!). On the other hand what the heck is the intent of the single point time axis of an annual-averaged dataset? That's an odd duck.

The code at r5198 that has been removed looks on-target for most situations. A time widget that displays only the single time -- offering no real choice to the user -- seems like right-on behavior.

An alternative fix to the 55198 change would be:

1. add logic into to how addXML and/or the V7 UI processes such a time axis. As encoded in the data file it is a 1-point time axis at 0001-07-01 14:00:00. (day=182.62125) One infers that it is climatological from '''units: "DAYS since 0000-01-01''' I suppose (old Ferret-eze). For now, suppress this axis in addXML on the grounds that we don't know what to do with a single point climatological time axis. note: ''A reasonable interpretation of such a time axis might be "climatological July". This would be the wrong interpretation for this particular dataset, but that's a problem in the dataset ... and maybe a shortcoming in CF ability to express climatological datasets.)''
2. using ncML remove the twisted time axis from the dataset (we are hosting it on our own TDS server)

[karlmsmith]

Comment by @noaaroland on 24 May 2010 14:04 UTC Agreed that eliminating the time data if it's the only metadata that tells the user the time stamp of the data is not ideal. And giving the user a Hobson's choice for the date is not effective either. So I'm reopening this ticket so we can consider coding up some of the points in the comments.

addXML knows how to process such a time axis (climatological axis with a date in the middle of the year). The UI does not. We could change the code in addXML to eliminate the time axis with a single step only in the case where the axis is climatological leaving the Hobson's choice in the UI to document what time axis is being used.

[karlmsmith]

Modified by @noaaroland on 6 Jan 2011 18:45 UTC