[thredds] Station Data Subset Service vs. OPeNDAP constraint expressions


I read about the new Station Data Subset Service (I'll call it SDSS in this email)
(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
(=~ 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.


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
<>< <>< <>< <>< <>< <>< <>< <>< <><

  • 2010 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the thredds archives: