Thoughts on the ESRI Developer Summit and OGC in ArcGIS Server

Last week, some of us went south to Palm Springs to escape the rain and enjoy the company of the crew from Redlands at the ESRI Developer Summit. Much of the conference has been blogged about elsewhere, but I did want to share my observations of the talk on OGC capabilities in ArcGIS Server 9.3.

Satish Sankaran, Yinqi Tang and Gary MacDougal gave a very exciting discussion and demonstration of ESRI’s implementation of OGC Web Services. The quick and dirty is that at 9.3, ESRI has exposed considerable out-of-the-box support for all three of the main OGC specifications and demonstrated interoperability using non-ESRI clients and servers.

It might be worth starting with a little background. For a long time, if you wanted to use ESRI software to access server-based data you really had two choices: use ESRI clients (like ArcMap and ArcCatalog) to access data served from ArcGIS Server or use a web browser client to access the data as a read-only image from ArcIMS. I’m setting aside any discussion of the (client side) Interoperability Extension, which requires an additional license and which I’ve never seen.

If you had another application which could really benefit from content in ArcGIS Server, that was an integration task. More specifically that was your integration task. Similarly if you had an ArcMap-based geo-processing workflow that could benefit from integration with a non-ESRI content provider, well, that was your problem too.

The Open Geospatial Consortium (of which both ESRI and LizardTech are members) exists to publish freely available specifications that allow geospatial applications to talk to each other. The three most commonly used OGC specifications are:

  • Web Map Service (WMS) for serving custom maps into web pages. Typically these are small JPEG image “tiles” that make up your map.
  • Web Feature Service (WFS) for serving features (vector data like roads, borders, pizza shops) from your dataset into another geospatial application that can interact with them at much more controlled level than a read-only map. Think of WFS is as serving GML over HTTP. An OGC extension for this is WFS-T (T for “transactions”) which allows remote editing of data.
  • Web Coverage Service (WCS). Like WMS, this provides a means of accessing raster data. However, here the service is optimized for sending to another geospatial application, rather than a simple web service.

At 9.3, there is significant support for all of these.


ArcGIS Server’s WMS support is extended to the current version 1.3 including support for Styled Layer Descriptor (SLD). SLDs are part of the WMS specification and allow customized symbology for features. The demonstration here included an OpenLayers web page client rendering a map (with user-selected symbology) served from ArcGIS Server via WMS. That was pretty good, but really, only a marginal improvement.


The previous 9.2 Data Interoperability extension will continue to provide WFS support to the Desktop Clients. However, at 9.3, “Simple Features” support comes out of the box (without the extra license). On the server side, 9.3 includes a WFS server and if your back-end store is SDE then this includes WFS-T support. What that means is that if you use SDE, non-ESRI clients (who speak WFS) can edit your geodatabase. Stop for a minute and think about that.

The demonstration here showed again the Open Layers client. This time it accessed the parcel data stored in ArcGIS Server via WFS. It corrected some of the parcel boundaries and this was reflected in the same GDB accessed via ArcMap. Frankly, I was pretty impressed.


WCS support is totally new in 9.3. The demonstration of server support showed the Open Layers client rendering a 4-banded Modis image served from ArcGIS Server via WCS. More interesting to me was the client demo where ArcMap read a dataset via WCS from ICDES and did some sort of raster-based geo-processing on it (I can’t remember exactly what it was). Very, very cool.

Whether or not you believe “What’s good for the country is good for General Motors, and vice versa,” ESRI’s support for this sort of interoperability can only be seen as good news for GIS and for ESRI.

Leave a Reply

Your email address will not be published. Required fields are marked *