1

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?

  • Create a new workspace and include only that one layer and then configure limited SRID list. But GetCapabilities is just xml, you can edit the file and put it available through https anywhere as a static document. – user30184 Sep 7 at 5:40
  • @user30184 Unfortunately, it's still putting CRS:84 in the capabilities document by default I think. I've gone into the WMS page and limited it to 3857. Also, this is legacy stuff and the people who used to administer this have left and not really documented it, so I don't think we have that much info behind the machine running it. – user25730 Sep 7 at 6:14
  • 1
    WMS 1.3.0 standard recommends that every WMS service would support CRS:84. GeoServer has probably taken that recommendation as a requirement. Hand written GetCapabilities is probably the easiest solution for you. Block also access to GetCapabilities request of GeoServer so that your users will not see the automatically generated document. – user30184 Sep 7 at 7:51
  • You can limit the SRS for the WMS or a workspace using the WMS settings page – Ian Turton Sep 7 at 8:40
  • 1
    @IanTurton Sadly, that's still putting CRS:84 into the capabilities doc as a default. – user25730 Sep 7 at 12:40
0

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/2.13.2/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.

| improve this answer | |
0

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.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.