Dapper in-situ conventions spec available

[John Caron]

Jennifer M. Adams wrote:
> Dear All,
> As a GrADS developer, I have multiple issues/concerns/ideas regarding 
> serving and accessing in situ data via OPeNDAP.  GrADS is a natural 
> client for this data type, as it already has an internal data model for 
> in situ data, with many built-in functions for the display and analysis 
> of the data. For two years, GDS has been serving in situ data -- surface 
> obs in real time -- with 4000-9000 hits per month over the past year. 
> Not overwhelming, but the usage has been consistent. 
> 
> Now that Dapper, the THREDDS Data Server, and OPeNDAP Server 4 are also 
> out there, I think it would be wonderful if there were  some consistency 
> in the way these data are presented to the world. I think a spec or set 
> of conventions is a great idea -- it certainly seems like it would make 
> my life easier when trying to enable GrADS to be a client for all the 
> possible servers that users will want to access. 
> 
> To get GrADS to read Dapper, I had to make a few changes that reflect 
> the differences between GDS and Dapper conventions: 
> 1. The variable "Int32 _id"  in Dapper is the analog to the  "String 
> stid" variable in GDS 
> 2. Time axis information is presented a little differently
> 3. Constraint protocol and syntax (the reason why GrADS 1.9 can't access 
> the new Dapper)
> 
> The more significant difference between GDS and Dapper is that Dapper 
> presents a time series from a single station as a 2D nested sequence, in 
> the same way you would present a vertical profile at a single time. Why 
> complicate things by have two meanings for the inner sequence? Swapping 
> Z and T as variables for the inner and outer sequences seems like it's 
> defeating the purpose of having a convention. I prefer the simpler 
> notion that it's a 2D sequence if the data at the same location vary in 
> height/depth, if not, it's a 1D sequence. 

I thought that the time series from a single station is just one of the inner sequences, and the outer sequencce comes from having a collection of different stations.

> 
> I suspect the real problem is that there is no NetCDF standard for this 
> data type. As soon as one is developed, and an API is available for 
> subsetting on variables as well as coordinates, then I reckon everyone 
> will jump to that standard and this whole discussion will become an 
> artifact of history. Anything on this brewing at UCAR? 

We've been working on a netCDF-3 file convention for storing observation data, and we are studying if we can map these files into the dapper spec. A lot of the problems have to do with efficiently implementing the projections. The CDM PointObs Datatype is then an API for doing the space/time subsetting on these files or on dapper datasets. All still experimental, but a start.

See

 http://www.unidata.ucar.edu/software/netcdf-java/formats/UnidataObsConvention.html

if you are interested in the netcdf-3 file spec.

> 
> Jennifer 
> 
> --
> Jennifer M. Adams
> IGES/COLA
> 4041 Powder Mill Road, Suite 302
> Beltsville, MD 20705
> jma at cola.iges.org <mailto:jma at cola.iges.org>
> 
> 
>