We are working on wrapping CDO operators in our WPS implementation COWS-WPS. This work is being done as part of the IS-ENES an ExArch projects with with DKRZ, KNMI and others. WPS doesn't define your functions for you but gives you a protocol and framework for asynchronous server-side tasks. http://cows.ceda.ac.uk/cows_wps/intro.html -- Stephen Pascoe from iPhone On 18 Jun 2012, at 23:07, "John Cartwright" <john.c.cartwright@xxxxxxxx> wrote: > Could the the OGC's Web Processing Service spec > (http://en.wikipedia.org/wiki/Web_Processing_Service) serve that > function? > > --john > > > On Mon, Jun 18, 2012 at 3:56 PM, Roy Mendelssohn > <roy.mendelssohn@xxxxxxxx> wrote: >> But for a useful service, the form and syntax of the URL should be >> independent of the mechanism that does the server side calculations (which >> rules out SWAMP). So for example, both Grads an F-TDS use the same format >> in the URL to say that "this is an expression", but the expressions >> themselves are platform specific. That is not the way to get overarching >> services. >> >> Instead, we need agreement on how in the URL request we signal a server-side >> function, the syntax of that function (independent of the engine underneath) >> and a few simple functions to start (say simple data transformations, >> differencing and averaging on a dimension(s)). Then the server back-end can >> parse the request and use Ferret or Grads or NCO or Python or whatever is >> desired, and like with any good service, the back end could change without >> having any affect on the URL or the user. >> >> I know Matthew Arrott at least used to like the approach in Chapter 12 of >> "Python Scripting for Computation Science". But a lot of that is the engine >> underneath. I am more interested in the form of the URL. Get some >> agreement on that, and some real implementation could proceed. >> >> -Roy >> >> >> >> >> >> On Jun 18, 2012, at 2:37 PM, Russ Rew wrote: >> >>> Jeff, >>> >>>> However, we have to keep in mind performance ramifications. It still takes >>>> a long time to move gigabytes of data across a network. This brings up the >>>> importance of moving the computation to the data, instead of moving the >>>> data to the computation. For some data sets and many use cases remote >>>> access to data works very well so things like brokering are tractable. >>>> However, for *big* data sets (e.g., climate model output) we need to come >>>> up with richer mechanisms (like the NCO on local data) to bring computation >>>> to the data. >>> >>> See Daniel Wang's SWAMP (the Script Workflow Analysis for >>> MultiProcessing), built on top of NCO: >>> >>> https://code.google.com/p/swamp/ >>> >>> --Russ >>> >>> _______________________________________________ >>> thredds mailing list >>> thredds@xxxxxxxxxxxxxxxx >>> For list information or to unsubscribe, visit: >>> http://www.unidata.ucar.edu/mailing_lists/ >> >> ********************** >> "The contents of this message do not reflect any position of the U.S. >> Government or NOAA." >> ********************** >> Roy Mendelssohn >> Supervisory Operations Research Analyst >> NOAA/NMFS >> Environmental Research Division >> Southwest Fisheries Science Center >> 1352 Lighthouse Avenue >> Pacific Grove, CA 93950-2097 >> >> e-mail: Roy.Mendelssohn@xxxxxxxx (Note new e-mail address) >> voice: (831)-648-9029 >> fax: (831)-648-8440 >> www: http://www.pfeg.noaa.gov/ >> >> "Old age and treachery will overcome youth and skill." >> "From those who have been given much, much will be expected" >> "the arc of the moral universe is long, but it bends toward justice" -MLK Jr. >> >> _______________________________________________ >> thredds mailing list >> thredds@xxxxxxxxxxxxxxxx >> For list information or to unsubscribe, visit: >> http://www.unidata.ucar.edu/mailing_lists/ > > _______________________________________________ > thredds mailing list > thredds@xxxxxxxxxxxxxxxx > For list information or to unsubscribe, visit: > http://www.unidata.ucar.edu/mailing_lists/ -- Scanned by iCritical.