NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTE: The galeon mailing list is no longer active. The list archives are made available for historical reasons.
Hi Peter (and others), as I wrote in the wiki, we have recently tested your server with our WCS Browser Lite and can report the following: as by your wsdl, you implement WCS as a SOAP rpc/encoded service. On the other hand, WCS Browser Lite expects a document/literal service (so is WCS-G, for instance); this is of course a major interoperability problem (ehr, wasn't SOAP meant for helping out?) Apart from discussing the pros and cons of the various options, I think this is a valuable result in itself: it is probably time for a standard WCS wsdl. BTW, I remember you were implementing WCS 1.1 specs: is it so? In this case, we would have some problems more, since we only address WCS 1.0 (pre-amended... :-) Regards, L
Hello Martin, thanks for trying our service! Yes indeed, we fully bought us into SOAP. However, as you only seem to need a GetCap request in non-SOAP, Ivan is about to implement a GET type GetCap. Unfortunately with resources given we can't change the GetCov to a GET request; the problem is that axis is the (SOAP-) wrapper around the service, so we'd need to re-interface. Ivan will inform you when he has finished the GetCap using GET, hopefully we then get a step further. ...in addition to this thread: anybody out there having a SOAP based client? thanks, Peter
galeon archives: