Thanks John (Caron)! Your explanations help clarify things and have
convinced us not to add lat/lon as coordinate variables.
Best Regards,
John Maurer
Date: Wed, 29 May 2013 15:31:41 -0600
> From: John Caron <caron at unidata.ucar.edu>
> To: cf-metadata at cgd.ucar.edu
> Subject: Re: [CF-metadata] CF-1.6 DSG clarification: time series &
> lat/lon coordinates
> Message-ID: <51A673BD.3000707 at unidata.ucar.edu>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
> Hi John:
>
> 1) The coordinates attribute is not new to DSG, it has been around since
> the beginning of CF. This defines the "auxiliary coordinate variables",
> that is, coordinate variables that do not follow "lat(lat)" template. I
> think it would be good if Grads et al could be upgraded to use them.
>
> 2) DSG data is 1 dimensional. The addition of extra dimensions of length
> 1 seems harmless when you know you can ignore them, but is wrong when
> you want dimensions to represent independent coordinates of the
> sampling. To see that, ask yourself what the data variables would look
> like if the dimension had length 2.
>
> float humidity(sample) -> float humidity(sample, alt, lat, lon);
>
> float humidity(sample, 1, 1, 1); // seems ok
> float humidity(sample, 2, 2, 2); // huh??
>
> it looks like a grid, and its not. there are not 2 x 2 x 2 independent
> coordinates. point data is not degenerate grid data. it has a different
> connectedness between the indices, and its this connectedness that makes
> multidimensional arrays much faster than, say, an RDBM, so throw that
> away at your peril.
>
> Im interested in hearing what Jonathan et al's data model would say
> about this. I can tell you that the CDM/TDS feature collection layer
> would break if you added the extraneous dimensions.
>
> John
>
>
> On 5/29/2013 12:35 PM, John Maurer wrote:
> > Hi all,
> > We ran into a glitch after converting one of our buoys to the new CF-1.6
> > discrete sampling geometries (DSG) format, and I'm looking for advice.
> > This dataset uses the single time series format, like the one provided
> > in the template of the CF document in Example H.4:
> >
> http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.6/cf-conventions.html#idp8320208
> .
> > The problem we discovered is that the dataset is no longer readable in
> > software clients like GrADS and Dapper/DChart (likely others) because it
> > can't find the latitude and longitude coordinates anymore.
> >
> > While the dataset previously included the lat/lon dimensions of the buoy
> > in NetCDF coordinate variables, CF-1.6 DSG no longer defines lat/lon as
> > coordinate variables. Instead, they are scalar variables which are
> > referenced by other variables (temp, salinity, etc.) via a new
> > variable-level "coordinates" attribute: e.g.
> >
> > temp:coordinates = "time lat lon alt" ;
> >
> > In order to allow the DSG datasets to continue working in existing
> > software clients that do not know yet to look for this new "coordinates"
> > variable attribute, does it break CF-1.6 DSG compliance to *also* change
> > the lat/lon scalars to coordinate variables like they used to operate?
> > Building on Example H.4, the modified dataset would look like this,
> > which is a melding of the old and new ways:
> >
> > dimensions:
> > time = 100233 ;
> > name_strlen = 23 ;
> > alt = 1 ;
> > lat = 1 ;
> > lon = 1 ;
> > variables:
> > float lon(lon) ;
> > lon:standard_name = "longitude";
> > lon:long_name = "station longitude";
> > lon:units = "degrees_east";
> > float lat(lat) ;
> > lat:standard_name = "latitude";
> > lat:long_name = "station latitude" ;
> > lat:units = "degrees_north" ;
> > float alt(alt) ;
> > alt:long_name = "vertical distance above the surface" ;
> > alt:standard_name = "height" ;
> > alt:units = "m";
> > alt:positive = "up";
> > alt:axis = "Z";
> > char station_name(name_strlen) ;
> > station_name:long_name = "station name" ;
> > station_name:cf_role = "timeseries_id";
> >
> > double time(time) ;
> > time:standard_name = "time";
> > time:long_name = "time of measurement" ;
> > time:units = "days since 1970-01-01 00:00:00" ;
> > time:missing_value = -999.9;
> > float humidity(time, alt, lat, lon) ;
> > humidity:standard_name = ?specific_humidity? ;
> > humidity:coordinates = "time lat lon alt" ;
> > humidity:_FillValue = -999.9;
> > float temp(time, alt, lat, lon) ;
> > temp:standard_name = ?air_temperature? ;
> > temp:units = "Celsius" ;
> > temp:coordinates = "time lat lon alt" ;
> > temp:_FillValue = -999.9;
> >
> > attributes:
> > :featureType = "timeSeries";
> >
> >
> >
> > Thanks for any insights on this issue!
> > Cheers,
> > John Maurer
> > Pacific Islands Ocean Observing System (PacIOOS)
> > University of Hawaii at Manoa
> >
> >
> >
> >
> > _______________________________________________
> > CF-metadata mailing list
> > CF-metadata at cgd.ucar.edu
> > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20130531/6d1dc801/attachment-0001.html>
Received on Fri May 31 2013 - 12:16:53 BST
