Thanks for your reply Ethan.
As I understand it, both TDS 4.x and 3.x implement the WCS 1.0.0 spec.
(I see upcoming support for 1.0.0.1 and 1.0.0.11 listed in the docs).
However, since the GetCapabilities response is slightly different
between TDS 3.x and 4.x - does it mean that one of them does not
"correctly" implement the 1.0.0 spec?
Can I provide a static GetCapabilities xml that TDS will use instead of
it's automatically generated response?
The response I'm getting from ESRI's ArcGIS Desktop client is something
generic like "unable to add layer". It does seem to parse the
GetCapabilities response. ArcGIS does work w/ TDS 3.x. I'll try to
access 4.x w/ other clients and also take up the question w/ ESRI.
Finally, should it make any difference to TDS if the underlying data is
on a NFS mount or on local disk?
--john
Ethan Davis wrote:
> Hi John,
>
> John Cartwright wrote:
>
>> it appears that TDS 4.0.17 is returning a slightly different XML
>> response for a GetCapabilities response than 3.16. I'm also finding
>> that ESRI clients cannot consume the 4.0.17-hosted version while the
>> 3.16-hosted version works OK. This second issue may be unrelated to the
>> first.
>>
>> Is a difference in the responses between the versions expected?
>>
>
> Yes. I did a lot of refactoring and rewriting of the WCS code for TDS
> 4.0. So, I'd be surprised if there weren't some differences.
>
>
>> I've attached two examples for comparison.
>>
>
> Not a lot of difference. Mainly, the 4.0 version: 1) doesn't have all
> the namespace/schema information in the root element; 2) the "Service"
> element is missing "description", "name", "label", and "keywords"
> elements [Hmm!]; and 3) the "lonLatEnvelope@srsName" value is different
> (should be a recognizable OGC CRS URN).
>
> Are you getting any error messages from the ESRI clients?
>
> My guess is that either 1) the ESRI client expects a "Service/name" or
> "Service/label" element 2) there is some difference in the HTTP headers
> and such that the ESRI clients don't like.
>
> Ethan
>
