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 request contains a bounding box region that does not intersect with the bounding box declared in the Capabilities XML document, the server returns an empty content (for example, an empty feature collection). Any element that is partially or completely contained in a bounding box should be returned in an appropriate format.
In the request, the coordinate reference system of the bounding box must be the same as the SRS for the feature type. SRS records for element types are available in the WFS Capabilities XML document. If there is more than one feature type in the request, all feature types must have the same SRS, and the BBOX must have the same SRS。
If the value of the bounding box is not defined in a given SRS (for example, a latitude greater than 90 degrees in EPSG: 4326), the server should return a value that is valid in the Empty content outside the 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, and their use 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 incorrect, 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 The Extended Capabilities element should be extended accordingly. Other Schemas that contain Extended Capabilities extension elements The document can be imported into the Capabilities XML document.
Clients can read service providers-specific definitions from Capabilities Schema and use VSPs Constitute a request.
WFS implementers should be careful when choosing names for VSPs so that they do not conflict with the WFS parameters defined in international standards.
The following table lists the common parameters for all WFS 2.0.0 requests.
Table 1 Common Parameters for WFS 2.0.0 Requests
| URL composition | Whether it is required | Description |
|
VERSION |
Yes |
Request version number. This parameter is required for all operations except the Get Capabilities operation. See Version Number . |
|
SERVICE |
Yes |
service type Request the WFS 2.0.0 service with a value of "WFS". |
|
REQUEST |
Yes |
Request name Request the WFS 2.0.0 service, Values can be GetCapabilities, DescribeFeatureType, GetPropertyValue, GetFeature, ListStoredQueries, DescribeStoredQueries, Or Transaction. |
|
HANDLE |
No |
Handle parameter. KVP encoding is not supported and is used to associate an element with its mnemonic name. |