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.
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 enterprise geodatabase. Unlike the OGC Web Map Service (WMS), which 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 are compliant with the WFS 1.1.0 and 2.0 specifications. They also support the WFS 1.0.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.
How to create a WFS service
There are two ways you can create a WFS service: from a map or from an enterprise geodatabase.
Creating a WFS service from a map
You can create a WFS service by publishing your ArcMapdocument to ArcGIS Server. When prompted for the capabilities you want to enable when publishing, check WFS. This creates a URL that any WFS client can use to access the service. For detailed instructions on how to create a WFS service from a map, see Tutorial: Publishing a WFS service.
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 do 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 items 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 enterprise geodatabase; otherwise, the map cannot contain layers from multiple sources.
The name of the layer is the type name returned from WFS.
To publish data through a WFS service, the data must be registered with the enterprise geodatabase.
Since WFS only works with features, any raster layers in the map are excluded from the service.
WFS services only support simple features, and do not support geodatabase functionality such as relationship classes, joins, networks, and rules.
If you use your source map document for 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 an enterprise geodatabase
Another way to create a WFS service is by starting with an enterprise geodatabase and then publishing the geodatabase as a geodata service. When prompted for the capabilities you want to enable when publishing, check WFS. This creates a URL that any WFS client can use to access the service. For detailed instructions on how to create a WFS service from an enterprise geodatabase, see Tutorial: Publishing a WFS service.
When creating a WFS service from a geodata service, all the feature classes to which the connected user has access are exposed in the service. Also, only feature classes and tables that are registered with the enterprise geodatabase are exposed in the service.
Creating a WFS service from an enterprise geodatabase allows you to read, query, and edit features.
Note:
If a feature class in your map or enterprise geodatabase uses a spatial reference that cannot be represented with an EPSG (European Petroleum Survey Group) code, WGS84 is used as the spatial reference for that feature class. Feature classes in your map or enterprise geodatabase that use an unknown spatial reference system are ignored by the WFS service.
Configuring WFS service properties
A WFS service's properties are reflected in its capabilities files. When publishing a WFS service with system-generated capabilities files (the default), it is recommended that you populate the WFS service properties. For information about each WFS service property you can set, see Available WFS service properties. Additionally, the following topics include instructions on how to get to the location where you can set WFS service properties:
Setting WFS properties using an external capabilities file
Another way to define the metadata for a WFS service is by using an external capabilities file. This 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 Using external capabilities files with WFS services for more information.
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, Planners will not be able to access the map 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 or HTTP Digest. Most OGC clients (both non-Esri and Esri clients) will understand and work with these widespread standard authentication schemes.