The WCPS spec is interesting, thanks for posting, I havent seen it before.
And Roy is, of course, 80% correct ;^)
On 6/19/2012 9:58 AM, Matthias Müller wrote:
Roy, all,
(at least WPS can be used to express I/O parameters of a function.)
However, if you are looking for "the key question of the syntax of the
expressions" the OGC WCPS language interface standard might provide a
solution:
http://www.opengeospatial.org/standards/wcps
It "... defines a protocol-independent language for the extraction,
processing, and analysis of multi-dimensional gridded coverages
representing sensor, image, or statistics data."
Regards,
Matthias
Am 19.06.2012 17:27, schrieb Roy Mendelssohn:
Hi All:
Ah, as usual I get to be the wet blanket. I am not as excited about
WPS, or for that matter most OGC standards, as others, because I find
since OGC tries to answer the general question, the resultant
services have to deal with the most complex case, therefore the 80%
of uses cases that aren't that complex are burdened with overly
complex services, that are difficult for the average user, and
require constant update of software, and software that is hard to
embed into existing applications.
Most of what a lot of us do are essentially read-only services. For
these, I much prefer the basic approach presently used by F-TDS and
GDS, though there can be discussion of how best to connote an
expression, and what the syntax should be. Even more, as has been
noted, WPS does not solve the key question of the syntax of the
expressions.
So I know this will start a lot of flames, but I just look at the
service that we developed and use, ERDDAP. All sorts of people, who
only know a little programming, successful use ERRDAP in R, Matlab,
shell scripts, python, java etc., and it is easy to use from within
applications, because any environment that can send a URL and receive
a file can use it. Moreover, since only methods internal to the
applications are used, the scripts or programs or whatever do not
break as both the application and operating environment change.
Our experience over many years of serving data is that in most cases,
simple and fast are to be preferred. Clearly people can come up with
counter cases that are not covered, and I am all for developing
services for those cases, but not for burdening simpler cases with
all that baggage.
My $0.02.
-Roy
On Jun 19, 2012, at 12:14 AM,<stephen.pascoe@xxxxxxxxxx> wrote:
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.
_______________________________________________
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/
