Desktop Help 10.0 - WFS services

With ArcGIS Server, you can publish services that comply with the Open Geospatial Consortium, Inc. (OGC), Web Feature Service (WFS) specification. This is an open specification for serving geographic features over the Web.

To publish your data using WFS with ArcGIS Server, you must have an appropriate ArcGIS Server license. Refer to the functionality matrix for licensing requirements.

This topic is organized into the following sections:

Why use a WFS service?

Serving your data through a WFS service allows any application that can work with Web services to access geographic features from your map or geodatabase. Unlike the OGC Web Map Service (WMS) that returns an image of a map, the WFS service returns actual features with geometry and attributes that clients can use in any type of geospatial analysis. WFS services also support filters that allow users to perform spatial and attribute queries on the data.

Technical notes

The WFS services you create with ArcGIS Server are compliant with the WFS 1.1 specification. They also support the WFS 1.0 specification on a read-only basis.
WFS services use Geography Markup Language (GML) to encode the feature data. GML is just a way of using XML to represent geographic information. The GML used by ArcGIS Server WFS services uses the Simple Features profile. To learn more about GML, see An overview of GML support in ArcGIS in the ArcGIS Desktop Help.

How to create a WFS service

There are two ways you can create a WFS service: from a map or from a geodatabase.

Creating a WFS service from a map

You can create a WFS service by starting with an ArcMap map document (.mxd). Publish the map document as an ArcGIS Server map service using either Manager or ArcCatalog. When prompted for the capabilities you want to enable, check WFS. This creates a URL that any WFS client can use to access the service.

If you need help publishing the service, see Publishing a GIS resource to the server.

The map document is just 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. Remember the following things when publishing a WFS service from a map document:

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 ArcSDE geodatabase. Otherwise, the map can contain layers from multiple sources.
Two or more layers in the map cannot reference the same feature class or have the same name. If they do, you may receive the error Workspace item or name is a duplicate.
The name of the layer will be the type name returned from WFS.
To publish data through a WFS service, the data must be registered with the geodatabase, including SDE views.
Since WFS only works with features, any raster layers in the map will be excluded from the service.
WFS services do not support virtual classes such as joins, relates, XY events, routes, or coverages or Data Interoperability extension-based layers.

If you use your source map document for many purposes other than publishing WFS services, you may need to make a copy of the map document that will act as the source document for the WFS service. You can then alter the copy so that it meets the above requirements without affecting your original map document.

Creating a WFS service from a geodatabase

Another way to create a WFS service is by starting with a geodatabase. This can be any type of geodatabase: personal, file, or ArcSDE. Publish the geodatabase as an ArcGIS Server geodata service using either Manager or ArcCatalog. When prompted for the capabilities you want to enable, check WFS. This creates a URL that any WFS client can use to access the service.

When creating a WFS service from a geodata service, all the feature classes to which the connected user has access will be exposed in the service. Also, only feature classes, tables, and SDE views that are registered with the geodatabase will be exposed in the service.

If you need help publishing the service, see Publishing a GIS resource to the server.

Creating a WFS service from a geodatabase allows you to edit the features as well as read and query them.

Notes on creating WFS services

If a feature class in your map or geodatabase uses a spatial reference that cannot be represented with an EPSG code, WGS 84 will be used as the spatial reference for that feature class.

Feature classes in your map or geodatabase that use an unknown spatial reference system will be ignored by the WFS service.

Setting WFS properties

Once published, you can set properties specific to the WFS service. These properties define the metadata that clients can use to get information about the service. By default, some service-level properties are set, while others are left unset. The following describes how to use Manager or ArcCatalog to set the properties that define the service-level metadata:

Start ArcCatalog or ArcGIS Server Manager.
Open the Service Properties dialog box. To do this in ArcCatalog, right-click an existing service and click Service Properties. In ArcGIS Server Manager, click the Services tab, click Manage Services, then click the Edit icon of the service.
Click the Capabilities tab.
In the list of capabilities, check WFS if it is not checked already. If it is checked already, just click the letters WFS. You'll see some WFS-specific properties appear.
Click Enter service properties below.
In the text boxes, type any service-level metadata you would like to include, such as the name of the service, the title, and the author contact information.
When you've finished adding metadata, click Save and Restart. The information you enter will be exposed in the system-generated capabilities file.

For a description of these properties, see the OGC Web Services Common Specification version 1.0.

Note that the Enable Transactions check box is used to allow edits to be applied through WFS-T. See the Editing and WFS services section below for more information.

Another way to define the metadata is by using an external capabilities file. Using an external capabilities file allows you to include additional projections for your feature types other than the defaults. The defaults include the coordinate system of the layer or feature class and WGS84 (EPSG 4326). See the Advanced topics section below for more information on using external capabilities files.

New at ArcGIS 10.0 you can also set the DefaultMaxFeatures property, which allows you to control the maximum number of features returned by the service. This property can be set in the configuration service file or the external capabilities files. The DefaultMaxFeatures property is only supported with WFS 1.1.0 so if you are using external capabilities files you only need to set this property in the file referencing the 1.1.0 properties.

In a configuration service file the DefaultMaxFeatures property should be defined in the WFSServer section as follows:

<Extension>
	 <TypeName>WFSServer</TypeName>
  <Enabled>true</Enabled>
  <Properties>
    ...
    <EnableDefMaxFeatures>true</EnableDefMaxFeatures>
    <DefMaxFeaturesValue>200</DefMaxFeaturesValue>
  </Properties>
  ...
</ows:Constraint>
</Extension>

If you are using external capabilities the DefaultMaxFeatures property should be defined in the metadata section of WFSServer 1.1.0 file as follows:

<ows:Constraint name="DefaultMaxFeatures">
	 <ows:Value>200</ows:Value>
</ows:Constraint>

Special characters

The following characters cannot be included in any of the service properties: &, <, >, ", '. If you need to use one of these characters, you must substitute the appropriate escape sequence from the table below:

&	&
<	<
>	>
"	"
'	'

Securing WFS services

A WFS service exposes an ArcGIS Server map or geodata service to WFS consumers. The security for a WFS service is managed by controlling the security of its parent map or geodata service. If a particular role, for example, Planners, is denied access to a map, then Planners will not be able to access the map no matter whether they try to consume it through SOAP, REST, or WFS interfaces.

ArcGIS Server supports a number of different authentication schemes. Services that are expected to be accessed via OGC interfaces should be secured using HTTP Basic, HTTP Digest, or Integrated Windows Authentication. Most OGC clients (both non-ESRI and ESRI clients) will understand and work with these widespread standard authentication schemes.

Accessing the WFS service

When you create a WFS service with ArcGIS Server, it can be used in any client that supports WFS.

Types of clients

A Web browser is the simplest client of a WFS service. WFS requests can be issued through HTTP, and the responses or exceptions are returned through the browser. All WFS services support three operations: GetCapabilities, DescribeFeatureType, and GetFeature. Through URL parameters, you can use these operations to obtain service metadata, feature type information, and GML-encoded features from the WFS service. These operations and parameters are detailed in the OGC WFS specifications.

There are many third-party clients available for consuming WFS services. To consume WFS services created by ArcGIS Server, the client must support WFS 1.1 or 1.0 and the Simple Features Profile of GML.

The out-of-the-box Web mapping application that comes with ArcGIS Server does not support the addition of WFS services. However, ArcCatalog and ArcMap can work with WFS services. For help with using WFS services in ArcMap, see How to work with WFS using ArcGIS Desktop.

The WFS 1.1 specification indicates that for many geographic coordinate systems, including WGS84, coordinates are returned in the order latitude, longitude (y,x). WFS services published through ArcGIS server follow this specification. Some WFS clients, however, expect the coordinates to be returned longitude, latitude (x,y). In this case, you can choose to swap the coordinate order for features returned from the WFS service and return longitude, latitude. See Advanced topics below for more information.

URL structure

To connect to the service, you'll need to know the URL. The URL follows this pattern:

http://<server name>/<instance name>/services/<folder name (if applicable)>/<service name>/<service type>/WFSServer?

The server name is the name of your Web server machine.
The instance name is the ArcGIS Server instance name you specified when you installed ArcGIS Server.
The service type can be either MapServer or GeoDataServer, depending on whether you created your WFS service from a map or geodatabase, respectively.

For example, if you enabled the WFS capability on a map service WFSDemoService in a folder DemoFolder on a server MyServer with the default instance name of arcgis, the URL would be as follows: http://MyServer/arcgis/services/DemoFolder/WFSDemoService/MapServer/WFSServer?

Similarly, if you enabled the WFS capability on a geodata service, the URL would be as follows: http://MyServer/arcgis/services/DemoFolder/WFSDemoService/GeoDataServer/WFSServer?

Using filters

When you work with WFS services, you can use a series of filters to select groups of features. WFS services created with ArcGIS Server use the OGC OpenGIS Filter Encoding Implementation Specification (FE) version 1.1. These are the filters you can apply:

Geometry	Spatial	Logical	Comparison	Sort
Envelope	BBOX	And	EqualTo	SortBy*
Point	Equals	Or	NotEqualTo
MultiPoint	Disjoint	Not	LessThan
LineString	Intersects		GreaterThan
Polygon	Crosses		LessThanOrEqualTo
	Touches		GreaterThanOrEqualTo
	Within		Like
	Contains		Between
	Overlaps		NullCheck

Note:

The SortBy filter can only be applied to WFS services that are based on data stored in an ArcSDE geodatabase.

Examples

Examples of using GetFeature with these filters can be found in section 9.5 of the Web Feature Service Implementation Specification.

Working with the FeatureID parameter

The FeatureID parameter can be used in GetFeature requests to request specific features in a WFS service. The FeatureID parameter consists of the FeatureType and the gml:id, not the OBJECTID of the feature. The format of a FeatureID for a feature in an ArcGIS WFS service is <FeatureType>.<gml:id>. One method to identify the gml:id of a feature in a WFS service is to do a GetFeature request on the FeatureType of interest.

Note:

gml:ids are not provided for features in WFS services that are based on shapefiles.

For example: There is a FeatureType called Cities in a WFS service. If you do a GetFeature request for the Cities, the response will include the gml:id for each feature.

URL example: http://bobmk/arcgis/services/wfs_services/ArcSDE_wfs/GeoDataServer/WFSServer?request=getfeature&typename=cities

In this example, the FeatureID for the city of Vancouver would be cities.F293__1. The following request could be used to specifically request the city of Vancouver using the FeatureID: http://bobmk/arcgis/services/wfs_services/ArcSDE_wfs/GeoDataServer/WFSServer?request=getfeature&featureid=cities.F293__1

Working with the Filter parameter

The Filter parameter can be used in GetFeature requests to request specific features in a WFS service. The benefit of the Filter parameter is that it’s part of the standard keyword-value pair encoding defined in the WFS specification and can be appended at the end of an HTTP Get request. The value of the Filter parameter must be set to a URL encoded OGC Filter XML string. Any supported filter listed in the table above can be encoded and sent to server through the Filter parameter.

For example, if you created a FeatureType called blockgroups in a WFS service, you could request blockgoup features within extent -122.423192682619, 37.7877919206256, -122.421377806544, 37.7893634225143 by sending the following GetFeature request:

http://server/arcgis/services/playground/sanfrancisco_wfs/MapServer/WFSServer?service=WFS&request=GetFeature&version=1.1.0&typename=esri:blockgroups&Filter=<ogc:Filter><ogc:BBOX><ogc:PropertyName>Shape</ogc:PropertyName><gml:Box srsName="urn:x-ogc:def:crs:EPSG:4326"><gml:coordinates>37.7877919206256,-122.423192682619 37.7893634225143,-122.421377806544</gml:coordinates></gml:Box></ogc:BBOX></ogc:Filter>

If you want to request a blockgroups feature that contains a specific point feature, such as 122.431577, 37.749936, you could send the following GetFeature request:

http://server/arcgis/services/playground/sanfrancisco_wfs/MapServer/WFSServer?service=WFS&request=GetFeature&version=1.1.0&typename=esri:blockgroups&Filter=<ogc:Filter><ogc:Contains><ogc:PropertyName>Shape</ogc:PropertyName><gml:Point srsName="urn:x-ogc:def:crs:EPSG:4326"><gml:pos srsName="urn:x-ogc:def:crs:EPSG:4326">37.749936 -122.431577</gml:pos></gml:Point></ogc:Contains></ogc:Filter>

Note:

WFS requires involved namespace prefixes to be present in the filter XML string. Additionally, to avoid incorrect conversions being completed by Web browsers or Web servers, URL-encode the filter XML string before sending it to the server.

Editing and WFS services

Map services and geodata services are what you use to publish data from ESRI data sources such as the geodatabase. When you publish a map or geodata service with the WFS capability, the data can be accessed by OGC-compliant WFS clients. These WFS clients can also see the latest changes made to the data.

When a request comes in from a WFS client such as a viewer, the data is returned as it exists in the data source at that time. For example, suppose you have a map document containing a feature class. This feature class comes from a file geodatabase. Now you publish that map document as a map service and enable the WFS capability. A client with a WFS viewer can access the data in the feature class using the WFS URL provided by the map service.

Now suppose someone else accesses the source file geodatabase and adds, updates, and deletes features in the feature class. The next time the client with the WFS viewer refreshes, they will see the data with the most recent edits.

When the data source is an ArcSDE geodatabase, geodata services and map services publish data from a specific version. If data is edited in that version, both WFS clients and non-WFS clients will see these changes. However, if edits are made in other versions, clients will not see the changes until they are reconciled with the published version.

This gives you more control over the data exposed through your services. Suppose you publish some data with the WFS capability from a version named WFS. Clients with WFS viewers then start to access the data through your service. Meanwhile, editors in the office use ArcGIS to update the Default version. The changes made by the editors are then checked and adjusted if necessary. Once the evaluation is complete, the WFS version is reconciled with the Default version. At this point, the WFS clients will see the latest updates from the editors.

Transactional WFS services

A transactional WFS service (sometimes known as WFS-T) allows WFS editors to apply changes to the data in the source database through the WFS service. To apply changes through WFS-T, the data must be from an ArcSDE geodatabase. Transactions can be enabled on services that have versioned data, non-versioned data or a combination of both. If you choose to use versioned data it is also recommended that you publish the service from a non-default version.

To publish your geodatabase as a transactional WFS service, follow these steps:

Determine if you want the data published through the WFS service to be versioned or non-versioned. If you are publishing versioned data create a version specifically for your transactional WFS editors. If you are using non-versioned data, you can publish the service on the default version.
Select the type of service you want to use to publish your data as a WFS service. You can either publish a geodatabase connection file (as a geodata service) or a map document (as a map service). If you are using a map service with versioned data make sure that the data in the map document is only referencing data from the specific version created for the WFS editors. Ensure that the WFS capability is enabled on the service.
Enable transactions on the service. This can be done in either ArcCatalog or Manager as follows:
- Stop the service.
- Display the Service Properties.
- Click the Capabilities tab.
- Click the name WFS (not the check box).
- Check Enable Transactions.
- Start the service.

Once transactions are enabled, WFS clients can apply changes to the geodatabase using transactional WFS methods. The following is an example of how changes can be applied:

The WFS client connects to the WFS service that has been published with transactions enabled.
The edited features and rows are locked on the server (this can be done using the GetFeatureWithLock WFS method).
Edits are performed using a WFS editor on the WFS client.
Edits are then applied on the server (this can be done using the Transaction WFS method).

When the edits are posted, the locks are released and the features can be edited by other WFS editors. Locks can also be released if they time out. By default, locks will time out after 5 minutes, but this can be adjusted by specifying a time-out in minutes using the GetFeatureWithLock method. An administrator can set the default time-out by manually editing a configuration and setting the element DefaultLockExpiration (time in minutes).

When a client requests a lock using GetFeatureWithLock, a feature collection with the locked features and a lockID are returned. If any of the requested features cannot be locked, the request will fail, and the client will need to call GetFeatureWithLock again. Other clients will be prevented from acquiring locks on these features until the locks are released.

Insert-only transactions do not require features to be locked. Since existing features are not being modified (updated or deleted), there is no need to call GetFeatureWithLock. Any transaction requests with updates or deletions must have a lockID.

When changes are posted through WFS-T, they are applied to the published version (with versioned data) or to the business tables (with non-versioned data). The following sections discuss important workflows differences to be aware of when working with either versioned or non-versioned data.

WFS-T services and versioned data

The power of versioning allows you to expose your geodatabase to both WFS and non-WFS editors and to effectively merge the edits made by the two groups with full conflict detection. To merge edits, you can reconcile and post the published WFS-T version with its parent. If there are outstanding locks, the system will not allow reconcile and post to succeed. This is to prevent conflicts between features locked by a WFS-T client and features changed because of the reconcile and post process. In addition, reconcile and post will lock the published version, preventing GetFeatureWithLock and Transaction calls during the reconcile and post process. For more information about working with versioned data: A quick tour of versioning

WFS-T services workflow with versioned data

Feature locks are kept on the server by means of a locks table. The locks table is created when transactions are enabled and appears as a regular table in the geodatabase. The table is named following the convention VERSION_<versionID>_ROW_LOCKS. To prevent reconcile and post from being blocked, administrators may want to delete outstanding locks by directly deleting rows from the locks table before calling reconcile and post.

The published WFS-T version shouldn't be edited using ArcGIS. An ArcGIS editor isn't aware of feature locks, and therefore, locked features may be edited. In such a case, the edits made in ArcGIS may cause conflicts that prevent the WFS-T client from uploading its changes. Creating and editing child versions of the published version may also cause similar problems if changes are reconciled and posted into the published version.

Multiple WFS-T services can reference the same published version, since all of them share the same locks table. There is a 1-to-1 association between the published version and its locks table.

If you disable transactions or remove the WFS service, the locks table will not automatically be deleted. Once there are no longer any WFS-T services referencing the version, this table can be deleted manually.

WFS-T services and non-versioned data

If you publish non-versioned data in a WFS-T service the edits get applied directly to the business tables in the Geodatabase so once the edits are committed they cannot be undone. For more information about working with non-versioned data see:

With non-versioned data based WFS-T services feature locks are also kept on the server in a locks table, which is created when transactions are enabled on the service. If you plan to only have WFS-T clients edit through the service it will have same behavior as a versioned data based service. However if you intend to have non WFS-T clients such as ArcMap, edit the data published in the service there are some important things to be a aware of;

ArcMap editors are not aware of the feature locks and as a result features locked through the WFS-T service can be edited.
If an ArcMap editor edits features they will appear locked to the WFS-T clients. As a result WFS-T clients cannot lock, update or delete those features until the ArcMap editor saves the edits.

Notes

The DBMS user that ArcGIS Server uses to connect to the ArcSDE geodatabase must be granted permissions to create tables in the DBMS to successfully use WFS-T.
ArcMap does not have a mechanism for transactional WFS editing, meaning you must use a third-party client to edit features using WFS.
You can use pooled services when editing through WFS-T since access to the service is not required at all times.
Feature classes that are Z-aware cannot be edited using WFS-T.

Advanced topics

This section contains advanced items of information regarding WFS services:

Using external capabilities files

Publishing a WFS service using external capabilities files is aimed at users who are familiar with OGC WFS specifications and WFS capabilities files syntax. This option gives you maximum flexibility to customize your WFS services. With external capabilities files, you can do the following:

Add service-level metadata information to WFS capabilities files.
Add feature-level metadata information to WFS capabilities files.
Add additional predefined spatial reference systems from the ArcGIS Server predefined projection list.

Publishing a WFS service using an external capabilities file saves the time it takes to create the capabilities file from scratch each time the service is accessed. This may improve the speed in connecting to your WFS service, especially when there are many type names in your service. However, if you make changes to the service's underlying map document or geodatabase, you must also update the capabilities file accordingly for the service to continue working.

There are two different methods that can be used to create an external capabilities file. You can create the capabilities files from scratch in an XML or text editor. You can also generate a capabilities file by publishing a WFS service with the defaults and calling GetCapabilities from a Web browser. The contents returned from the GetCapabilities requests can be saved as and .xml file, modified as desired, and used as the external capabilities file. How to structure and fill in the content of the external capabilities file is beyond the scope of this help system, but more information is available at the Further reading link at the end of this topic.

As of ArcGIS 9.3 SP1, ArcGIS Server is compliant with both 1.1.0 and 1.0.0 OGC WFS specifications. As a result, the steps to create and use external capabilities files for ArcGIS 9.3 SP1 have changed. The following steps will cover how to create external capabilities files from an existing WFS service and how to publish a WFS service using these files. Steps will be included for both ArcGIS 9.3 and the new process starting at ArcGIS 9.3 SP1.

How to create and publish a WFS service with external capabilities files at ArcGIS 9.3

Part 1: Creating an external capabilities file from an existing WFS service

Start ArcCatalog or ArcGIS Server Manager.
Open the Service Properties dialog box. To do this in ArcCatalog, right-click an existing service and click Service Properties. In ArcGIS Server Manager, click the Services tab and click the Edit icon of the service.
Click the Capabilities tab.
In the list of capabilities, check WFS if it is not checked already. If it is checked already, just click the letters WFS. Some WFS-specific properties appear.
Highlight the WFS URL and copy and paste it into a Web browser.
To create the external capabilities file for WFS 1.1.0 specifications, append ?request=getCapabilities or request=getCapabilities&version=1.1.0 to the WFS URL in the Web browser and save the results as an XML file with the version number appended to the end. At ArcGIS 9.3, the .xml file must be saved as GetCapabilities110.xml.

Part 2: Creating a WFS Service with an external capabilities file at ArcGIS 9.3

Once the capabilities file has been created, it can be placed in a folder accessible to the SOC and the server. For example, the file can be placed in the same folder as the geodatabase or map document of the service. A URL location can also be used.

An existing service that is using the default properties can be updated to use an external capabilities file, or a new service that references the external capabilities file can be created. The steps below describe how to publish a WFS service with an external capabilities file.

Note:

It is important to note that only one external capabilities file can be saved in a folder at ArcGIS 9.3; otherwise, the server cannot distinguish which capabilities file should be used, since they all must be called GetCapabilities110.xml.

How to publish a WFS service with the external capabilities files:

Start ArcCatalog or ArcGIS Server Manager.
Stop the service that you want to update.
Open the Service Properties dialog box. To do this in ArcCatalog, right-click an existing service and click Service Properties. In ArcGIS Server Manager, click the Services tab and click the Edit icon of the service.
Click the Capabilities tab.
In the list of capabilities, check WFS if it is not checked already. If it is checked already, just click the letters WFS. You'll see some WFS-specific properties appear.
Click Use external capabilities files.
The next step is to specify the location of the external capabilities file. The location is specified by providing the URL or folder path that contains the capabilities file. When specifying the location or URL, do not include the name of the .xml file. An example of a URL location is http://<server name>/arcgis/wfs, and an example of a folder location is C:\arcgis\arcgisserver\wfs.
Restart the service.

How to create and publish a WFS service with external capabilities files as of ArcGIS 9.3 SP1

As of ArcGIS 9.3 SP1, ArcGIS Server is compliant with both 1.1.0 and 1.0.0 OGC WFS specifications. As a result, two external capabilities files are required, one that references 1.1.0 specifications and one that references 1.0.0 specifications.

Part 1: Creating external capabilities files from an existing WFS service

Start ArcCatalog or ArcGIS Server Manager.
Open the Service Properties dialog box. To do this in ArcCatalog, right-click an existing service and click Service Properties. In ArcGIS Server Manager, click the Services tab and click the Edit icon of the service.
Click the Capabilities tab.
In the list of capabilities, check WFS if it is not checked already. If it is checked already, just click the letters WFS. Some WFS-specific properties appear.
Highlight the WFS URL and copy and paste it into a Web browser.
Create the external capabilities file for WFS 1.1.0 specifications by appending ?request=getCapabilities or request=getCapabilities&version=1.1.0 to the WFS URL in the Web browser and save the results as an XML file. The file name must have the format <prefix>110.xml. For example, if the service is called California, you may want to name the file California110.xml, where California is the prefix.
Create the external capabilities file for WFS 1.0.0 specifications by appending ?request=getCapabilities&version1.0.0 to the WFS URL and save the results as an XML file. The file name must have the format <prefix>100.xml, and the prefix must match that of the 1.1.0 file. Following the example in step 6, if the 1.1.0 file is called California110.xml, the 1.0.0 file must be called California100.xml.

Part 2: Creating a WFS Service with an external capabilities file as of 9.3 SP1

Once the <prefix>110.xml and <prefix>100.xml capabilities files have been created, they must be placed in the same directory accessible to the SOC and the server. For example, the files can be placed in the same folder as the geodatabase or map document of the service. A URL location can also be used.

An existing service that is using the default properties can be updated to use the external capabilities files, or a new service that references the external capabilities files can be created. The steps below describe how to publish a WFS service with the external capabilities files.

How to publish a WFS service with the external capabilities files:

Start ArcCatalog or ArcGIS Server Manager.
Stop the service to be updated.
Open the Service Properties dialog box. To do this in ArcCatalog, right-click an existing service and click Service Properties. In ArcGIS Server Manager, click the Services tab and click the Edit icon of the service.
Click the Capabilities tab.
In the list of capabilities, check WFS if it is not checked already. If it is checked already, just click the letters WFS. Some WFS-specific properties appear.
Click Use external capabilities files.
The next step is to specify the location of the external capabilities files. The location is specified by providing the URL or folder path that contains the capabilities files and the prefix. For example, if you have capabilities files named California110.xml and California100.xml for your California service, the prefix is California. If these files are stored in http://ArcGIS_Server/arcgis/wfs, you would specify http://ArcGIS_Server/arcgis/wfs/California. If you choose to store these files in C:\arcgis\arcgisserver\wfs instead, you would specify C:\arcgis\arcgisserver\wfs\California.
Restart the service.

Note:

If the 1.1.0 and 1.0.0 capabilities files do not exist in the same directory, the WFS service will fail to start. Ensure the files are placed in the same directory and are accessible to the SOC and the server.

Now when a WFS client accesses the service, the appropriate capabilities file will be referenced based on the version of the request. For example, if the WFS client calls DescribeFeatureType&version=1.0.0, then the server would respond with information from the 1.0.0-specific external capabilities file. If no version is specified, it will return information from the 1.1.0-specific external capabilities file.

Adding spatial reference systems to an external capabilities file

Although you can request a map from the WFS service using any of the hundreds of supported spatial reference systems, some WFS clients will return an error if the spatial reference you request does not appear in the capabilities file. Other clients, such as the Data Interoperability extension, only allow you to switch among the spatial reference systems listed in the capabilities file.

You can manually add more spatial reference systems to the external capabilities file of your WFS service. External capabilities files are described above.

Controlling the axis order

Features returned in some geographic coordinate systems (for example, WGS 84) have an axis order of latitude, longitude (y,x) by default. This is in compliance with the WFS 1.1 specification. For example, a point may be returned from a getfeature request with its coordinates specified as follows:

<gml:Point>
	<gml:pos>48.4922165520043 -122.630685732366</gml:pos> 
</gml:Point>

Some WFS clients expect the coordinates to be returned with an axis order of longitude, latitude (x,y). To work with these clients, you can set the axis order for the service to be longitude, latitude. The following describes how to set the property:

Log on to the machine running ArcGIS server as an administrator.
Shut down ArcGIS Server.
Go to the location of the service configuration files. For example, if ArcGIS Server is installed in c:\arcgis, go to c:\arcgis\server\user\cfg.
Open the configuration file for your service (for example, myservice.cfg) in a text editor.

In the WFS section, add the following to the properties: <AxisOrderWFS11>longlat</AxisOrderWFS11>. For example:

<Extension>
	<TypeName>WFSServer</TypeName>
	<Enabled>true</Enabled>
	<Properties>
		<AxisOrderWFS11>longlat</AxisOrderWFS11>
		<CustomGetCapabilities>false</CustomGetCapabilities>
		<EnableTransactions>false</EnableTransactions>
		<Name>wfs_WFSTest_ras</Name>
		<OnlineResource>http://bobmk/arcgis/services/wfs/WFSTest_ras/MapServer/WFSServer</OnlineResource>
		<AppSchemaURI>http://bobmk/arcgis/services/wfs/WFSTest_ras/MapServer/WFSServer</AppSchemaURI>
		<AppSchemaPrefix>wfs_WFSTest_ras</AppSchemaPrefix>
	</Properties>
	<Info>
		<WebEnabled>true</WebEnabled>
	</Info>
</Extension>

Start ArcGIS Server.

Features with geographic coordinates requested from the service are now returned with a longitude, latitude axis order.

Note that the axis order property only applies to features with geographic coordinates. Features with projected coordinates are always returned with an x,y axis order.

Using fully qualified type names

The type names generated for WFS services defined from ArcSDE geodatabases will be based on the unqualified name of the feature class by default. For example, the type name for a feature class named bob.buildings will be buildings.

You can set a property to include the fully qualified name when the type name is generated. You may want to do this if more than one feature class has the same name but a different owner in the geodatabase. When the fully qualified name is used, the type name for bob.buildings will be bob_buildings.

The following describes how to set the property to use the fully qualified name:

Log on as an administrator to the machine running ArcGIS Server.
Shut down ArcGIS Server.
Go to the location of the service configuration files. For example, if ArcGIS Server is installed in c:\arcgis, go to c:\arcgis\server\user\cfg.
Open the configuration file for your service (for example, myservice.cfg) in a text editor.

In the WFS section, add the following to the properties: <UseQualifiedName>true</UseQualifiedName>. For example:

<Extension>
	<TypeName>WFSServer</TypeName>
	<Enabled>true</Enabled>
	<Properties>
		<UseQualifiedName>true</UseQualifiedName>
		<CustomGetCapabilities>false</CustomGetCapabilities>
		<EnableTransactions>false</EnableTransactions>
		<Name>wfs_WFSTest_ras</Name>
		<OnlineResource>http://bobmk/arcgis/services/wfs/WFSTest_ras/MapServer/WFSServer</OnlineResource>
		<AppSchemaURI>http://bobmk/arcgis/services/wfs/WFSTest_ras/MapServer/WFSServer</AppSchemaURI>
		<AppSchemaPrefix>wfs_WFSTest_ras</AppSchemaPrefix>
	</Properties>
	<Info>
		<WebEnabled>true</WebEnabled>
	</Info>
</Extension>

Start ArcGIS Server.