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 <ca...@unidata.ucar.edu> > To: cf-metadata@cgd.ucar.edu > Subject: Re: [CF-metadata] CF-1.6 DSG clarification: time series & > lat/lon coordinates > Message-ID: <51a673bd.3000...@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@cgd.ucar.edu > > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata >
_______________________________________________ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata