Editing capabilities document in GeoServer

Question

I've got several layers in GeoServer, one of which I'm trying to use as a WMS in desktop programs (Manifold 8). I've set it up correctly, but whenever I bring it into Manifold, it projects the layer into EPSG:4326, which unfortunately can't work with my map - I need it in EPSG:3857.

The layer in question is wrapped inside a more overarching layer definition, which contains all the layers - and coordinate systems that allow them all to be used flexibly. However, I want to put this layer on its own in the capabilities document, and only allow it to use EPSG:3857.

How, in GeoServer, would I edit, or override, a capabilities document?

Answer 1

You can do a GetCapabilities request, copy the response, and put it in a public web folder, for example, save as MyStaticGCresponseVersionmno.xml then edit this file and remove the <CRS>CRS:84</CRS>, any BoundingBox (<BoundingBox CRS="CRS:84"...), and also change the URL for the GetCapabilities requests (<OnlineResource xlink:type="simple" xlink:href="..."/>) to the static file location.

Then you can use this 'static' file as the service URL.

That works for most clients, but it will fail a WMS validator.

Alternatively you could use MapServer, and cascade the GeoServer service through it.

For example,

Here is a GeoServer WMS service:

http://13.95.69.121/geoserver/erl/ows?service=WMS&request=GetCapabilities

with

<GetCapabilities>
<Format>text/xml</Format>
<DCPType>
<HTTP>
<Get>
<OnlineResource xlink:type="simple" xlink:href="http://13.95.69.121:80/geoserver/erl/ows?SERVICE=WMS&"/>
</Get>
<Post>
<OnlineResource xlink:type="simple" xlink:href="http://13.95.69.121:80/geoserver/erl/ows?SERVICE=WMS&"/>
</Post>
</HTTP>
</DCPType>
</GetCapabilities>

and ...

in the mineralOccurrenceView layer

<KeywordList>
<Keyword>features</Keyword>
<Keyword>mineraloccurrence</Keyword>
<Keyword>earth resource</Keyword>
<Keyword>mineral resource</Keyword>
<Keyword>mineral occurrence</Keyword>
<Keyword>mineral deposit</Keyword>
<Keyword>mine</Keyword>
</KeywordList>

This service was being used in a portal which uses keywords to trigger functionality. To test the keywords quickly (client developers were not service providers) a static file version of this file was created:

http://ogc.bgs.ac.uk/OWS/GTK.xml

with the OnlineResource changed thus.

<GetCapabilities>
<Format>text/xml</Format>
<DCPType>
<HTTP>
<Get>
<OnlineResource xlink:type="simple" xlink:href="http://ogc.bgs.ac.uk/OWS/GTK.xml"/>
</Get>
</HTTP>
</DCPType>
</GetCapabilities>

Other OnlineResources remain the same (point to the actual service).

but keywords were change for the layer like:

  <KeywordList>
      <Keyword>features</Keyword>
      <Keyword>mineraloccurrence</Keyword>
      <Keyword>earth resource</Keyword>
      <Keyword>mineral resource</Keyword>
      <Keyword>mineral occurrence</Keyword>
      <Keyword>mineral deposit</Keyword>
      <Keyword>mine</Keyword>
      <Keyword>Erml_lite_age_or_litho_queryable</Keyword>
      <Keyword>Erml_lite_queryable</Keyword>
      <Keyword>Erml_lite_queryable_geoserver</Keyword>
      <Keyword>Erml_lite_queryable_geoserver_workspace</Keyword>
      <Keyword>Erml_lite_queryable_4</Keyword>
  </KeywordList>

The edited content in this case was keywords, not CRS, but the principle is the same.

Now for the client you use the http://ogc.bgs.ac.uk/OWS/GTK.xml URL as the endpoint instead of the http://13.95.69.121:80/geoserver/erl/ows? version.

Answer 2

Geoserver will set the 'Native' CRS to what it determines the source data's coordinate system to be. You can set the 'Declared CRS' and the option ' Force Declared', which will force the layer to use the Declared CRS, but thats usually only if the source CRS is unable to be read by Geoserver. However in your instance, this should force it to use the declared (3857).

Some reading on this can be found here: https://docs.boundlessgeo.com/suite/1.1.0/geoserver/configuration/crshandling/configurecrs.html

In terms of isolating the layer itself in its own getCapabilities. hmm. Not sure if this is ideal, but, the documentation here: https://docs.geoserver.org/stable/en/user/services/wms/reference.html This states that a 'getCapabilities' is a

"The GetCapabilities operation requests metadata about the operations, services, and data (“capabilities”) that are offered by a WMS server."

Suggesting that, if you have this

http://localhost:8080/geoserver/wms?
service=wms&
version=1.1.1&
request=GetCapabilities

but you want

    http://localhost:8080/geoserver_new/wms?
service=wms&
version=1.1.1&
request=GetCapabilities

then you will need an entirely new instance of Geoserver. Sounds like overkill. My recommendation is that you simply add a new workspace as per the suggestion above, which can isolate the layer definition from your existing layer.

As an example, you currently have

http://localhost:8080/geoserver/wms?
request=GetMap
&service=WMS
&version=1.1.1
&layers=topp:states

Where topp is the workspace. But with a new workspace, you will have:

http://localhost:8080/geoserver/wms?
request=GetMap
&service=WMS
&version=1.1.1
&layers=new_workspace:states2

And then simply apply the coord system settings that you desire, to the new_workspace:states2 layer.