Web Feature Service
The Web Feature Service (WFS) is an interface standard developed by the Open Geospatial Consortium (OGC) that enables direct, fine-grained access to geospatial feature data over the web, allowing clients to discover, query, lock, and transact (create, update, or delete) individual geographic features and their properties.[1] Introduced in 2002 as the OGC's first data access service standard, WFS marked a shift from file-based sharing of geospatial information (such as via FTP) to dynamic, web-based interactions that support the creation, modification, and exchange of vector data like points, lines, and polygons.[2] The standard has evolved through several versions: WFS 1.0.0 (2002), which established basic and transactional modes for feature retrieval and editing; WFS 1.1.0 (2005), which improved interoperability with enhanced support for filtering and coordinate reference systems; and WFS 2.0.0 (2010, aligned with ISO 19142), which introduced stored queries, property value retrieval, and better handling of large datasets via paging.[3][4] At its core, WFS defines 11 key operations, including GetCapabilities for service metadata, DescribeFeatureType for schema details, GetFeature for querying data, Transaction for modifications, and stored query functions for reusable parameterized requests.[1] It relies on Geography Markup Language (GML) for encoding features but supports output in formats like GeoJSON in modern implementations, facilitating integration with GIS software, web mapping applications, and spatial databases. While widely adopted for applications in environmental monitoring, urban planning, and disaster management, WFS is increasingly complemented or replaced by the more RESTful OGC API – Features standard for contemporary web architectures.Introduction
Definition and Purpose
The Web Feature Service (WFS) is an interface standard developed by the Open Geospatial Consortium (OGC) that enables direct, fine-grained access to geospatial vector features—such as points, lines, and polygons—over HTTP, allowing clients to retrieve, query, and update geographic information at the individual feature and property level.[1][5] This standard shifts from traditional file-based sharing methods, like FTP, to a more precise, web-enabled approach for handling spatial data.[5] The primary purpose of WFS is to facilitate interoperability in geographic information system (GIS) applications by permitting clients to request specific features along with their associated attributes and geometries from distributed data stores.[1] It supports both read-only access for discovery and retrieval, as well as transactional capabilities—such as create, update, and delete operations—through the WFS-Transactional (WFS-T) extension, thereby enabling dynamic manipulation of geospatial data in web environments.[5] This design promotes efficient data exchange without requiring the transfer of entire datasets, enhancing usability in collaborative and analytical workflows.[1] Key benefits of WFS include standardized access to spatial data that avoids proprietary formats, thereby reducing integration barriers across diverse systems and tools for web mapping and geospatial analysis.[5] By providing a common protocol for feature-level interactions, it fosters broader adoption of open data sharing practices and supports scalable, client-driven queries that improve performance in resource-constrained settings.[1] Within the broader OGC ecosystem, WFS originated as a foundational element of the service-oriented architecture for geospatial web services, integrating with other standards to enable seamless interoperability in handling vector-based geographic information.[5]Historical Development
The development of the Web Feature Service (WFS) standard originated in the late 1990s within the Open Geospatial Consortium (OGC), as part of broader efforts to standardize web-based geospatial data access beyond traditional file transfers. The OGC Technical Committee, with contributions from industry leaders and academic institutions, drove the initial work to enable direct retrieval and manipulation of geographic features over the internet. This culminated in the adoption of the first specification, WFS 1.0.0, on September 19, 2002, marking OGC's inaugural data access service standard.[2][6] Subsequent major releases advanced the standard's maturity. WFS 1.1.0 was adopted on January 19, 2005, introducing improvements in query capabilities and alignment with evolving geospatial markup languages. The specification reached a significant milestone with WFS 2.0.0, approved on August 4, 2010 and aligned with ISO 19142:2010, which refined support for transactional operations and resource management. Key events during this period included the approval of the GML Simple Features Profile for WFS in 2005, aimed at enhancing interoperability for basic geometry types, and its integration into the OGC Reference Model for broader architectural consistency.[4][5][7] The European Union's INSPIRE Directive, adopted in 2007, further propelled WFS adoption by requiring member states to implement standardized geospatial services, including WFS, for environmental data sharing across borders. Since 2010, updates have been limited to minor errata corrections and specialized profiles, with no major version like WFS 3.0 released; however, by 2025, OGC discussions emphasize transitioning toward RESTful API approaches for enhanced web integration, as explored in engineering reports from the late 2010s.[8]Standards and Specifications
Core Versions and Profiles
The Web Feature Service (WFS) standard has evolved through several core versions, each building on the previous to enhance functionality for accessing and manipulating geospatial features. The initial version, WFS 1.0.0, released in 2002, introduced basic capabilities for discovering, querying, and retrieving geographic features encoded in Geography Markup Language (GML) 2.1.2, supporting operations such as GetCapabilities for service metadata, DescribeFeatureType for schema description, and GetFeature for feature retrieval via HTTP GET and POST requests.[9] This version focused on read-only access in its basic form, with optional extensions for transactions. WFS 1.1.0, published in 2005 as OGC document 04-094r1, expanded on the foundational operations by adding support for XML-based POST requests, advanced spatial operators in queries (e.g., Beyond, DWithin), and integration with the Filter Encoding 1.1 standard for more expressive filtering.[4] It maintained compatibility with GML 3.1 while allowing GML 2.1.2, and introduced versioning negotiation in requests to handle multiple specification versions. Key enhancements included improved handling of coordinate reference systems and partial result support to manage large datasets. The current core version, WFS 2.0.0 (also ISO 19142:2010), finalized in 2010 as OGC document 09-025r1 (with corrigenda in r2), introduced significant advancements such as result paging for efficient handling of large responses, stored queries for predefined reusable queries, and support for multiple application schemas beyond GML, including JSON-like outputs in later extensions.[5] It also added operations like GetFeatureWithLock for concurrent access and enhanced transaction support with versioning and rollback capabilities, while defaulting to GML 3.2 for feature encoding. WFS implementations are categorized by compliance levels to ensure interoperability, with Basic WFS providing read-only query access (GetCapabilities, DescribeFeatureType, GetFeature), and Transactional WFS (WFS-T) extending to full CRUD operations (Create, Update, Delete via Transaction).[10] Additional conformance classes in versions 1.1.0 and 2.0.0 include Locking WFS for feature locking during transactions, Query for advanced filtering, and specialized classes like Simple WFS (core operations without joins) and Standard Join WFS (for relational queries across feature types).[11] These classes are verified through OGC's Compliance Testing Service (CITE), requiring implementations to declare supported classes in the GetCapabilities response. Profiles define constrained subsets of the WFS standard for specific domains, promoting simplified interoperability. The GML Simple Features Profile (OGC 06-049r1, 2006) restricts geometry types to basic elements like Point, LineString, Polygon, and Multi-geometries, using a subset of GML 3.1.1 to reduce complexity for WFS servers and clients handling common vector data.[12] Extensions like WFS-C (Cascading) enable hierarchical service chaining, where one WFS forwards requests to upstream services. WFS can integrate with domain-specific standards like Observations & Measurements (O&M) for handling sensor and spatiotemporal data. Official specification documents include XML schemas for validation: WFS 1.0.0 schemas at http://schemas.opengis.net/wfs/1.0.0/, WFS 1.1.0 at http://schemas.opengis.net/wfs/1.1.0/, and WFS 2.0.0 at http://schemas.opengis.net/wfs/2.0/. Conformance testing is detailed in OGC's executable test suites, such as those for WFS 2.0 covering 11 core operations and various classes.[11] WFS 2.0.0 maintains backward compatibility with 1.x clients through version negotiation in requests, allowing servers to respond in older formats like GML 2.1.2 or 3.1 upon specification, and by preserving core operation semantics where possible, though some changes (e.g., axis order in coordinates) require client awareness.[13]Evolution and Related Standards
Legacy implementations of the Web Feature Service (WFS) faced significant challenges due to their reliance on a remote procedure call (RPC)-over-HTTP architecture with verbose XML payloads, including the mandatory use of Geography Markup Language (GML) for feature encoding, which increased complexity and parsing overhead.[14] This design, originating in the late 1990s and early 2000s, lacked native support for RESTful principles, leading to adoption hurdles in the 2010s as web development shifted toward simpler, resource-oriented APIs.[14][15] By the mid-2010s, these limitations—such as limited format flexibility and higher integration barriers for non-GIS developers—prompted the Open Geospatial Consortium (OGC) to evolve toward more modern standards.[16] The OGC API - Features standard emerged as a direct successor, introducing a multi-part framework to address these gaps while providing RESTful endpoints for accessing, querying, and managing geospatial features.[14] Part 1: Core, published in October 2019, establishes foundational capabilities for retrieving features in WGS 84 coordinates using formats like JSON and GeoJSON.[14] Part 2: Coordinate Reference Systems by Reference, released in November 2020, extends support to arbitrary coordinate reference systems (CRS) via HTTP content negotiation.[17] As of November 2025, the standard continues to advance with Part 4: Create, Replace, Update and Delete (draft, providing transactional operations) and Part 5: Schemas (proposal draft, for describing feature properties and constraints).[18][19] Key differences from legacy WFS include the use of HTTP GET and POST methods with hypermedia-driven responses in HTML or JSON, facilitating discoverability and browser-friendly interactions without requiring specialized clients.[14] OGC API - Features also incorporates OpenAPI specifications for machine-readable API descriptions, enhancing interoperability and tooling support.[14] Backward compatibility is maintained through optional conformance classes, such as the GML Simple Features Profile, allowing gradual migration from WFS.[14] This evolution integrates with related OGC standards like OGC API - Common (Part 1: Core, approved in 2019), which provides shared building blocks for service metadata, including landing pages with titles, descriptions, and conformance declarations accessible at the API root.[20] Additionally, OGC API - Features aligns with W3C standards, such as SPARQL extensions via GeoSPARQL, enabling semantic querying of linked geospatial data in RDF formats.[21][22] As of 2025, WFS 2.0 continues to serve existing deployments effectively, but the OGC actively promotes OGC API - Features for new implementations due to its alignment with contemporary web practices.[23] Adoption has grown in cloud-based GIS platforms, exemplified by ArcGIS Online's support for publishing hosted feature layers as OGC API - Features services, enabling efficient access and integration with web applications.[24]Architecture
Service Components
A Web Feature Service (WFS) server comprises several core internal components that enable the processing and management of geospatial feature requests. The feature store serves as the primary data repository, typically implemented using spatial databases such as PostGIS, which stores vector features with their associated attributes and geometries.[25] This store maintains persistent unique identifiers for features, often encoded asgml:id attributes, and supports versioning to track feature states like valid, superseded, or retired.[5] The schema repository complements the feature store by holding definitions of feature types, including their properties and structures, which are derived from application schemas based on the Geography Markup Language (GML) standard (ISO 19136:2007).[5][26]
The query engine is a critical server-side element responsible for executing spatial and attribute queries against the feature store. It leverages spatial indexing techniques, such as R-trees implemented via Generalized Search Trees (GiST) in databases like PostGIS, to efficiently retrieve features based on bounding boxes or other geometric constraints.[27] This engine processes query expressions, including ad hoc queries and stored queries, relying on the OGC Filter Encoding (FE) 2.0 standard (OGC 09-026r2) for defining selection predicates, sorting, and joins.[5][28]
Server architecture includes modules for request handling and response generation. The request parser interprets incoming requests encoded in XML or key-value pairs (KVP), validating parameters such as service version, operation type, and namespaces to ensure conformance.[5] An authentication module enforces security, advertising supported methods (e.g., HTTP Basic or TLS client certificates) via constraints in the service's Capabilities document, as defined in the OGC Web Services Security standard.[29] The response encoder formats query results, defaulting to GML 3.2 (application/gml+xml; version=3.2) while supporting additional output formats if declared in the service metadata.[5]
WFS implementations incorporate scalability features to manage high-volume requests. Caching mechanisms allow servers to store intermediate query results, with optional timeouts advertised via the ResponseCacheTimeout parameter to control cache validity.[5] Result paging, enabled through count and startIndex parameters, facilitates handling large datasets by dividing responses into manageable subsets.[5] Load balancing can be achieved in distributed deployments, such as those using Kubernetes, to distribute processing across multiple server instances.
Error handling follows standardized protocols to report issues during request processing. Servers generate exception reports in XML format using the ows:ExceptionReport element, including codes such as OperationParsingFailed for malformed requests or InvalidParameterValue for incorrect parameters, ensuring interoperability in fault scenarios.[5]
Communication Models
The Web Feature Service (WFS) primarily employs a stateless request/response communication model over HTTP, where clients issue synchronous requests and servers provide immediate replies without maintaining session state across interactions.[5] This model ensures independence of each request, facilitating scalable and reliable client-server exchanges in distributed geospatial environments.[5] For instance, a client sends a query via HTTP, and the server responds with the requested feature data, typically encoded in XML formats like Geography Markup Language (GML).[5] Asynchronous interactions can be supported by integrating WFS with the publish/subscribe (Pub/Sub) model using the OGC Publish/Subscribe 1.0 Standard, building on earlier concepts like the Web Notification Service (WNS).[30] In such approaches, explored in OGC testbeds, clients subscribe to events such as feature modifications or insertions, enabling servers to push notifications upon changes without repeated polling. Services like WNS can act as a broker for these subscriptions, handling one-way notifications for updates like real-time feature alterations in sensor networks or aviation data scenarios.[30][31] This complements the synchronous model by reducing latency in dynamic environments, with subscribers specifying filters based on WFS query patterns to receive targeted FeatureCollection payloads.[31] Protocol bindings for WFS communications default to HTTP 1.1, supporting both GET with key-value pair (KVP) encoding for simple queries and POST with XML payloads for complex operations.[5] SOAP over HTTP POST is an optional binding, particularly emphasized in WFS 1.x versions for interoperability with broader web service ecosystems, though it remains viable in later iterations.[5] In modern implementations, the OGC API - Features adopts a RESTful binding over HTTP, leveraging resource-oriented URLs and standard methods like GET for stateless resource access, enhancing compatibility with web-centric architectures.[14] Security in WFS communications relies on HTTP-level mechanisms, including basic authentication for access control and OAuth for authorizing transactional interactions, though the core specification leaves detailed policies to implementations.[29] While no comprehensive encryption is mandated, the standard recommends HTTPS to protect data in transit, ensuring confidentiality for sensitive geospatial exchanges.[29] This approach aligns with broader OGC web service guidelines, allowing secure bindings without altering the underlying request/response semantics.[14] Performance optimizations in WFS include configurable request timeouts, such as the ResolveTimeout parameter (indefinite if not specified) for resource resolution, preventing indefinite hangs during processing.[5] Result compression via GZIP is supported at the HTTP level to reduce bandwidth usage for large feature responses, with clients able to request it explicitly for efficient data transfer in high-volume scenarios.[32] These features, combined with the stateless design, enable robust handling of geospatial workloads while minimizing overhead.[14]Data Handling
Feature Representation
In the Web Feature Service (WFS) standard, geospatial features are modeled as instances of predefined feature types, each comprising a geometry component representing spatial location and a set of properties capturing descriptive attributes. This abstract model aligns with the conceptual framework of geographic features in ISO 19110, where features serve as the primary abstractions for real-world entities with associated spatial and thematic information.[5] Geometries adhere to the spatial schema defined in ISO 19107, supporting types such as Point, LineString, and Polygon as specified in the Simple Features profile of ISO 19125-1, enabling representation of discrete locations, linear paths, and areal extents.[33] The schema for feature types is defined abstractly in XML, outlining the structure of each type including its properties, their data types, and cardinality. This schema incorporates a bounding box, or envelope, which delineates the minimum and maximum coordinates encompassing all instances of the feature type, facilitating spatial indexing and query optimization. Additionally, the schema specifies the spatial reference system (SRS) using identifiers like EPSG codes, ensuring that geometries are positioned within a consistent coordinate framework for interoperability across diverse datasets.[5] WFS supports hierarchical feature structures through complex feature types, which allow nested elements where properties can themselves be complex objects containing sub-properties or further geometries. This enables modeling of relationships, such as associations between feature types (e.g., a building feature linked to address details), promoting the representation of multifaceted geographic phenomena without flattening into simple attribute-value pairs. Such hierarchies draw from the object-oriented concepts in ISO 19109, allowing for inheritance and composition in feature type definitions.[5] Query constraints in the feature model provide mechanisms to filter features based on spatial, attribute, and temporal criteria, enabling precise retrieval without full dataset transfer. Spatial constraints include bounding box (BBOX) for envelope-based selection and intersects for overlap detection with a provided geometry, both leveraging the ISO 19107 spatial operations. Attribute constraints use property filters to match specific values or ranges, such as equality or greater-than comparisons on thematic properties. Temporal constraints support time-based filtering, like during or before operators on date-time properties, to handle dynamic or time-stamped features. These constraints are expressed abstractly to ensure service-agnostic querying.[5][33] The WFS feature model distinguishes between simple and complex abstraction levels to accommodate varying data complexity. Simple features consist of a single geometry and flat properties, suitable for straightforward vector data like points of interest, aligning with the basic conformance class in the specification. Complex features extend this with nested structures and multiple geometries per instance, supporting advanced scenarios such as topographic networks or urban models, while maintaining adherence to ISO 19107 for geometric integrity across both levels.[5][33]Supported Data Formats
The primary data format for encoding features in Web Feature Service (WFS) requests and responses is the Geography Markup Language (GML), an XML-based standard for representing geospatial features. In WFS 1.0.0, features must be encoded using GML 2.1.2, while WFS 1.1.0 defaults to GML 3.1.1 with support for GML 2.1.2 for backward compatibility. Subsequent versions, including WFS 2.0.0, mandate GML 3.2.1 (per ISO 19136:2007) as the default, with the output format specified asapplication/gml+xml; version=3.2. Features are structured within a <wfs:FeatureCollection> root element, containing one or more <gml:featureMember> elements that encapsulate individual feature instances, including geometries, properties, and identifiers via the gml:id attribute.[4][5]
Alternative formats extend beyond GML to support diverse client needs, negotiated via the outputFormat parameter in requests or HTTP content negotiation in later versions. Servers advertise supported formats in the capabilities document, allowing clients to request alternatives such as XML subsets tailored to specific feature types. For visualization purposes, Keyhole Markup Language (KML) may be supported as an output option in some implementations, though it is not mandatory. In the successor standard OGC API - Features (Part 1: Core), GeoJSON emerges as a recommended primary format with the media type application/geo+json, offering a lightweight JSON-based alternative to GML for feature collections, while retaining optional GML support via profiles like Simple Features Level 0 (application/gml+xml; version=3.2; profile=http://www.opengis.net/def/profile/ogc/2.0/gml-sf0).[5][14][34]
Input formats for WFS requests, particularly POST operations, rely on XML encodings, with GML used to represent feature data in transactions like inserts or updates. The default input format mirrors the output, such as application/gml+xml; version=3.2 for WFS 2.0.0, and servers may advertise additional options in capabilities. Query predicates are encoded using the Filter Encoding Standard (FES), which integrates with XML requests to specify spatial and attribute filters; for example, FES 2.0 (OGC 12-077r1) is required for WFS 2.0.0, enabling elements like <fes:Within> with embedded GML geometries.[5]
WFS 2.0.0 introduces version-specific enhancements for format handling, including support for multiple schemas per response, allowing feature types from different namespaces to be queried and returned together, with schemas referenced via the DescribeFeatureType operation. Backward compatibility with legacy GML versions (e.g., 3.1.1 or 2.1.2) is maintained if advertised, ensuring interoperability with older clients without requiring full schema upgrades. In OGC API - Features, negotiation shifts to HTTP Accept headers for media types like GeoJSON or GML profiles.[5][14]
A key limitation of GML is its verbosity due to XML tagging, which can result in large payloads that strain bandwidth and processing, particularly for complex features or high-volume queries. To mitigate this, OGC recommends compression techniques such as GZIP for general HTTP transfers and Efficient XML Interchange (EXI) for schema-informed GML encoding, which can reduce payload sizes by up to 20% compared to GZIP alone when schemas are available; these are negotiated via the Accept-Encoding header or extended outputFormat parameters. Servers should restrict to GML 3.x with explicit 'float' data types in schemas for optimal compression efficacy.[14][35]
Operations
Basic Query Operations
The basic query operations in the Web Feature Service (WFS) standard provide read-only mechanisms for discovering service capabilities, retrieving feature schemas, and querying feature instances without modifying the underlying data. These operations form the foundation of WFS interactions, enabling clients to explore available resources and fetch geospatial features based on spatial, attribute, or logical constraints. Defined in the Open Geospatial Consortium (OGC) specifications, the core operations—GetCapabilities, DescribeFeatureType, and GetFeature—support both Key-Value Pair (KVP) and XML POST encodings, with responses typically in XML formats such as GML.[5][4] The GetCapabilities operation serves as the entry point for service discovery, returning an XML document that describes the server's supported versions, operations, feature types, spatial reference systems (SRS), and other metadata. Mandatory parameters includeservice=WFS and request=GetCapabilities, while optional parameters such as version (e.g., 2.0.2), AcceptVersions, Sections, and UpdateSequence allow clients to specify preferences or retrieve updates. The response, formatted as wfs:WFS_Capabilities, includes sections on service identification, provider details, operation metadata (e.g., supported bindings like KVP or SOAP), a FeatureTypeList enumerating available feature types with their bounding boxes and output formats, and filter capabilities. This operation is mandatory for all WFS implementations and helps clients determine compatibility before issuing further requests. For example, a KVP request might appear as: http://example.com/wfs?SERVICE=WFS&VERSION=2.0.2&REQUEST=GetCapabilities. In WFS 1.1.0, the response structure is similar but uses GML 3.1.1 by default and lacks some 2.0-specific conformance class advertisements.[5][4]
DescribeFeatureType retrieves the application schema for one or more specific feature types, enabling clients to understand the structure of features, including elements, attributes, and geometry types, for validation or rendering purposes. Required parameters are service=WFS, request=DescribeFeatureType, and version, with optional parameters like typeNames (a comma-separated list of qualified feature type names, e.g., myns:Roads) and outputFormat (defaulting to application/gml+xml; version=3.2 in WFS 2.0). The response is an XML Schema document (XSD) that defines the feature type's properties, inheritance, and geometry bindings, often incorporating GML schemas for geospatial elements. If no typeNames is specified, the operation may return schemas for all feature types, though servers can limit this to avoid overload. Exceptions such as InvalidParameterValue are raised for malformed requests. In WFS 1.1.0, the default output format is text/xml; subtype=gml/3.1.1, and the parameter is typeName (singular). An example KVP request is: http://example.com/wfs?SERVICE=WFS&VERSION=2.0.2&REQUEST=DescribeFeatureType&TYPENAMES=myns:Roads.[5][4]
The GetFeature operation is the primary query mechanism, allowing retrieval of feature instances or subsets based on client-defined constraints, with support for spatial and attribute filtering via the Filter Encoding Specification (FES). Mandatory parameters include service=WFS, request=GetFeature, version, and typeNames (specifying the target feature types, e.g., sf:PrimitiveGeoFeature), while optional parameters encompass outputFormat (default GML), count (maximum features to return), startIndex (zero-based offset for paging, default 0), resultType (either results for full features or hits for a count only), bbox (spatial bounding box filter), featureVersion (specific instance version), srsName (output coordinate reference system), propertyName (subset of properties to include), and sortBy (comma-separated sort expressions with ascending/descending order). Filters are expressed using FES, supporting spatial operators (e.g., BBOX, Intersects, Within), comparison operators (e.g., PropertyIsEqualTo, PropertyIsGreaterThan), logical operators (And, Or, Not), and resource identifiers (ResourceId). The response is a wfs:FeatureCollection XML document containing matched features, with attributes numberMatched (total hits) and numberReturned (actual count), or just the hit count for resultType=hits. In WFS 2.0, additional features include resolveStoredQueries for executing predefined parameterized queries (e.g., via STOREDQUERY_ID like http://www.opengis.net/def/query/OGC-WFS/0/GetFeatureById with an ID parameter) and enhanced join support across multiple feature types using FES predicates. Paging is facilitated by combining count and startIndex for efficient large-result handling, while sortBy enables ordered retrieval (e.g., sortBy=priority DESC, name ASC). In contrast, WFS 1.1.0 uses maxFeatures instead of count, lacks native startIndex (relying on server-specific extensions for paging), and employs the earlier Filter Encoding 1.1 with parameters like FILTER (XML-encoded) or FEATUREID. An illustrative KVP example for a bounded query is: http://example.com/wfs?SERVICE=WFS&VERSION=2.0.2&REQUEST=GetFeature&TYPENAMES=roads&BBOX=18.54,-72.3544,18.62,-72.2564&COUNT=10&STARTINDEX=0. These operations ensure interoperable access to vector geospatial data across diverse servers.[5][4][28]
Transactional Operations
The Web Feature Service Transactional (WFS-T) extension enables clients to modify geospatial feature data stored on a server through a standardized interface, supporting the creation, updating, and deletion of features in a controlled manner.[5] This extension builds on the core WFS query capabilities by providing write access, ensuring that modifications are applied atomically to maintain data integrity across potentially multiple feature types within a single request.[5] The transactional model treats the entire set of operations as a unit, where either all changes succeed (commit) or none are applied (rollback) in case of failure, preventing partial updates that could lead to inconsistent states.[5] The core of WFS-T is the Transaction operation, which serves as a single endpoint for executing Insert, Update, and Delete actions via HTTP POST requests, typically encoded in XML.[5] For insertion, clients submit new features using the<wfs:Insert> element, encapsulating them within <gml:featureMember> tags to add them to the server's data store; for example, a request might insert a new water body feature from the InWaterA_1M type by providing its geometry and properties in GML format.[5] Updates modify existing features via <wfs:Update>, specifying the target feature type, a filter (often using <fes:ResourceId> for precise identification), and the properties or geometry to change, such as altering the population attribute of a BuiltUpA_1M feature.[5] Deletions are handled with <wfs:Delete>, targeting features by type and filter, like removing a specific InWaterA_1M instance identified by its resource ID.[5] These operations can be combined in one transaction, processed sequentially, with later actions able to reference prior inserts.[5]
To manage concurrent access and prevent conflicts during modifications, WFS-T includes locking mechanisms. The GetFeatureWithLock operation retrieves features while acquiring an exclusive lock on them, returning a lockId that clients must use in subsequent transactions; this ensures that only the locking client can modify the features until the lock is released.[5] The LockFeature operation allows explicit locking of features based on a query without retrieval, also providing a lockId.[5] Locks are released using the Transaction operation with the releaseAction parameter set to "ALL" (default) or "SOME", specifying the lockId, or automatically upon expiry, safeguarding against indefinite holds.[5]
Key parameters govern these operations for flexibility and control. The InputFormat parameter specifies the encoding of input features, defaulting to "application/gml+xml; version=3.2" for GML compatibility, allowing servers to parse diverse formats if supported.[5] The lockId parameter is required for transactions involving locked features, linking modifications to the appropriate lock.[5] Transaction responses include a summary with counts such as totalInserted, totalUpdated, and totalDeleted, enabling clients to verify the outcomes of their requests.[5]
Constraints ensure robust implementation and interoperability. Atomicity is mandatory, applying across operations on multiple feature types to guarantee consistency even in complex transactions.[5] In WFS 2.0, optional versioning support allows updates to target specific feature versions using the featureVersion parameter, facilitating change tracking in dynamic environments.[5] Servers advertise WFS-T conformance in their capabilities document, indicating support for these features under classes like ImplementsTransactional.[5]
Interfaces
Core Request Interfaces
The core request interfaces of the Web Feature Service (WFS) 2.0 standard provide the foundational mechanisms for clients to discover service capabilities, describe feature types, and retrieve geospatial features via standardized HTTP exchanges. These interfaces are mandatory for compliant implementations and support two primary encoding methods: key-value pairs (KVP) for HTTP GET requests and XML documents for HTTP POST requests. All requests must include theservice parameter set to "WFS" and may specify a version parameter to indicate the desired protocol version, such as "2.0.0" or "2.0.2".[5]
Requests utilize XML namespaces to ensure interoperability, including the OWS Common namespace (ows: http://www.opengis.net/ows/2.0), the WFS namespace (wfs: http://www.opengis.net/wfs/2.0), and the Geography Markup Language namespace (gml: http://www.opengis.net/gml/3.2) for feature encoding. For example, a simple GET request for service capabilities might use the KVP encoding http://example.com/wfs?service=WFS&request=GetCapabilities&version=2.0.0, while the equivalent POST request would be an XML document like <wfs:GetCapabilities service="WFS" version="2.0.0"/>. Successful responses are returned with the Content-Type: application/xml header and an HTTP status code of 200 OK, whereas invalid requests yield a 400 Bad Request status along with an error document.[5][36]
GetCapabilities Operation
The GetCapabilities request allows clients to retrieve metadata about the service, including supported operations, feature types, and output formats. Mandatory parameters includeservice=WFS and request=GetCapabilities; optional parameters encompass version (defaults to the highest supported version by the server), acceptVersions (a comma-separated list of acceptable versions), acceptFormats (MIME types for capabilities documents), and sections (to request specific sections like "All" or "ServiceIdentification"). The response is an XML document rooted in wfs:WFS_Capabilities, featuring elements such as ows:ServiceIdentification (containing service title, abstract, and keywords) and wfs:FeatureTypeList (listing available feature types with their names, titles, and supported spatial reference systems). For instance, a KVP example is service=WFS&request=GetCapabilities&version=2.0.0, yielding a structured XML response that describes the server's conformance classes and operations.[37][37]
DescribeFeatureType Operation
This operation enables clients to obtain the schema definition for one or more feature types, facilitating the construction of subsequent queries. Required parameters areservice=WFS, request=DescribeFeatureType, and typeNames (a comma-separated list of qualified feature type names, e.g., sf:PrimitiveGeoFeature); optional parameters include outputFormat (defaults to application/gml+xml; [version](/page/Version)=3.2) and schemaDescriptionLanguage (for specifying schema languages beyond GML). The response is an XML schema document describing the structure, properties, and geometry types of the requested feature types, often embedded in a wfs:FeatureTypeList or as a standalone XSD. An example KVP request is service=WFS&request=DescribeFeatureType&[version](/page/Version)=2.0.0&typeNames=example:Roads,example:Rivers.[38][38]
ListStoredQueries and DescribeStoredQueries Operations
The ListStoredQueries request retrieves a list of predefined, server-stored queries that clients can invoke without specifying full query expressions. It requiresservice=WFS and request=ListStoredQueries, with optional parameters like returnFeatureTypes (to filter by feature types) and storedQueryId (to match specific IDs). The response is a wfs:ListStoredQueriesResponse XML element containing wfs:StoredQueryDescription entries with id, title, abstract, and ReturnFeatureType details. Complementing this, the DescribeStoredQueries request details the parameters and expressions of specific stored queries, using service=WFS, request=DescribeStoredQueries, and storedQueryId (comma-separated list). Its response is a wfs:DescribeStoredQueriesResponse XML containing wfs:StoredQueryDescription elements with full query metadata, including parameter definitions and the associated query expression. For example, service=WFS&request=ListStoredQueries&[version](/page/Version)=2.0.0 lists available queries.[39][39]
GetFeature and GetPropertyValue Operations
The GetFeature request retrieves feature instances matching specified criteria, supporting operations like those outlined in the basic query section. Key parameters includeservice=WFS, request=GetFeature, typeNames (target feature types), count (maximum features to return), startIndex (for paging), filter (query constraints in XML), and outputFormat (e.g., application/gml+xml; version=3.2). The response is a wfs:FeatureCollection XML document, including numberMatched (total matching features) and numberReturned (features in this response), with totalMatches approximated if the full count is resource-intensive. An example is service=WFS&request=GetFeature&version=2.0.0&typeNames=example:InWaterA_1M. The related GetPropertyValue operation extracts only property values without full features, using parameters like valueReference (XPath to properties) and resolve (for property navigation); its response is a wfs:ValueCollection with requested values and matching counts.[40][41]
Version negotiation occurs through the version parameter in requests; if the client-specified version is unsupported, the server responds with the highest supported version it can use, as defined in the associated OWS Common Implementation Standard. Errors in any request trigger an ows:ExceptionReport XML response, including the version attribute, one or more ows:Exception elements with a code (e.g., InvalidParameterValue, MissingParameterValue, VersionNegotiationFailed) and optional locator (pointing to the erroneous parameter or location). For example, an invalid parameter might yield <ows:ExceptionReport version="2.0.0"><ows:Exception exceptionCode="InvalidParameterValue" locator="typeNames"/></ows:ExceptionReport>.[36][42]
| Core Operation | Mandatory Parameters | Common Optional Parameters | Response Root Element |
|---|---|---|---|
| GetCapabilities | service, request | version, sections, acceptVersions | wfs:WFS_Capabilities |
| DescribeFeatureType | service, request, typeNames | outputFormat | xs:schema |
| ListStoredQueries | service, request | storedQueryId | wfs:ListStoredQueriesResponse |
| DescribeStoredQueries | service, request, storedQueryId | None | wfs:DescribeStoredQueriesResponse |
| GetFeature | service, request | typeNames, count, filter, outputFormat | wfs:FeatureCollection |
| GetPropertyValue | service, request, valueReference | typeNames, count, filter, outputFormat | wfs:ValueCollection |