Given a WMS endpoint URL (and the ability to make calls to it), what is a reliable way to work out whether it is a GeoServer, ArcGIS Server, or something else? The reason we want to know is due to variable support for things like styles and legends, regardless of what the spec says.

For instance, does an ArcGIS Server WMS endpoint:

  • always have /MapServer/WMSServer in the URL?
  • always contain a <esri_wms:GetStyles> element in its GetCapabilities' Capabilities section?

Does a GeoServer WMS endpoint GetCapabilities:

  • always contain a <Keyword>GEOSERVER</Keyword> in its <KeywordList>
  • always contain <OnlineResource xlink:type="simple" xlink:href="http://geoserver.sourceforge.net/html/index.php"/>


To be clearer about why we want to do this, we run a catalogue that connects to many different servers of different types. Esri and GeoServer treat the width and height parameters to GetLegendGraphic differently (the former treats it as the width of the whole graphic, the latter as the width of each box). Similarly, if you want to change the background color of a legend in GeoServer, you pass ?LEGEND_OPTIONS=bgColor:0055ff while for Esri you pass bgColor:0055ff without the LEGEND_OPTIONS. GeoServer respects LEGEND_OPTIONS=fontColor:..., Esri doesn't (as far as I can tell). And finally, Esri returns a pretty useless response to request=getStyles.

So, all up, it's better if we can make this assessment automatically, before making any detailed requests.

  • Have you seen if vendor specific WMS request could be a help in tasting the response of server? - Just a thought, have not tried it. docs.geoserver.org/stable/en/user/services/wms/vendor.html – Jakob Feb 29 '16 at 8:04
  • The <Keyword>GEOSERVER</Keyword> is added by default, but I always remove it, I just use keywords appropriate to the service. – nmtoken Feb 29 '16 at 8:57
  • Similarly with always contain <OnlineResource xlink:type="simple" xlink:href="http://geoserver.sourceforge.net/html/index.php"/> this is the default, but I use it to point to further information about the service provider, so if you were using these to try and sniff out geoserver you would be unsuccessful. – nmtoken Feb 29 '16 at 9:04
  • 1
    If a server claims to implement the spec and doesn't then raise a bug against it. – Ian Turton Feb 29 '16 at 9:27
  • 1
    @iant - I have raised an issue with ArcGIS (NIM095568) over their WMS + SLD issue (submitted Oct 7, 2013). – nmtoken Feb 29 '16 at 9:48

The simple answer is no. There is no reliable way to determine what sort of server is behind an end point.

Issues about styles and legends can be found in the GetCapabilities response.

  • Whilst it shouldn't be necessary, and whilst the GetCapabilities response should provide information about style handling and legend support etc. You can I think get quite a good stab of which software is supplying a service, by looking at URL structure and keywords (people often use defaults), and looking at what is and isn't reported in the GetCapabilities by means of operations, and of course you can fire off requests that cause errors and look at the response. – nmtoken Feb 29 '16 at 9:24
  • @nmtoken - that's why I said no reliable way :-) the simple answer is to only make requests that are within the spec and only user servers that respond correctly according to the spec. – Ian Turton Feb 29 '16 at 9:26
  • though sometimes it's good to know what software is providing the service to get around know bugs and issues; for example ArcGIS doesn't follow the WMS+SLD spec, but if you know that you are dealing with ArcGIS then you know how to get around the bug and supply an external SLD. Similarly GeoServer doesn't advertise SLD support, yet we know that it does. – nmtoken Feb 29 '16 at 9:38
  • my GeoServer says <UserDefinedSymbolization SupportSLD="1" UserLayer="1" UserStyle="1" RemoteWFS="1"/> – Ian Turton Feb 29 '16 at 9:55
  • 1
    In version 1.1.1 it does but not in version 1.3.0, so I should have been more specific. – nmtoken Feb 29 '16 at 10:07

Agree with Ian that there is no fully reliable way.

That said, if you want a heuristic, I'd look for the supported GetMap output formats, there are some in there that other servers often do not support and GeoServer does not allow easy configuration of that list (it's possible, but requires building a customized version of it).

Like, application/openlayers is supported by GeoServer (and by recent versions of MapServer) but as far as I know, not by ESRI

  • Are you able to comment on my proposed specific tests, like the <esri_wms:GetStyles> or GEOSERVER elements? – Steve Bennett Feb 29 '16 at 22:45
  • Your tests will work only if GeoServer was not customized (as in, those fields were not edited in the configuration UI, I'm not talking about customizing at the programming level, which is possible, common enough, and can result in larger deviations) – Andrea Aime Mar 6 '16 at 16:11

What with ability of service providers to use proxies (changes the URL), and supply their own hand rolled GetCapabilities responses, not just change default settings, the chances of finding one or two tests that together can be used to reliably determine the service software is unlikely.

If you have any influence over the services (MoU with service providers) the best way would be to ask them to add a specific keyword, or for legacy (pre-registered services) just contacting the provider and asking them. One project I am involved in is considering this approach just to get around inconsistencies of style handling, (server software that we know is running MapServer, GeoServer, ArcIMS, ArcGIS, and services proxied through a hand rolled connector).

If we attempt to run some test suite at run time prior to constructing each styling request, the overhead of doing so would likely be an issue, but in this instance it appears that you can apply a set of programmatic tests when you harvest the Capabilities response into your catalogue, and then query the catalogue prior to constructing the styling request.

Whilst there might not be one or two tests that can determine all server software, you are likely to be able to find tests that can be used to determine whether a service is one bit of software or not.

For example GeoServer:

The following GeoServer service fails these two above tests:

Other tests for GeoServer, as already mention in the comments etc.

If a WMS 1.1.1 response gives you <UserDefinedSymbolization SupportSLD="1" UserLayer="1" UserStyle="1" RemoteWFS="1"/> but a WMS 1.3.0 response doesn't give you this then the service is likely to be GeoServer.

If a WMS 1.3.0 response gives you two CRS per layer of which one is CRS:84 like below then the software is likely to be GeoServer:


You can just experiment and find quirks in each software and work with these.

  • Thanks, that's very helpful. The MOU route etc is not useful - we can just as easily simply store a bit against them. And it's ultimately not that important - it just improves the display of legends a bit if we can supply a few advanced parameters. – Steve Bennett Mar 2 '16 at 12:11

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.