Skip To Content

Tutorial: Publishing a WFS-T service

Complexity: BeginnerData Requirement: Use your own dataGoal: Publish a WFS-T service to ArcGIS Server and consume it in a web browser.

This tutorial shows how to publish a Web Feature Service (WFS) with transactions (WFS-T) to ArcGIS Server using ArcMap. WFS is a specification published by the Open Geospatial Consortium, Inc. (OGC) for serving geographic features on the Internet. A WFS service with transactions (WFS-T) allows WFS clients to apply edits (inserts, deletes, and updates) to the data in the source database through the WFS service.

When a map service or geodata service is published with WFS capabilities, the data can be accessed by OGC-compliant WFS clients, including the ArcGIS Data Interoperability extension for Desktop in ArcGIS Desktop. These WFS clients can also see the latest changes made to the data. If you're new to WFS services and want to learn more about them before attempting this tutorial, see WFS services.

WFS services support simple features from Esri sources, such as shapefiles and geodatabases. However, if you're going to enable transactions on the service (WFS-T), all data that you want to edit must be stored in a workgroup or enterprise geodatabase. This tutorial demonstrates the workflow to be used when working specifically with versioned data.

Before beginning this tutorial

If you've just installed ArcGIS Server, you need to complete some preparatory steps before you can connect to the server and publish services:


This tutorial uses examples for WFS 1.1.0, however these steps are also applicable for WFS 2.0.0. WFS 1.0.0 does not support transactions.

Deciding between a geodata service or a map service

With WFS services, you have the option of publishing a geodata service or a map service. There are a few differences to be aware of when selecting the type of service you're going to create. The following sections summarize the functionality available with map and geodata services to help you identify which type of service best suits your requirements.

Geodata service

A WFS geodata service allows you to access a workgroup, enterprise, or file geodatabase through the Internet or any OGC-compliant WFS client. When creating a WFS service from a geodata service, it's important to keep in mind that all the feature classes in the geodatabase will be exposed in the service.

Geodata services are useful in situations where you need to access geodatabases in remote locations. For example, a company may want to set up enterprise geodatabases to manage data in its Los Angeles and New York offices. Once created, each office can publish its enterprise geodatabase on the Internet using a geodata service.

Map service

A WFS map service represents a map document that you've made available to others through the Internet or any OGC-compliant WFS client. Map services with WFS functionality give you a lot of control over the data that's published through the service. The following are common reasons why you might set up a map service:

  • Unlike a geodata service, a single map service can include data from a variety of sources including data from multiple geodatabases as well as shapefiles.
  • You can select which feature classes are exposed through a map service.
  • You can rename the feature classes in the map document so that the service does not expose the actual names in the data source.

There are also some limitations associated with WFS map services. Consider the following when publishing a WFS service from a map document:

  • The map document is a specification of the layers that will be available in your WFS service. Symbology, query definitions, and field aliases defined at the layer level will not transfer to the WFS service, because the purpose of the service is to expose the features in the data. To expose the visual properties of your map through OGC specifications, use a WMS service.
  • Two or more layers in the map cannot reference the same feature class.
  • Two or more layers in the map cannot have the same name.
  • Since WFS only works with features, any raster layers in the map will be excluded from the service.
  • Nonspatial tables are not exposed.
  • If you want the WFS service to support transactions for editing (WFS-T), the source data for all the layers in the map must come from the same workspace, for example, the same enterprise geodatabase.

Preparing data for a WFS-T service

Before creating a WFS service with read and write access, there are some initial requirements to set up your data:

  • It must be loaded into a workgroup or enterprise geodatabase.
  • If you want to work with versioned data, it must be registered as versioned.
  • A version must be dedicated specifically for WFS editors to work with. If one does not already exist, it must be created.
  • Specific WFS editors must be granted permissions on the database connection (.sde) file to edit.

Follow these steps to prepare your data for a WFS-T service with versioned data:

  1. In ArcCatalog or the Catalog window in ArcGIS Desktop, load the data you want to publish into a workgroup or enterprise geodatabase. For more information on loading data, see Loading Data in ArcCatalog.
  2. Register the data as versioned by right-clicking the dataset and choosing Register data as versioned from the context menu. For more information, see Registering data as versioned.
  3. Now that the data is versioned, you must dedicate a version specifically for WFS users to edit. If no such version exists, right-click your database connection and choose Administration > Administer Geodatabase.
  4. In the connection window, click the Versions tab.
  5. Right-click the version of your geodatabase you want to create a child version of and click New.
  6. Type a Name for the new version. If users other than the creator will be editing the data, the Permission option must be set to Public.

If you're creating a map service, continue to the map services section below. If you're creating a geodata service, continue to the geodata services section below.

For map services

To ensure that the map service publishes the appropriate data when it's created, your map document must be updated so that it references the newly created WFS version.

  1. Open your map document in ArcMap.
  2. In the ArcMap table of contents, click List By Source List By Source.
  3. Right-click the geodatabase connection and select Change Version.
  4. In the Change Version dialog box, select the version dedicated to WFS users and click OK.
  5. Save changes to the map document.

For geodata services

To ensure that the geodata service publishes the appropriate data when it's created, the connection properties of the geodatabase must be updated so that they reference the new WFS version that has been created.

  1. In ArcCatalog or the Catalog window in ArcGIS Desktop, right-click the geodatabase connection, and choose Administration > Administer Geodatabase.
  2. In the Administration dialog box, click Versions.
  3. Select the version dedicated to WFS users and click OK.

Publishing a WFS-T service to ArcGIS Server

To get started publishing a WFS-T service, follow these steps:

  1. Follow the directions in the following table based on the service type you want to publish:


    To publish a WFS-T map service... your map document in ArcMap, choose File > Share As > Service, and click Next.

    To publish a WFS-T geodata service...

    ...browse to the workgroup, enterprise, or file geodatabase in ArcCatalog or the Catalog window, right-click it, and choose Share as geodata service.

  2. In the Share as Service window, choose Publish a service, and click Next.

    The Publish a Servicedialog box appears.

  3. In the Publish a Service dialog box, click Connect to ArcGIS Server Add ArcGIS Server to create a new connection to the server.

    The Add ArcGIS Server window appears.

  4. In the Add ArcGIS Server window, choose Publish GIS Services, and click Next.
  5. For the Server URL, type the URL of the ArcGIS Server site you want to connect to. For example,
  6. From the Server Type drop-down list, choose ArcGIS Server.
  7. During the publishing process, a service definition file is created and temporarily stored locally on disk. When the publishing process completes, the service definition is uploaded to the server and the local file is deleted. For the purposes of this tutorial, accept the default staging folder and continue.
  8. If your server administrator has enabled security for your site, enter your User Name and Password, and click Finish.
  9. Optionally, in the Publish a Service window, type a new name for the service. The name cannot be more than 120 characters long and can contain only alphanumeric characters and underscores. Click Next.
  10. By default, services are published to the root folder (root) of ArcGIS Server. Services can be organized into subfolders under the root folder. Choose the folder where you want to publish the service, or create a new folder to contain the service. Click Continue.
  11. The Service Editor displays. You'll use the Service Editor to choose what users can do with your WFS-T service and take fine-grained control of how the server will expose your service. Click the Capabilities tab.
  12. By default, mapping and KML are enabled. Select WFS.
  13. In the left pane of the Service Editor, click WFS. Use this panel to choose how to configure the properties of your WFS service. By providing WFS service properties, clients can gain a better understanding of the service publisher.
    • The URL field displays the URL clients use to access the WFS service. The URL will be formatted as follows:

      Copy and save the WFS service URL. You'll need it to perform additional steps in this tutorial.

    • If you want to publish a WFS service with system-generated capabilities files, use the default Enter service properties below option. The Name, Title, and OnlineResource fields are automatically populated and should not be modified. Optionally, you can populate additional properties using the fields in the list. For more information, see Available WFS service properties.
    • If you want to configure a WFS service to use external capabilities files, select Use external capabilities files. To use this option, you must have already created a WFS capabilities file. For more information, see Using external capabilities files with WFS services.
  14. At the bottom of the WFS pane, click the Enable Transactions check box. This will allow WFS users to edit and apply changes to the data in the source database.
  15. Click Analyze Analyze. This examines your map document or geodatabase to see if it can be published to the server.

    To give yourself more viewing area when configuring your WFS-T service, click the Collapse Collapse button at the top of the Service Editor.

  16. Fix any Errors Error in the Prepare window; this must be done before you can publish. Optionally, you can fix the warnings and informational messages to further improve the performance and appearance of your WFS-T service. For more information about resolving these issues, see Analyzing your GIS resource.

    You can register folders and geodatabases with your ArcGIS Server site, ensuring that the server can recognize and use your data. If you proceed with the following steps, any data referenced by your GIS resource originating from an unregistered folder or geodatabase will be copied to the server when you publish. This is a precautionary measure to ensure that the server can access all the data used by the service. For full instructions on registering a folder or geodatabase with your ArcGIS Server site, see Registering your data with ArcGIS Server using ArcGIS Desktop.

  17. Optionally, in the Service Editor, click Preview Preview. This can give you an idea of how your WFS-T service will look when viewed on the web. See Previewing your map for more information.
  18. Once you've fixed the errors in your map document or geodatabase, click Publish Publish.

Consuming the WFS service

Once you've published a WFS service, it can be used in any client that supports WFS 1.1.0 and the Simple Features profile of GML, including web browsers. A web browser is one of the simplest clients of a WFS service. You can request information through HTTP, and the responses or exceptions are returned through the browser.

Follow these steps to access WFS services through a web browser:

  1. Open a web browser.
  2. Perform the GetCapabilities, DescribeFeatureType, and GetFeature requests as indicated in the following sections.


This request will return all feature types and functionality available through the service in GML format. To use the GetCapabilities operation, copy and paste the WFS service URL into the address bar and add ?request=getcapabilities to the end of the URL.

URL example:

The following graphic is an example of functionality returned by the GetCapabilities operation:

Functionality returned by the GetCapabilities operation

GetCapabilities also returns a list of all available feature classes and tables:

Available feature classes and tables returned by the GetCapabilities operation


This request describes the field information about one or more features in the WFS service. This includes the field names, field types, allowed minimum and maximum field values, and any other constraints set on a field of the feature classes or tables.

To use the DescribeFeatureType operation, copy and paste the WFS URL into the address bar and add ?SERVICE=WFS&REQUEST=DescribeFeatureType&VERSION=1.1.0 to the end of the URL. This will return all the field information about each of the feature types and tables available in the feature service.

URL Example:

Feature classes, tables, and field information returned by the DescribeFeatureType operation

Adding filters

You can also specify a single feature class or table for which you want the field information by appending the following request to the end of the URL with the name of the feature type or table: ?SERVICE=WFS&REQUEST=DescribeFeatureType&TypeName=<enter feature type here>&VERSION=1.1.0.

For more information about the different filters available with WFS services, see Communicating with a WFS service in a web browser.

In the following example, the DescribeFeatureType request is used to identify the field information for the feature type called continent:

URL example:

Continent feature class and its field information returned by the filtered DescribeFeatureType operation


This request returns information about specific feature types available through the WFS service.

To use the GetFeature operation in a web browser, copy and paste the WFS URL into the address bar and add ?request=getFeature&typename=<enter feature type here> to the end of the URL. This will return all the attribute and geometry information about each feature or row in the feature type.

URL example:

Attribute and geometry information for the cities feature class returned by the GetFeature operation

Adding filters

You can also add filters in the request to refine the results that are returned. For example, you can request all the cities that are within a specified coordinate range. In the following example, two cities are located within a specified coordinate range. For more information about the different filters available with WFS services, see the topic Communicating with a WFS service in a web browser.

URL example:,-76.21,42.12,-72.88

Cities within the specified coordinate range returned by the filtered GetFeature operation

Using the Data Interoperability extension to connect to a WFS service

The ArcGIS Data Interoperability extension extension allows you to read and write data in data formats other than ArcGIS. You can use the Interoperability Connection tool in ArcCatalog or the Catalog window in ArcGIS Desktop to connect directly to external Esri data formats, including WFS services. Once the connection is made, the data source will appear under the Interoperability Connection entry in the Catalog tree. A connection is just like any other dataset in that you can add it to the table of contents or use it in geoprocessing tools.

Managing edits made through a WFS-T service with versioned data

It's important to create an efficient workflow for managing edits made through a WFS-T service. Assuming you have followed the recommended method of creating a separate WFS version for WFS-T editors to work with, the system that you have set up should look similar to the following diagram:

Common WFS-T editing system
Web editing with a WFS-T service using versioned data.

In this example, WFS-T editors and ArcMap editors use versions so that each group can have their own isolated view of the geodatabase to work with. ArcMap editors are directly editing the default version through ArcMap. WFS-T editors are accessing the WFS service over the Internet. This allows WFS-T editors to make edits on the WFS version that was created as a child of the default. To learn more about versions, see A quick tour of versioning in the desktop help system.

To keep the two versions in sync, a process can be run regularly to update the WFS version with edits from the default version and to update the default version with the edits from the WFS version. This is a two-step process in the editing workflow of any versioned system called reconcile and post. This process can be automated, or it can be administered by an editor (depending on his or her permissions) or database administrator. To learn more about the reconcile and post process, see A quick tour of the version editing process.

When run, the reconcile operation will pull updates from the default version into the current editing session on the WFS version. Conflicts may occur if edits have been made to the same features in both versions. You can either set up conflict resolution to be automatic or choose to resolve each conflict manually through the conflict resolution dialog box.

After handling any conflicts, the post operation can be run. This process merges changes from the WFS version into the default version.

The whole reconcile and post process is summarized in the following diagram. Here, the WFS version pulls updates from the default version during reconcile. After incorporating the changes, the WFS version posts its updates to the default version using the post operation. At this point, the default and WFS versions both have the same content.

Reconcile and post process
The reconcile and post process between the default and WFS versions.

Once the reconcile and post process is complete, both versions are up-to-date with the most current representation of the features, and WFS editors can continue making edits again.

It's important to note that if there are outstanding locks when reconcile and post is run, the system will not allow the process to succeed. This is a safeguard to prevent conflicts between features locked by WFS-T clients and features changed through the reconcile and post process. Also, running reconcile and post will lock the WFS-T version to prevent any lock and transaction calls from being made by WFS-T editors during the reconcile and post process.

To accommodate this safeguard, it's recommended that the reconcile and post process be run at well-established times that all WFS-T editors have prior knowledge of. This will allow the editors to get their changes posted to the database. Administrators may also need to manually remove locks from the locks table before the reconcile and post.

To learn more about the WFS-T locking scheme, see WFS services.