John,
I read about the new Station Data Subset Service (I'll call it SDSS in
this email)
http://www.unidata.ucar.edu/projects/THREDDS/tech/interfaceSpec/StationDataSubsetService.html
(version 0.2), which lists you as the contact. I understand that the
UAF group is considering using SDSS to deal with station data.
I noticed that SDSS queries are very similar to OPeNDAP constraint
expression queries (
http://www.opendap.org/user/guide-html/guide_33.html ).
Yet, SDSS seems limited to one type of dataset (stations with time,
latitude, longitude, ... data, because it uses specific variable names,
e.g., stn, north, south, west, east, time for the constraints) while
OPeNDAP constraint expressions can be used with a much broader range of
datasets, notably, any dataset that can be represented as a
database-like table, because it isn't tied to any specific variable
names. And OPeNDAP's bigger set of operators (=, <, <=, >, >=, !=, =~)
can be applied to any variable, not just longitude/latitude/depth/time/stn.
The sample queries in the SDSS documentation can easily be converted to
OPeNDAP constraint expression queries, for example:
SDSS: ?north=17.3&south=12.088&west=140.2&east=160.0
OPeNDAP: ?latitude<=17.3&latitude>=12.088&longitude>=140.2&longitude<=160.0
SDSS: ?stn=KDEN
OPeNDAP: ?stn="KDEN"
SDSS: ?stn=KDEN&stn=KPAL&stn=SDOL
OPeNDAP: ?stn=~"KDEN|KPAL|SDOL"
(=~ lets you specify a regular expression to be matched)
SDSS: ?time_start=2007-03-29T12:00:00Z&time_end=2007-03-29T13:00:00Z
OPeNDAP: ?time>="2007-03-29T12:00:00Z"&time<="2007-03-29T13:00:00Z"
SDSS' accept=mime_type could be mimicked by having the OPeNDAP server
support file extensions in addition to .dods and .asc (or by some other
means if necessary). And mime types have a problem if two file types
share the same mime type.
OPeNDAP's sequence data type is well-suited to this type of data query
and to the API described at
http://www.unidata.ucar.edu/software/netcdf-java/reference/FeatureDatasets/PointFeatures.html
.
I have worked quite a lot with OPeNDAP constraint expressions and I have
found them to be
* Very flexible (well-suited to a wide range of datasets and queries),
* Very easy for non-programmers to read, write, and understand,
* Easy to convert into queries for other types of data servers (e.g.,
SQL, SOS, OBIS),
* Easy for data servers to handle and optimize.
They are sort of like a nice subset of SQL with a really simple syntax.
All of this discussion leads up to this:
I'm very curious: why did you decide to define a new protocol instead of
using the existing standard OPeNDAP constraint expression protocol?
And/or, would you consider switching to the OPeNDAP constraint
expression protocol?
Instead of creating a new service with one server implementation
(THREDDS) and one client implementation (netcdf-java), switching to
OPeNDAP constraint expressions would hook your service into the realm of
other servers and clients that already support OPeNDAP constraint
expressions.
And supporting OPeNDAP constraint expressions in THREDDS seems like a
logical extension for a data server which already supports OPeNDAP
grid/hyperslab queries.
I am very curious to hear your thoughts on this.
Thanks for considering this.
Sincerely,
Bob Simons
IT Specialist
Environmental Research Division
NOAA Southwest Fisheries Science Center
1352 Lighthouse Ave
Pacific Grove, CA 93950-2079
Phone: (831)658-3205
Fax: (831)648-8440
Email: bob.simons@xxxxxxxx
The contents of this message are mine personally and
do not necessarily reflect any position of the
Government or the National Oceanic and Atmospheric
Administration.
<>< <>< <>< <>< <>< <>< <>< <>< <><
