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
>
Received on Wed May 29 2013 - 15:31:41 BST
