In this article by Stefano Iacovella, author of GeoServer Cookbook, we look into a brief comparison between GeoServer and ArcGIS for Server, a map server created by ESRI. The importance of adopting OGC standards when building a geographical information system is stressed. We will also learn how OGC standards let us create a system where different pieces of software cooperate with each other.

(For more resources related to this topic, see here.)

ArcGIS versus GeoServer

As an ESRI professional, you obviously know the server product from this vendor that can be compared to GeoServer well. It is called ArcGIS for Server and in many ways it can play the same role as that of GeoServer, and the opposite is true as well, of course.

Undoubtedly, the big question for you is: why should I use GeoServer and not stand safely on the vendor side, leveraging on integration with the other software members of the big ArcGIS family?

Listening to colleagues, asking to experts, and browsing on the Internet, you'll find a lot of different answers to this question, often supported by strong arguments and somehow by a religious and fanatic approach.

There are a few benchmarks available on the Internet that compare performances of GeoServer and other open source map servers versus ArcGIS for Server. Although they're not definitely authoritative, a reasonably objective advantage of GeoServer and its OS cousins on ArcGIS for Server is recognizable.

Anyway, I don't think that your choice should overestimate the importance of its performance. I'm sorry but my answer to your original question is another question: why should you choose a particular piece of software?

This may sound puzzling, so let me elaborate a bit on the topic. Let's say you are an IT architect and a customer asked you to design a solution for a GIS portal. Of course, in that specific case, you have to give him or her a detailed response, containing specific software that'll be used for data publication. Also, as a professional, you'll arrive to the solution by accurately considering all requirements and constraints that can be inferred from the talks and surveying what is already up and running at the customer site.

Then, a specific answer to what the software best suited for the task is should exist in any specific case. However, if you consider the question from a more general point of view, you should be aware that a map server, which is the best choice for any specific case, does not exist.

You may find that the licensing costs a limit in some case or the performances in some other cases will lead you to a different choice. Also, as in any other job, the best tool is often the one you know better, and this is quite true when you are in a hurry and your customer can't wait to have the site up and running.

So the right approach, although a little bit generic, is to keep your mind open and try to pick the right tool for any scenario.

However, a general answer does exist. It's not about the vendor or the name of the piece of software you're going to use; it's about the way the components or your system communicate among them and with external systems. It's about standard protocol.

This is a crucial consideration for any GIS architect or developer; nevertheless, if you're going to use an ESRI suite of products or open source tools, you should create your system with special care to expose data with open standards.

Understanding standards

Let's take a closer look at what standards are and why they're so important when you are designing your GIS solution.

The term standard as mentioned in Wikipedia (http://en.wikipedia.org/wiki/ Technical_standard) may be explained as follows:

"An established norm or requirement in regard to technical systems. It is usually a formal document that establishes uniform engineering or technical criteria, methods, processes and practices. In contrast, a custom, convention, company product, corporate standard, etc. that becomes generally accepted and dominant is often called a de facto standard."

Obviously, a lot of standards exist if you consider the Information Technology domain. Standards are usually formalized by standards organization, which usually involves several members from different areas, such as government agencies, private companies, education, and so on.

In the GIS world, an authoritative organization is the Open Geospatial Consortium (OGC), which you may find often cited in this book in many links to the reference information.

In recent years, OGC has been publishing several standards that cover the interaction of the GIS system and details on how data is transferred from one software to another. We'll focus on three of them that are widely used and particularly important for GeoServer and ArcGIS for Server:

WMS: This is the acronym for Web Mapping Service. This standard describes how a server should publish data for mapping purposes, which is a static representation of data.
WFS: This is the acronym for Web Feature Service. This standard describes the details of publishing data for feature streaming to a client.
WCS: This is the acronym for Web Coverage Service. This standard describes the details of publishing data for raster data streaming to a client. It's the equivalent of WFS applied to raster data.

Now let's dive into these three standards. We'll explore the similarities and differences among GeoServer and ArcGIS for Server.

WMS versus the mapping service

As an ESRI user, you surely know how to publish some data in a map service. This lets you create a web service that can be used by a client who wants to show the map and data. This is the proprietary equivalent of exposing data through a WMS service.

With WMS, you can inquire the server for its capabilities with an HTTP request:

$ curl -XGET -H 'Accept: text/xml' 
 'http://localhost:8080/geoserver/wms?service=WMS
 &version=1.1.1&request=GetCapabilities' -o capabilitiesWMS.xml

Browsing through the XML document, you'll know which data is published and how this can be represented.

If you're using the proprietary way of exposing map services with ESRI, you can perform a similar query that starts from the root:

$ curl -XGET 'http://localhost/arcgis/rest/services?f=pjson' -o 
 capabilitiesArcGIS.json

The output, in this case formatted as a JSON file, is a text file containing the first of the services and folders available to an anonymous user. It looks like the following code snippet:

{
"currentVersion": 10.22,
"folders": [
"Geology",
"Cultural data",
…
"Hydrography"
],
"services": [
{
"name": "SampleWorldCities",
"type": "MapServer"
}
]
}

At a glance, you can recognize two big differences here. Firstly, there are logical items, which are the folders that work only as a container for services. Secondly, there is no complete definition of items, just a list of elements contained at a certain level of a publishing tree.

To obtain specific information about an element, you can perform another request pointing to the item:

$ curl -XGET 'http://localhost/arcgis/rest/
 services/SampleWorldCities/MapServer?f=pjson' -o 
 SampleWorldCities.json

Setting up an ArcGIS site is out of the scope of this book; besides, this appendix assumes that you are familiar with the software and its terminology. Anyway, all the examples use the SampleWorldCities service, which is a default service created by the standard installation.

In the new JSON file, you'll find a lot of information about the specific service:

{
"currentVersion": 10.22,
"serviceDescription": "A sample service just for demonstation.",
"mapName": "World Cities Population",
"description": "",
"copyrightText": "",
"supportsDynamicLayers": false,
"layers": [
{
"id": 0,
"name": "Cities",
"parentLayerId": -1,
"defaultVisibility": true,
"subLayerIds": null,
"minScale": 0,
"maxScale": 0
},
…
"supportedImageFormatTypes":
"PNG32,PNG24,PNG,JPG,DIB,TIFF,EMF,PS,PDF,GIF,SVG,SVGZ,BMP",
…
"capabilities": "Map,Query,Data",
"supportedQueryFormats": "JSON, AMF",
"exportTilesAllowed": false,
"maxRecordCount": 1000,
"maxImageHeight": 4096,
"maxImageWidth": 4096,
"supportedExtensions": "KmlServer"
}

Please note the information about the image format supported. We're, in fact, dealing with a map service. As for the operation supported, this one shows three different operations: Map, Query, and Data. For the first two, you can probably recognize the equivalent of the GetMap and GetFeatureinfo operations of WMS, while the third one is little bit more mysterious. In fact, it is not relevant to map services and we'll explore it in the next paragraph.

If you're familiar with the GeoServer REST interface, you can see the similarities in the way you can retrieve information.

We don't want to explore the ArcGIS for Server interface in detail and how to handle it. What is important to understand is the huge difference with the standard WMS capabilities document.

If you're going to create a client to interact with maps produced by a mix of ArcGIS for Server and GeoServer, you should create different interfaces for both. In one case, you can interact with the proprietary REST interface and use the standard WMS for GeoServer.

However, there is good news for you. ESRI also supports standards. If you go to the map service parameters page, you can change the way the data is published.

ogc-esri-professionals-img-0

The situation shown in the previous screenshot is the default capabilities configuration. As you can see, there are options for WMS, WFS, and WCS, so you can expose your data with ArcGIS for Server according to the OGC standards.

If you enable the WMS option, you can now perform this query:

$ curl -XGET 'http://localhost/arcgis/
 services/SampleWorldCities/MapServer/
 WMSServer?SERVICE=WMS&VERSION=1.3.0&REQUEST=GetCapabilities'
    -o capabilitiesArcGISWMS.xml

The information contained is very similar to that of the GeoServer capabilities. A point of attention is about fundamental differences in data publishing with the two software. In ArcGIS for Server, you always start from a map project. A map project is a collection of datasets, containing vector or raster data, with a drawing order, a coordinate reference system, and rules to draw.

It is, in fact, very similar to a map project you can prepare with a GIS desktop application. Actually, in the ESRI world, you should use ArcGIS for desktop to prepare the map project and then publish it on the server.

In GeoServer, the map concept doesn't exist. You publish data, setting several parameters, and the map composition is totally demanded to the client. You can only mimic a map, server side, using the group layer for a logical merge of several layers in a single entity.

In ArcGIS for Server, the map is central to the publication process; also, if you just want to publish a single dataset, you have to create a map project, containing just that dataset, and publish it.

Always remember this different approach; when using WMS, you can use the same operation on both servers. A GetMap request on the previous map service will look like this:

$ curl -XGET 'http://localhost/arcgis/services/
 SampleWorldCities/MapServer/WMSServer?service=
 WMS&version=1.1.0&request=GetMap&layers=fields&styles
 =&bbox=47.130647,8.931116,48.604188,29.54223&srs=
 EPSG:4326&height=445&width=1073&format=img/png' -o map.png

Please note that you can filter what layers will be drawn in the map. By default, all the layers contained in the map service definition will be drawn.

WFS versus feature access

If you open the capabilities panel for the ArcGIS service again, you will note that there is an option called feature access. This lets you enable the feature streaming to a client.

With this option enabled, your clients can acquire features and symbology information to ArcGIS and render them directly on the client side. In fact, feature access can also be used to edit features, that is, you can modify the features on the client and then post the changes on the server.

When you check the Feature Access option, many specific settings appear. In particular, you'll note that by default, the Update operation is enabled, but the Geometry Updates is disabled, so you can't edit the shape of each feature.

ogc-esri-professionals-img-1

If you want to stream features using a standard approach, you should instead turn on the WFS option. ArcGIS for Server supports versions 1.1 and 1.0 of WFS. Moreover, the transactional option, also known as WFS-T, is fully supported.

ogc-esri-professionals-img-2

As you can see in the previous screenshot, when you check the WFS option, several more options appear. In the lower part of the panel, you'll find the option to enable the transaction, which is the editing feature. In this case, there is no separate option for geometry and attributes; you can only decide to enable editing on any part of your features.

After you enable the WFS, you can access the capabilities from this address:

$ curl -XGET 'http://localhost/arcgis/services/
 SampleWorldCities/MapServer/WFSServer?SERVICE=WFS&VERSION=1.1.
 0&REQUEST=GetCapabilities' -o capabilitiesArcGISWFS.xml

Also, a request for features is shown as follows:

$ curl -XGET "http://localhost/arcgis/services/SampleWorldCities
 /MapServer/WFSServer?service=wfs&version=1.1.0
 &request=GetFeature&TypeName=SampleWorldCities:
 cities&maxFeatures=1" -o getFeatureArcGIS.xml

This will output a GML code as a result of your request. As with WMS, the syntax is the same. You only need to pay attention to the difference between the service and the contained layers:

<wfs:FeatureCollection xsi:schemaLocation
="http://localhost/arcgis/services/SampleWorldCities/
MapServer/WFSServer http://localhost/arcgis/services/
SampleWorldCities/MapServer/WFSServer?request
=DescribeFeatureType%26version=1.1.0%26typename=cities
http://www.opengis.net/wfs http://schemas.opengis.net
/wfs/1.1.0/wfs.xsd">
<gml:boundedBy>
<gml:Envelope srsName="urn:ogc:def:crs:EPSG:6.9:4326">
<gml:lowerCorner>-54.7919921875 -
176.1514892578125</gml:lowerCorner>
<gml:upperCorner>78.2000732421875
179.221923828125</gml:upperCorner>
</gml:Envelope>
</gml:boundedBy>
<gml:featureMember>
<SampleWorldCities:cities gml_id="F4__1">
<SampleWorldCities:OBJECTID>1</SampleWorldCities:OBJECTID>
<SampleWorldCities:Shape>
<gml:Point>
<gml:pos>-15.614990234375 -
56.093017578125</gml:pos>
</gml:Point>
</SampleWorldCities:Shape>
<SampleWorldCities:CITY_NAME>Cuiaba</
SampleWorldCities:CITY_NAME>
<SampleWorldCities:POP>521934</SampleWorldCities:POP>
<SampleWorldCities:POP_RANK>3</SampleWorldCities:POP_RANK>
<SampleWorldCities:POP_CLASS>500,000 to
999,999</SampleWorldCities:POP_CLASS>
<SampleWorldCities:LABEL_FLAG>0</SampleWorldCities:LABEL_
FLAG>
</SampleWorldCities:cities>
</gml:featureMember>
</wfs:FeatureCollection>

Publishing raster data with WCS

The WCS option is always present in the panel to configure services. As we already noted, WCS is used to publish raster data, so this may sound odd to you. Indeed, ArcGIS for Server lets you enable the WCS option, only if the map project for the service contains one of the following:

A map containing raster or mosaic layers
A raster or mosaic dataset
A layer file referencing a raster or mosaic dataset
A geodatabase that contains raster data

If you try to enable the WCS option on SampleWorldCities, you won't get an error. Then, try to ask for the capabilities:

$ curl -XGET "http://localhost/arcgis/services
 /SampleWorldCities/MapServer/
 WCSServer?SERVICE=WCS&VERSION=1.1.1&REQUEST=GetCapabilities" -o 
 capabilitiesArcGISWCS.xml

You'll get a proper document, compliant to the standard and well formatted, but containing no reference to any dataset. Indeed, the sample service does not contain any raster data:

 <Capabilities xsi_schemaLocation="http://www.opengis.net/wcs/1.1.1
http://schemas.opengis.net/wcs/1.1/wcsGetCapabilities.xsd
http://www.opengis.net/ows/1.1/
http://schemas.opengis.net/ows/1.1.0/owsAll.xsd"
version="1.1.1">
<ows:ServiceIdentification>
<ows:Title>WCS</ows:Title>
<ows:ServiceType>WCS</ows:ServiceType>
<ows:ServiceTypeVersion>1.0.0</ows:ServiceTypeVersion>
<ows:ServiceTypeVersion>1.1.0</ows:ServiceTypeVersion>
<ows:ServiceTypeVersion>1.1.1</ows:ServiceTypeVersion>
<ows:ServiceTypeVersion>1.1.2</ows:ServiceTypeVersion>
<ows:Fees>NONE</ows:Fees>
<ows:AccessConstraints>None</ows:AccessConstraints>
</ows:ServiceIdentification>
...
<Contents>
<SupportedCRS>urn:ogc:def:crs:EPSG::4326</SupportedCRS>
<SupportedFormat>image/GeoTIFF</SupportedFormat>
<SupportedFormat>image/NITF</SupportedFormat>
<SupportedFormat>image/JPEG</SupportedFormat>
<SupportedFormat>image/PNG</SupportedFormat>
<SupportedFormat>image/JPEG2000</SupportedFormat>
<SupportedFormat>image/HDF</SupportedFormat>
</Contents>
</Capabilities>

If you want to try out WCS, other than the GetCapabilities operation, you need to publish a service with raster data; or, you may take a look at the sample service from ESRI arcgisonline™.

Try the following request:

$ curl -XGET "http://sampleserver3.arcgisonline.com/
 ArcGIS/services/World/Temperature/ImageServer/
 WCSServer?SERVICE=WCS&VERSION=1.1.0&REQUEST=GETCAPABILITIES" -o 
 capabilitiesArcGISWCS.xml

Parsing the XML file, you'll find that the contents section now contains coverage, raster data that you can retrieve from that server:

 …
<Contents>
<CoverageSummary>
<ows:Title>Temperature1950To2100_1</ows:Title>
<ows:Abstract>Temperature1950To2100</ows:Abstract>
<ows:WGS84BoundingBox>
<ows:LowerCorner>-179.99999999999994 -55.5</ows:LowerCorner>
<ows:UpperCorner>180.00000000000006 83.5</ows:UpperCorner>
</ows:WGS84BoundingBox>
<Identifier>1</Identifier>
</CoverageSummary>
<SupportedCRS>urn:ogc:def:crs:EPSG::4326</SupportedCRS>
<SupportedFormat>image/GeoTIFF</SupportedFormat>
<SupportedFormat>image/NITF</SupportedFormat>
<SupportedFormat>image/JPEG</SupportedFormat>
<SupportedFormat>image/PNG</SupportedFormat>
<SupportedFormat>image/JPEG2000</SupportedFormat>
<SupportedFormat>image/HDF</SupportedFormat>
</Contents>

You can, of course, use all the operations supported by standard. The following request will return a full description of one or more coverages within the service in the GML format.

An example of the URL is shown as follows:

$ curl -XGET "http://sampleserver3.arcgisonline.com/
 ArcGIS/services/World/Temperature/ImageServer/
 WCSServer?SERVICE=WCS&VERSION=1.1.0&REQUEST=DescribeCoverage&
 COVERAGE=1" -o describeCoverageArcGISWCS.xml

Also, you can obviously request for data, and use requests that will return coverage in one of the supported formats, namely GeoTIFF, NITF, HDF, JPEG, JPEG2000, and PNG.

Another URL example is shown as follows:

$ curl -XGET "http://sampleserver3.arcgisonline.com/
 ArcGIS/services/World/Temperature/ImageServer/
 WCSServer?SERVICE=WCS&VERSION=1.0.0
 &REQUEST=GetCoverage&COVERAGE=1&CRS=EPSG:4326
 &RESPONSE_CRS=EPSG:4326&BBOX=-158.203125,-
 105.46875,158.203125,105.46875&WIDTH=500&HEIGHT=500&FORMAT=jpeg" -o 
 coverage.jpeg

Summary

In this article, we started with the differences between ArcGIS and GeoServer and then moved on to understanding standards. Then we went on to compare WMS with mapping service as well as WFS with feature access. Finally we successfully published a raster dataset with WCS.