Hi Bob,
My impulse is to agree with Jonathan Gregory -- that in the conversion
to CF the auxiliary coordinate variables must become explicit and share
the dimension sizes with the measured variables. Could your conversion
program perform this calculation? The down side is that the coordinate
variables may plump up in size to exceed the measured variable(s).
The issue highlights the compromises that occur when a single format is
conceived for both archival and interchange. A solution in this case (a
thought exercise) might be to build an OPeNDAP server that would read
the HDF-EOS files (with in-built compression mechanisms such as the one
under discussion for efficient archival) and would output a CF-compliant
DAP representation (that can be read by the standard netCDF client API).
- steve
=============================================
Bob Bane wrote:
> The increment and offset are scalars. In HDF-EOS, by convention
> either both of them are positive (meaning a small geolocation
> dimension -> larger data dimension) or both negative (large
> geolocation -> smaller data - I think they threw that one in for
> generality, not that they ever expect to see it implemented).
>
> If you have an offset of 1 and an increment of 2, then
>
> Geoloc[0] has the value for Data[1] (0 * 2 + 1)
> Geoloc[1] has the value for Data[3] (1 * 2 + 1)
> Geoloc[2] has the value for Data[5] (2 * 2 + 1)
> etc. ...
>
> This gets nasty when you want to geolocate (say) Data[2] - I was going
> to punt and do a linear interpolation, but my coworkers say I should
> consider some sort of curve fit over more points.
>
> Also, this is just the one-dimensional case - two-D will be most
> common, and the HDF-EOS API supports N-dimensions. My head hurts...
>
> - Bob
>
>
>
> -----Original Message-----
> From: Steve Hankin [mailto:Steven.C.Hankin at noaa.gov]
> Sent: Mon 8/2/2004 1:21 PM
> To: Bob Bane
> Cc: cf-metadata at cgd.ucar.edu
> Subject: Re: [CF-metadata]
>
> Hi Bob,
>
> I'll start the conversation going, because I believe that several of
> the
> principals are off on vacations ...
>
> Can you clarify the key statement
>
> "Swaths let you map data variables to geolocation variables,
> but they also allow the geolocation dimensions to be different
> sizes than the data dimensions - the mapping between the
> dimensions contain offset and increment values so that, in the
> one-dimensional case:
>
> Geoloc(i) is mapped to Data(i * increment + offset)"
>
> In the example that you have given ("Data(i * increment + offset)")
> the
> transformation does not appear to have changed the dimensionality --
> there is still the single index "i". Are "increment" or "offset"
> arrays
> rather than scalars?
>
> thanks - steve
>
> ======================================================================
>
> Bob Bane wrote:
>
> > I'm in the middle of updating a program that converts HDF-EOS files
> to
> > netCDF. The old version is available here:
> >
> > http://hdfeos.gsfc.nasa.gov/hdfeos/details.cfm?swID=84
> >
> > It converts HDF-EOS5 files to netCDF, and attempts to preserve
> COARDS
> > compliance (if the original file had COARDS-compatible metadata, so
> > will the new one).
> >
> > The updated version is going to handle both HDF-EOS2 and HDF-EOS5
> > (which already works), and I now want to make it CF-compatible. The
>
> > auxiliary coordinate variables conventions in particular look like a
>
> > good fit for the HDF-EOS Swath datatype, except for one thing.
> >
> > Swaths let you map data variables to geolocation variables, but they
>
> > also allow the geolocation dimensions to be different sizes than the
>
> > data dimensions - the mapping between the dimensions contain offset
> > and increment values so that, in the one-dimensional case:
> >
> > Geoloc(i) is mapped to Data(i * increment + offset)
> >
> > As near as I can tell from the CF spec, auxiliary coordinate
> variables
> > must have the same size dimensions as their corresponding data
> > variables, so there's no way to translate a Swath to CF-compliant
> > netCDF without expanding and interpolating the gelocation variables
> to
> > make them match the data dimensions. Does this make sense, or am I
> > missing something?
> >
> > - Bob
> >
> >
> > ----------------------------------------------------------------
> > _______________________________________________
> > CF-metadata mailing list
> > CF-metadata at cgd.ucar.edu
> > http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata
> >
> --
>
> Steve Hankin, NOAA/PMEL -- Steven.C.Hankin at noaa.gov
> 7600 Sand Point Way NE, Seattle, WA 98115-0070
> ph. (206) 526-6080, FAX (206) 526-6744
>
>
--
Steve Hankin, NOAA/PMEL -- Steven.C.Hankin at noaa.gov
7600 Sand Point Way NE, Seattle, WA 98115-0070
ph. (206) 526-6080, FAX (206) 526-6744
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20040803/24c319f3/attachment.html>
-------------- next part --------------
An embedded message was scrubbed...
From: Jonathan Gregory <j.m.gregory at reading.ac.uk>
Subject: RE: [CF-metadata]
Date: Tue, 3 Aug 2004 16:18:37 +0100
Size: 4088
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20040803/24c319f3/attachment.mht>
Received on Tue Aug 03 2004 - 10:35:30 BST
