01-22-2018 09:25 AM
I create a service from the Data Manager, if we use the WFS of the service from the Geospatial Portal it works just fine.
But if I try to use the WMS, it does not display anything, it dowload a file that is a XML of the service, but I want to display the service on the browser.
I tried it just with the URL I got from the link on the Geospatial Portal but happens the same.
If I use the WMS of any data set of the Apollo Catalog, It display on the browser normally
The WMS URL works just fine, is just the way is displaying on browser.
Do you have any idea to change the way to display the WMS service?
01-23-2018 05:58 AM
I understand now what you mean.
With a WFS service (registered in the catalog), the "Access: WFS" redirects you to the describeFeatureType of the selected feature and the result is an XML and can be opened automatically by the browser.
With a WMS service (registered in the catalog), the "Access: WMS" redirects you to the getLayer of the selected layer if it is an APOLLO legacy service or to the full getCapabilities if it is not a legacy service (other service provider). The reason is that the getLayer is not an OGC standard request. For the APOLLO legacy services it allows to get a subset of the getCapabilities like a describeFeatureType does for a WFS.
The issue for you is that the getLayer returns a XML formatted message but the Content-Type (response header) is not "text/xml" ("application/vnd.ogc.wms_xml" instead). Not sure if it is a bug or a WAD but in both cases I don't see any case where it could be a problem.
01-23-2018 07:04 AM - edited 01-23-2018 07:04 AM
Camilo to display your link in a browser, you can add the version 1.3.0 as request parameter so you will get the an xml type known by the browser.
01-24-2018 08:40 AM
thanks a lot for your help, I already reported this information to the client.
But I am wondering if there is any way to change the WMS access so it redirect to the URL with the version 1.3.0 request as default instead of adding this manually.
01-25-2018 06:01 AM - edited 01-25-2018 06:03 AM
If no version is specified the server (apollo) should return the highest version according ogc standard
So it are bug it does not do that by deafult
Ref: [Part 6.1.4, "OpenGIS® Web Map Service Implementation Specification version 1.1.1 (OGC dokument 01-068r3)"]
All Capabilities XML shall include a protocol version number. In response to a GetCapabilities request containing a version number, an OGC Web Service shall either respond with output that conforms to that version of the specification, or negotiate a mutually agreeable version if the requested version is not implemented on the server. If no version number is specified in the request, the server shall respond with the highest version it understands and label the response accordingly.
Ref: [Part 6.2.4, "OpenGIS® Web Map Service (WMS) Implementation Specification, version 1.3.0 (06-042)"]
All service metadata shall include a protocol version number and shall comply with the XML DTD or Schema defined for that version. In response to a GetCapabilities request (for which the VERSION parameter is optional) that does not specify a version number, the server shall respond with the highest version it supports. In response to a GetCapabilities request containing a version number that the server implements, the server shall send that version. If the server does not support the requested version, the server shall respond with output that conforms to a version it does support, as determined by the following rules...
01-25-2018 08:25 AM - edited 01-25-2018 08:31 AM
Thanks hm for the clarification.
But as the getLayer is not an OGC request...
Anyway, you are right, the best practice would be to return the highest version also with the getLayer.
And another best practice would be that the Portal doesn't use the getLayer because any OGC service (not only an APOLLO legacy one) can be registered in the catalog. So the response shouldn't be different.