reference.rst 21 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518
  1. .. _wfs_reference:
  2. WFS reference
  3. =============
  4. The `Web Feature Service <http://www.opengeospatial.org/standards/wfs>`_ (WFS) is a standard created by the Open Geospatial Consortium (OGC) for creating, modifying and exchanging vector format geographic information on the Internet using HTTP. A WFS encodes and transfers information in Geography Markup Language (GML), a subset of XML.
  5. The current version of WFS is **2.0.0**. GeoServer supports versions 2.0.0, 1.1.0, and 1.0.0. Although there are some important differences between the versions, the request syntax often remains the same.
  6. A related OGC specification, the :ref:`wms`, defines the standard for exchanging geographic information in digital image format.
  7. Benefits of WFS
  8. ---------------
  9. The WFS standard defines the framework for providing access to, and supporting transactions on, discrete geographic features in a manner that is independent of the underlying data source. Through a combination of discovery, query, locking, and transaction operations, users have access to the source spatial and attribute data in a manner that allows them to interrogate, style, edit (create, update, and delete), and download individual features. The transactional capabilities of WFS also support the development and deployment of collaborative mapping applications.
  10. Operations
  11. ----------
  12. All versions of WFS support these operations:
  13. .. list-table::
  14. :widths: 20 80
  15. :header-rows: 1
  16. * - Operation
  17. - Description
  18. * - `GetCapabilities`_
  19. - Generates a metadata document describing a WFS service provided by server as well as valid WFS operations and parameters
  20. * - `DescribeFeatureType`_
  21. - Returns a description of feature types supported by a WFS service
  22. * - `GetFeature`_
  23. - Returns a selection of features from a data source including geometry and attribute values
  24. * - `LockFeature`_
  25. - Prevents a feature from being edited through a persistent feature lock
  26. * - `Transaction`_
  27. - Edits existing feature types by creating, updating, and deleting
  28. The following operations are available in **version 2.0.0 only**:
  29. .. list-table::
  30. :widths: 20 80
  31. :header-rows: 1
  32. * - Operation
  33. - Description
  34. * - `GetPropertyValue`_
  35. - Retrieves the value of a feature property or part of the value of a complex feature property from the data store for a set of features identified using a query expression
  36. * - `GetFeatureWithLock`_
  37. - Returns a selection of features and also applies a lock on those features
  38. * - `CreateStoredQuery`_
  39. - Create a stored query on the WFS server
  40. * - `DropStoredQuery`_
  41. - Deletes a stored query from the WFS server
  42. * - `ListStoredQueries`_
  43. - Returns a list of the stored queries on a WFS server
  44. * - `DescribeStoredQueries`_
  45. - Returns a metadata document describing the stored queries on a WFS server
  46. The following operations are available in **version 1.1.0 only**:
  47. .. list-table::
  48. :widths: 20 80
  49. :header-rows: 1
  50. * - Operation
  51. - Description
  52. * - `GetGMLObject`_
  53. - Retrieves features and elements by ID from a WFS
  54. .. note:: In the examples that follow, the fictional URL ``http://example.com/geoserver/wfs`` is used for illustration. To test the examples, substitute the address of a valid WFS. Also, although the request would normally be defined on one line with no breaks, breaks are added for clarity in the examples provided.
  55. .. _wfs_getcap:
  56. GetCapabilities
  57. ~~~~~~~~~~~~~~~
  58. The **GetCapabilities** operation is a request to a WFS server for a list of the operations and services, or *capabilities*, supported by that server.
  59. To issue a GET request using HTTP::
  60. http://example.com/geoserver/wfs?
  61. service=wfs&
  62. version=1.1.0&
  63. request=GetCapabilities
  64. The equivalent request using POST:
  65. .. code-block:: xml
  66. <GetCapabilities
  67. service="WFS"
  68. xmlns="http://www.opengis.net/wfs"
  69. xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  70. xsi:schemaLocation="http://www.opengis.net/wfs
  71. http://schemas.opengis.net/wfs/1.1.0/wfs.xsd"/>
  72. GET requests are simplest to decode, but the POST requests are equivalent.
  73. The parameters for GetCapabilities are:
  74. .. list-table::
  75. :widths: 20 20 60
  76. :header-rows: 1
  77. * - Parameter
  78. - Required?
  79. - Description
  80. * - ``service``
  81. - Yes
  82. - Service name—Value is ``WFS``
  83. * - ``version``
  84. - Yes
  85. - Service version—Value is the current version number. The full version number must be supplied ("1.1.0", "1.0.0"), not the abbreviated form ("1" or "1.1").
  86. * - ``request``
  87. - Yes
  88. - Operation name—Value is ``GetCapabilities``
  89. Although all of the above parameters are technically required as per the specification, GeoServer will provide default values if any parameters are omitted from a request.
  90. The GetCapabilities response is a lengthy XML document, the format of which is different for each of the supported versions. There are five main components in a GetCapabilities document:
  91. .. list-table::
  92. :widths: 20 80
  93. :header-rows: 1
  94. * - Component
  95. - Description
  96. * - ``ServiceIdentification``
  97. - Contains basic header information for the request such as the ``Title`` and ``ServiceType``. The ``ServiceType`` indicates which version(s) of WFS are supported.
  98. * - ``ServiceProvider``
  99. - Provides contact information about the company publishing the WFS service, including telephone, website, and email.
  100. * - ``OperationsMetadata``
  101. - Describes the operations that the WFS server supports and the parameters for each operation. A WFS server may be configured not to respond to the operations listed above.
  102. * - ``FeatureTypeList``
  103. - Lists the feature types published by a WFS server. Feature types are listed in the form ``namespace:featuretype``. The default projection of the feature type is also listed, along with the bounding box for the data in the stated projection.
  104. * - ``Filter_Capabilities``
  105. - Lists the filters, or expressions, that are available to form query predicates, for example, ``SpatialOperators`` (such as ``Equals``, ``Touches``) and ``ComparisonOperators`` (such as ``LessThan``, ``GreaterThan``). The filters themselves are not included in the GetCapabilities document.
  106. .. _wfs_dft:
  107. DescribeFeatureType
  108. ~~~~~~~~~~~~~~~~~~~
  109. **DescribeFeatureType** requests information about an individual feature type before requesting the actual data. Specifically, the operation will request a list of features and attributes for the given feature type, or list the feature types available.
  110. The parameters for DescribeFeatureType are:
  111. .. list-table::
  112. :widths: 20 20 60
  113. :header-rows: 1
  114. * - Parameter
  115. - Required?
  116. - Description
  117. * - ``service``
  118. - Yes
  119. - Service name—Value is ``WFS``
  120. * - ``version``
  121. - Yes
  122. - Service version—Value is the current version number
  123. * - ``request``
  124. - Yes
  125. - Operation name—Value is ``DescribeFeatureType``
  126. * - ``typeNames``
  127. - Yes
  128. - Name of the feature type to describe (``typeName`` for WFS 1.1.0 and earlier)
  129. * - ``exceptions``
  130. - No
  131. - Format for reporting exceptions—default value is ``application/vnd.ogc.se_xml``
  132. * - ``outputFormat``
  133. - No
  134. - Defines the scheme description language used to describe feature types
  135. To return a list of feature types, the GET request would be as follows. This request will return the list of feature types, sorted by namespace::
  136. http://example.com/geoserver/wfs?
  137. service=wfs&
  138. version=2.0.0&
  139. request=DescribeFeatureType
  140. To list information about a specific feature type called ``namespace:featuretype``, the GET request would be::
  141. http://example.com/geoserver/wfs?
  142. service=wfs&
  143. version=2.0.0&
  144. request=DescribeFeatureType&
  145. typeNames=namespace:featuretype
  146. .. _wfs_getfeature:
  147. GetFeature
  148. ~~~~~~~~~~
  149. The **GetFeature** operation returns a selection of features from the data source.
  150. This request will execute a GetFeature request for a given layer ``namespace:featuretype``::
  151. http://example.com/geoserver/wfs?
  152. service=wfs&
  153. version=2.0.0&
  154. request=GetFeature&
  155. typeNames=namespace:featuretype
  156. Executing this command will return the geometries for all features in given a feature type, potentially a large amount of data. To limit the output, you can restrict the GetFeature request to a single feature by including an additional parameter, ``featureID`` and providing the ID of a specific feature. In this case, the GET request would be::
  157. http://example.com/geoserver/wfs?
  158. service=wfs&
  159. version=2.0.0&
  160. request=GetFeature&
  161. typeNames=namespace:featuretype&
  162. featureID=feature
  163. If the ID of the feature is unknown but you still want to limit the number of features returned, use the ``count`` parameter for WFS 2.0.0 or the ``maxFeatures`` parameter for earlier WFS versions. In the examples below, ``N`` represents the number of features to return::
  164. http://example.com/geoserver/wfs?
  165. service=wfs&
  166. version=2.0.0&
  167. request=GetFeature&
  168. typeNames=namespace:featuretype&
  169. count=N
  170. ::
  171. http://example.com/geoserver/wfs?
  172. service=wfs&
  173. version=1.1.0&
  174. request=GetFeature&
  175. typeName=namespace:featuretype&
  176. maxFeatures=N
  177. Exactly which N features will be returned depends in the internal structure of the data. However, you can sort the returned selection based on an attribute value. In the following example, an attribute is included in the request using the ``sortBy=attribute`` parameter (replace ``attribute`` with the attribute you wish to sort by)::
  178. http://example.com/geoserver/wfs?
  179. service=wfs&
  180. version=2.0.0&
  181. request=GetFeature&
  182. typeNames=namespace:featuretype&
  183. count=N&
  184. sortBy=attribute
  185. The default sort operation is to sort in ascending order. Some WFS servers require the sort order to be specified, even if an ascending order sort if required. In this case, append a ``+A`` to the request. Conversely, add a ``+D`` to the request to sort in descending order as follows::
  186. http://example.com/geoserver/wfs?
  187. service=wfs&
  188. version=2.0.0&
  189. request=GetFeature&
  190. typeNames=namespace:featuretype&
  191. count=N&
  192. sortBy=attribute+D
  193. There is no obligation to use ``sortBy`` with ``count`` in a GetFeature request, but they can be used together to manage the returned selection of features more effectively.
  194. To restrict a GetFeature request by attribute rather than feature, use the ``propertyName`` key in the form ``propertyName=attribute``. You can specify a single attribute, or multiple attributes separated by commas. To search for a single attribute in all features, the following request would be required::
  195. http://example.com/geoserver/wfs?
  196. service=wfs&
  197. version=2.0.0&
  198. request=GetFeature&
  199. typeNames=namespace:featuretype&
  200. propertyName=attribute
  201. For a single property from just one feature, use both ``featureID`` and ``propertyName``::
  202. http://example.com/geoserver/wfs?
  203. service=wfs&
  204. version=2.0.0&
  205. request=GetFeature&
  206. typeNames=namespace:featuretype&
  207. featureID=feature&
  208. propertyName=attribute
  209. For more than one property from a single feature, use a comma-separated list of values for ``propertyName``::
  210. http://example.com/geoserver/wfs?
  211. service=wfs&
  212. version=2.0.0&
  213. request=GetFeature&
  214. typeNames=namespace:featuretype&
  215. featureID=feature&
  216. propertyName=attribute1,attribute2
  217. While the above permutations for a GetFeature request focused on non-spatial parameters, it is also possible to query for features based on geometry. While there are limited options available in a GET request for spatial queries (more are available in POST requests using filters), filtering by bounding box (BBOX) is supported.
  218. The BBOX parameter allows you to search for features that are contained (or partially contained) inside a box of user-defined coordinates. The format of the BBOX parameter is ``bbox=a1,b1,a2,b2,[crs]`` where ``a1``, ``b1``, ``a2``, and ``b2`` represent the coordinate values. The optional ``crs`` parameter is used to name the CRS for the bbox coordinates (if they are different to the featureTypes native CRS.) The order of coordinates passed to the BBOX parameter depends on the coordinate system used
  219. (this is why the coordinate syntax isn't represented with ``x`` or ``y``.)
  220. To specify the coordinate system for the returned features, append ``srsName=CRS`` to the WFS request, where ``CRS`` is the Coordinate Reference System you wish to use.
  221. As for which corners of the bounding box to specify, the only requirement is for a bottom corner (left or right) to be provided first. For example, bottom left and top right, or bottom right and top left.
  222. An example request returning features based on a bounding box (using the featureTypes native CRS)::
  223. http://example.com/geoserver/wfs?
  224. service=wfs&
  225. version=2.0.0&
  226. request=GetFeature&
  227. typeNames=namespace:featuretype&
  228. srsName=CRS&
  229. bbox=a1,b1,a2,b2
  230. To request features using a bounding box with CRS different from featureTypes native CRS::
  231. http://example.com/geoserver/wfs?
  232. service=wfs&
  233. version=2.0.0&
  234. request=GetFeature&
  235. typeNames=namespace:featuretype&
  236. srsName=CRS&
  237. bbox=a1,b1,a2,b2,CRS
  238. LockFeature
  239. ~~~~~~~~~~~
  240. A **LockFeature** operation provides a long-term feature locking mechanism to ensure consistency in edit transactions. If one client fetches a feature and makes some changes before submitting it back to the WFS, locks prevent other clients from making any changes to the same feature, ensuring a transaction that can be serialized. If a WFS server supports this operation, it will be reported in the server's GetCapabilities response.
  241. In practice, few clients support this operation.
  242. .. _wfs_wfst:
  243. Transaction
  244. ~~~~~~~~~~~
  245. The **Transaction** operation can create, modify, and delete features published by a WFS. Each transaction will consist of zero or more Insert, Update, and Delete elements, with each transaction element performed in order. Every GeoServer transaction is *atomic*, meaning that if any of the elements fail, the transaction is abandoned, and the data is unaltered. A WFS server that supports **transactions** is sometimes known as a WFS-T server. **GeoServer fully supports transactions.**
  246. More information on the syntax of transactions can be found in the `WFS specification <http://www.opengeospatial.org/standards/wfs>`_ and in the :ref:`GeoServer sample requests <demos>`.
  247. GetGMLObject
  248. ~~~~~~~~~~~~
  249. .. note:: This operation is valid for **WFS version 1.1.0 only**.
  250. A **GetGMLObject** operation accepts the identifier of a GML object (feature or geometry) and returns that object. This operation is relevant only in situations that require :ref:`app-schema.complex-features` by allowing clients to extract just a portion of the nested properties of a complex feature. As a result, this operation is not widely used by client applications.
  251. GetPropertyValue
  252. ~~~~~~~~~~~~~~~~
  253. .. note:: This operation is valid for **WFS version 2.0.0 only**.
  254. A **GetPropertyValue** operation retrieves the value of a feature property, or part of the value of a complex feature property, from a data source for a given set of features identified by a query.
  255. This example retrieves the geographic content only of the features in the ``topp:states`` layer::
  256. http://example.com/geoserver/wfs?
  257. service=wfs&
  258. version=2.0.0&
  259. request=GetPropertyValue&
  260. typeNames=topp:states&
  261. valueReference=the_geom
  262. The same example in a POST request:
  263. .. code-block:: xml
  264. <wfs:GetPropertyValue service='WFS' version='2.0.0'
  265. xmlns:topp='http://www.openplans.org/topp'
  266. xmlns:fes='http://www.opengis.net/fes/2.0'
  267. xmlns:wfs='http://www.opengis.net/wfs/2.0'
  268. valueReference='the_geom'>
  269. <wfs:Query typeNames='topp:states'/>
  270. </wfs:GetPropertyValue>
  271. To retrieve value for a different attribute, alter the ``valueReference`` parameter.
  272. GetFeatureWithLock
  273. ~~~~~~~~~~~~~~~~~~
  274. .. note:: This operation is valid for **WFS version 2.0.0 only**.
  275. A **GetFeatureWithLock** operation is similar to a **GetFeature** operation, except that when the set of features are returned from the WFS server, the features are also locked in anticipation of a subsequent transaction operation.
  276. This POST example retrieves the features of the ``topp:states`` layer, but in addition locks those features for five minutes.
  277. .. code-block:: xml
  278. <wfs:GetFeatureWithLock service='WFS' version='2.0.0'
  279. handle='GetFeatureWithLock-tc1' expiry='5' resultType='results'
  280. xmlns:topp='http://www.openplans.org/topp'
  281. xmlns:fes='http://www.opengis.net/fes/2.0'
  282. xmlns:wfs='http://www.opengis.net/wfs/2.0'
  283. valueReference='the_geom'>
  284. <wfs:Query typeNames='topp:states'/>
  285. </wfs:GetFeatureWithLock>
  286. To adjust the lock time, alter the ``expiry`` parameter.
  287. CreateStoredQuery
  288. ~~~~~~~~~~~~~~~~~
  289. .. note:: This operation is valid for **WFS version 2.0.0 only**.
  290. A **CreateStoredQuery** operation creates a stored query on the WFS server. The definition of the stored query is encoded in the ``StoredQueryDefinition`` parameter and is given an ID for a reference.
  291. This POST example creates a new stored query (called "myStoredQuery") that filters the ``topp:states`` layer to those features that are within a given area of interest (``${AreaOfInterest}``):
  292. .. code-block:: xml
  293. <wfs:CreateStoredQuery service='WFS' version='2.0.0'
  294. xmlns:wfs='http://www.opengis.net/wfs/2.0'
  295. xmlns:fes='http://www.opengis.org/fes/2.0'
  296. xmlns:gml='http://www.opengis.net/gml/3.2'
  297. xmlns:myns='http://www.someserver.com/myns'
  298. xmlns:topp='http://www.openplans.org/topp'>
  299. <wfs:StoredQueryDefinition id='myStoredQuery'>
  300. <wfs:Parameter name='AreaOfInterest' type='gml:Polygon'/>
  301. <wfs:QueryExpressionText
  302. returnFeatureTypes='topp:states'
  303. language='urn:ogc:def:queryLanguage:OGC-WFS::WFS_QueryExpression'
  304. isPrivate='false'>
  305. <wfs:Query typeNames='topp:states'>
  306. <fes:Filter>
  307. <fes:Within>
  308. <fes:ValueReference>the_geom</fes:ValueReference>
  309. ${AreaOfInterest}
  310. </fes:Within>
  311. </fes:Filter>
  312. </wfs:Query>
  313. </wfs:QueryExpressionText>
  314. </wfs:StoredQueryDefinition>
  315. </wfs:CreateStoredQuery>
  316. DropStoredQuery
  317. ~~~~~~~~~~~~~~~
  318. .. note:: This operation is valid for **WFS version 2.0.0 only**.
  319. A **DropStoredQuery** operation drops a stored query previous created by a CreateStoredQuery operation. The request accepts the ID of the query to drop.
  320. This example will drop a stored query with an ID of ``myStoredQuery``::
  321. http://example.com/geoserver/wfs?
  322. request=DropStoredQuery&
  323. storedQuery_Id=myStoredQuery
  324. The same example in a POST request:
  325. .. code-block:: xml
  326. <wfs:DropStoredQuery
  327. xmlns:wfs='http://www.opengis.net/wfs/2.0'
  328. service='WFS' id='myStoredQuery'/>
  329. ListStoredQueries
  330. ~~~~~~~~~~~~~~~~~
  331. .. note:: This operation is valid for **WFS version 2.0.0 only**.
  332. A **ListStoredQueries** operation returns a list of the stored queries currently maintained by the WFS server.
  333. This example lists all stored queries on the server::
  334. http://example.com/geoserver/wfs?
  335. request=ListStoredQueries&
  336. service=wfs&
  337. version=2.0.0
  338. The same example in a POST request:
  339. .. code-block:: xml
  340. <wfs:ListStoredQueries service='WFS'
  341. version='2.0.0'
  342. xmlns:wfs='http://www.opengis.net/wfs/2.0'/>
  343. DescribeStoredQueries
  344. ~~~~~~~~~~~~~~~~~~~~~
  345. .. note:: This operation is valid for **WFS version 2.0.0 only**.
  346. A **DescribeStoredQuery** operation returns detailed metadata about each stored query maintained by the WFS server. A description of an individual query may be requested by providing the ID of the specific query. If no ID is provided, all queries are described.
  347. This example describes the existing stored query with an ID of ``urn:ogc:def:query:OGC-WFS::GetFeatureById``::
  348. http://example.com/geoserver/wfs?
  349. request=DescribeStoredQueries&
  350. storedQuery_Id=urn:ogc:def:query:OGC-WFS::GetFeatureById
  351. The same example in a POST request:
  352. .. code-block:: xml
  353. <wfs:DescribeStoredQueries
  354. xmlns:wfs='http://www.opengis.net/wfs/2.0'
  355. service='WFS'>
  356. <wfs:StoredQueryId>urn:ogc:def:query:OGC-WFS::GetFeatureById</wfs:StoredQueryId>
  357. </wfs:DescribeStoredQueries>
  358. Exceptions
  359. ----------
  360. WFS also supports a number of formats for reporting exceptions. The supported values for exception reporting are:
  361. .. list-table::
  362. :widths: 15 35 50
  363. :header-rows: 1
  364. * - Format
  365. - Syntax
  366. - Description
  367. * - XML
  368. - ``exceptions=text/xml``
  369. - *(default)* XML output
  370. * - JSON
  371. - ``exceptions=application/json``
  372. - Simple JSON
  373. * - JSONP
  374. - ``exceptions=text/javascript``
  375. - Return a JSONP in the form: parseResponse(...jsonp...). See :ref:`wms_vendor_parameters` to change the callback name. Note that this format is disabled by default (See :ref:`wms_global_variables`).