Not-Quite-Web Processing Service
I had a longer post about the new WPS specification that I scrapped after I realized that it reduces to this: the OGC WPS working group gets the formats and parameters more or less right as usual (good), but still can't find any respect for HTTP as an application protocol (bad).
Web geo-processing came up at tonight's meetup in the form of this question: how do I compute zonal statistics on a raster over the web using open source? I said that GRASS would be part of the answer. It wasn't until the meeting broke up that I realized I'd neglected to mention PyWPS, which has a tantalizing kernel of Pythonic goodness.
Meanwhile, it looks like ESRI's ArcGIS Server might be the prime mover for RESTful geo-processing this year.
Update: or maybe it won't. This is not exactly an endorsement by Vish.
Comments
Re: Not-Quite-Web Processing Service
Author: Stefano Costa
Sean, it's worth noting that PyWPS is heavily based on GRASS (or other programs like R and GDAL/OGR) for all its analytical functions. See http://pywps.ominiverdi.org/ for some live examples. That said, I'll wait for another post from you about RESTful geoweb services to learn something about it.Re: Not-Quite-Web Processing Service
Author: Sean
Yes, that was my point about PyWPS: that it has solved the problem of calling GRASS routines in the context of a web request, and is therefore worth looking at despite my concerns about the WPS protocol.