Common request parameters |
The VERSION parameter specifies the protocol version number. See Version Number .
The REQUEST parameter is used to set what action to invoke for WFS.
The BBOX parameter is a short representation of an ordinary bounding box filter, consisting of four English comma separated decimals, scientific symbols, or certificates. These values represent the specified min X (Xmin), min Y (Ymin), max X (Xmax) and max Y (Ymax) under SRS.
As shown in the following figure:
Bounding box area cannot have an area of 0.
If the request contains an illegal bounding box, for example, min X is greater than max X, or min Y is greater than max Y, the server must return an exception.
If the requested bounding box area does not intersect with the LatLongBoundingBox in the Capabilities XML document, the server will return an empty content (such as an empty feature collection). Any element partially or completely contained within a bounding box should return an appropriate format.
In the request, the coordinate reference system of the bounding box must be the same as the SRS of the feature type. The SRS of element types is recorded in the WFS Capability XML document. If there is more than one element type in the request, all element types must have the same SRS, and BBOX must also have the same SRS as the element type.
If the value of the bounding box is not defined in the given SRS (e.g. latitude greater than 90 degrees in EPSG: 4326), the server should return empty content outside the valid SRS area.
In the special case of longitude, the following method is used when the meridian is 180 degrees in longitude. There are cases where the map crosses the prime meridian (for example, the center of the map is in the Pacific Ocean), which is legal. If the smallest X is the westernmost longitude and Max X is the easternmost longitude, then the following constraints can be applied:
-180 <= Xmin < Xmax < 540
For example, the Xmin, Xmax values and the corresponding bounding box ranges:
-180,180 = the center of the Earth is in Greenwich
0,360 = Greenwich left boundary
0,360 = Pacific
Optional vendor-specific parameters (VSPs) are allowed in the request, which can enhance the response to the request. In particular, they can be used to complete the testing of non-standard functions, which may then become standard. These are not required by the average user VSPs.
The OGC WFS service must generate a valid result when:
when VSPs are missing or constitute an error, the service can provide a default value.
When VSPs are applied without being known by the service, the service may choose to ignore the unknown request parameters.
WFS may choose not to declare some or all of the VSPs. If VSPs are included in Capabilities XML You must redefine the VendorSpecificCapabilities element. Other Schema documents can introduce the redefinition of the containing element.
Clients can read service providers-specific definitions from Capabilities Schema and use VSPs Constitute a request.
The service providers should choose the VSP carefully to avoid conflicts with standard parameters.
The following table lists the common parameters for all WFS requests.
Table 1 Common Parameters for WFS Requests
| URL composition | Whether it is required | Description |
|
http://server_address/path/script |
No |
The URL prefix for the WFS service. |
|
VERSION |
Yes |
Request version number. See Version Number. |
|
SERVICE |
Yes |
Service type The default is "WFS". |
|
REQUEST |
Yes |
Request name. Can be: GetCapabilities, DescribeFeatureType, GetFeature, LockFeature, or Transaction. |
|
Additional parameters |
|
Description ofother parameters. |
|
Vendor-specific parameters |
|
The service providers specific parameter. |