Talk:Web Services

This is a follow-up on today's telecon:

GMU WMS Service.

We have discussed the WCS-Modis data access from GMU to DataFed, Service_Interoperability_Tests As it is, the service is not directly usable. The problems include finding granules, encoding time query, very slow (7Kb/sec) data transfer, etc. All of these are stated in the above report and where discussed at the telecon. It is my understanding that a WCS service could be constructed by JPL/GMU, which uses BBOX and TIME to specify the location and time range of the requested data. We will be happy to help out with the implementation of the WCS service, but we cannot help with the granule finding. Rhusar 23:36, 9 May 2006 (EDT)

The granule finding problem can be solved through calls to GMU CSW(catalog service for web) service. In the CSW, user can specify the bbox, the time, and the data parameter they want, and then the CSW service will return the metadata for the matched granules. The returned metadata is detail enough for you to construct a valid WCS getCoverage call. CSW getRecord and then WCS getCoverage are the supposed OGC calling sequence for accessing large data archive. The getCapabilities in WCS is useless for large data archive. Peisheng can help you on CSW getRecord call and the construction of the WCS getCoverage call from the results. Please contact him on this. Liping

The fact that the GMU WMS/WCS service doesn't have all of the features you want is a symptom of the fact that the WCS standard does not *require* all of the features that we need. Obviously, your SOAP-ifying WCS effort and the GALEON project are heading in the right direction, but the fact that this isn't all ironed out, and isn't required as part of implementing a

WCS server, currently reduces the usefulness of WCS as a universal standard for all Earth Science data needs. I'm sure the situation will improve but we aren't there yet. Thus, whether you are using WCS or SOAP services, you need some cooperation from your collaborators to agree on the *real* interface and *capabilities*.Brian D. Wilson (BrianWilson)

JPL Granule Finder Service.

Brian, it would be helpful if you would specify the URL pattern which is used to find data granules in a specific BBOX and TIME range. In other words, an HTTP Get version for your data query form. At this time it does not matter which particular dataset is queried. Hopefully, the above query for granules can have the same pattern regardless of the dataset. I would like to experiment with either the HTTP Get or the SOAP version of your granule finder service. Rhusar 23:36, 9 May 2006 (EDT)

Interoperable Data Access.

Eric was asking if we are heading away from standard interfaces back into the dark ages of hand-crafted interfacing. Clearly, we are pursuing a path towards standard interfaces. The WCS interface has the promise to be the "universal" query language for most of the Earth Science data. So, in order to be interoperable we would have to adapt and homogenize our data access interfaces to WCS, either using HTTP Get or SOAP protocols. On this page you will find the description of the SOAP-wrapped version of WCS. SOAPifying_WCS Rhusar 23:36, 9 May 2006 (EDT)

Interoperability Experiments.

The pursuit of WCS as the "universal" data access interface is the topic of other interoperability experiments, GALEON, GSN, both coordinated by OGC. We have added a page to the ESIP wiki that lists and briefly describes these efforts. Service_Interoperability_Experiments Rhusar 23:36, 9 May 2006 (EDT)

Rationale for WCS.

We have been maintaining a page on ESIP wiki in which the rationale for WCS as well as its main features are described. WCS_for_Earth_Science_Data_Access. At this time the page only contains ppt slides. However, this page along with its "talk" discussion page can serve for collecting and exchanging our respective ideas on this matter. Rhusar 23:36, 9 May 2006 (EDT)