This section analyses the use cases documented in the previous chapter and identifies the requirements that would require more complex interactions than those supported by the current draft of WFS 3.0, Part 1 (Core).
Requirements that are supported by design by all implementations of WFS 3.0 Core are not discussed.
We split the analysis between requirements related to the data structures used in the data, the requirements related to querying such data and requirements for other approaches to organizing the data.
In terms of encodings, this analysis documents the support for the requirements in the feature encodings supported by WFS 3.0 Core, i.e. GeoJSON and the GML Simple Feature Profile. Requirements related to a Hypertext Markup Language (HTML) representation of features or collections of them are not discussed.
|
Note
|
The identified requirements are based on the use cases documented in the previous chapter and the requirements for this study. They are not intended to exhaustively cover all potential use cases related to handling complex features. However, if there are other requirements related to complex feature handling that should be considered in this report, maybe we can still add them here, if these are relevant for the recommendations and we can reference a source for the requirement. |
- Requirement "multiple-values"
-
Support for properties with multiple values.
In an application schema, the property has a maximum multiplicity greater than "1".
WFS 3.0 Core and the GeoJSON and GML Simple Feature Profile Level 2 conformance classes already support this requirement.
GeoJSON does not place any restrictions on the contents of properties, i.e.,
the natural approach to encoding such properties in GeoJSON would be a JSON
array.
GML Simple Feature Level 2 is similar as it only constrains the spatial geometries used, but has no constraints on the other feature properties. In GML, multiple values are represented by repeated property elements.
- Requirement "nested-structures"
-
Support for properties with structured values.
In an application schema, the property has value type that is neither a geometry, another feature nor a literal value (like Integer or CharacterString).
Again, WFS 3.0 Core and the GeoJSON / GML Simple Feature Profile Level 2 conformance classes already support this requirement.
In GeoJSON, the natural approach is to represent such values as a JSON object.
In GML, the value of the property is an object element representing an instance of the data type.
For example, the following XML shows a GML feature with a property property that
has two values, each a data type with two properties (sub-property1 and
sub-property2). The other properties are suppressed:
<Feature gml:id="f1">
...
<property>
<DataType>
<sub-property1>value1</sub-property1>
<sub-property2>value2</sub-property2>
</DataType>
</property>
<property>
<DataType>
<sub-property1>value3</sub-property1>
<sub-property2>value4</sub-property2>
</DataType>
</property>
...
</Feature>The GeoJSON representation would be:
{
"type": "Feature",
"id": "f1",
"geometry": { ... },
"properties": {
...,
"property": [
{
"sub-property1": "value1",
"sub-property2": "value2"
},
{
"sub-property1": "value3",
"sub-property2": "value4"
}
],
...
}
}Even though GeoJSON and GML support such complex data structures, software tools are sometimes limited to simple values only. In that case, the data structures would have to be flattened. The following GeoJSON snippet is a flattened version of the GeoJSON feature above.
{
"type": "Feature",
"id": "f1",
"geometry": { ... },
"properties": {
...,
"property-1.sub-property1": "value1",
"property-1.sub-property2": "value2",
"property-2.sub-property1": "value3",
"property-2.sub-property2": "value4",
...
}
}If application schemas according to ISO 19109 are used, the ShapeChange cite:[ShapeChange] can help to create flattened implementation schemas, i.e. where all feature properties have a literal value. ShapeChange is a Java tool that takes application schemas constructed according to ISO 19109 from a UML model and derives implementation representations.
- Requirement "relationships"
-
Support for properties where the value is a link to another resource, identified by a URI.
In an application schema, the property is typically a relationship role - or in some cases an application-schema-specific link data type (External references in the German cadastre application schema or in CityGML that have a URI as a value are such data types).
The GML encoding in a WFS 3.0 Core supports such properties already using Xlink references (again, only in Simple Feature Profile Level 2, not in Level 0).
GeoJSON has no concept of links, but specifies extension points and no constraints on the content of "properties". The links could thus be implemented in multiple ways:
-
Inside the additional "links" JSON array that WFS 3.0 already uses to include links to alternate representations, etc.
-
Inside the "properties" JSON array as string-valued properties where each relationship is a URI and the property name represents the relation type.
-
Similar to the previous option, but using the link data type from WFS 3.0 Core as the value.
Spatial relationships between features are a somewhat special case as they can be derived by spatial analysis (see the discussion in the use cases and the W3C/OGC Spatial Data on the Web Best Practice document), but they can use the same pattern in an encoding.
The W3C/OGC Spatial Data on the Web Working Group discussed whether the most commonly used spatial relation types should be registered with Internet Assigned Numbers Authority (IANA), but eventually deferred this. Note that schema.org now has a pending change to support them.
WFS 3.0 supports 3D coordinates but not 3D solids. WFS 3.0 Core is therefore currently limited to 2D geometries in a 2D or 3D coordinate reference system (elevation values may be included for each position). All curves and surface boundaries are restricted to linear interpolation (plus circular arc interpolation in the GML Simple Feature conformance classes). This is not sufficient for the use cases identified in the previous chapter.
- Requirement "multiple-geometries"
-
Support for multiple geometry properties per feature.
An example are geometries at different map scales / levels of details.
|
Note
|
For cases where a feature has multiple spatial properties, WFS 3.0 Core specifies that it is the decision of the server whether only a single spatial geometry property is used to determine the extent or all relevant geometries. |
GML, including the Simple Feature Profiles Levels 0 and 2, supports this, but GeoJSON does not.
That is, in cases where this capability is important, another JSON encoding has to be used or the features have to be split so that there is one feature per spatial geometry property.
Another option could be to include additional geometries inside the "properties" JSON array, but GeoJSON-aware software would not identify these values as geometries. Such an option should, therefore, not be considered.
- Requirement "3D-geometries"
-
Support for 3D coordinate reference systems and solid geometries.
This is fully supported by GML, but not the GML Simple Feature Profiles or GeoJSON as both encodings do not support solids. That is, none of the conformance classes in WFS 3.0 Core is able to support this requirement.
Again, this is supported by GML, but neither by the GML Simple Feature Profiles nor by GeoJSON.
- Requirement "non-linear-interpolation"
-
Support for using arcs, splines or other interpolation of curves or surface boundaries.
Again, this is supported by GML, but neither by the GML Simple Feature Profiles (with the exception of arcs) nor by GeoJSON.
- Requirement "schema-validation"
-
Support for validating features and feature collections against a schema.
Typical examples are validation against an XML Schema or a JSON Schema.
The current draft of WFS 3.0 Core includes - as a stopgap - a recommendation to
include relationships to the schema documents. Another option would be /schema
paths.
The OpenAPI Initiative is discussing more robust support ("alternative schemas") for this requirement in the OpenAPI specification. OGC should wait for the resolution of this development before looking for other solutions.
As the use cases have shown, support for richer data structures is not only required for representing the features in JSON or XML, but these data structures have to be accessible in queries, too.
- Requirement "query-properties-with-multiple-values"
-
The capability to specify whether a predicate on a feature property must be met by all values for a feature or by at least one.
In FES 2.0 this is supported by the matchAction parameter.
- Requirement "query-nested-properties"
-
The capability to specify predicates on properties of a nested data type or a related feature. The "nesting" may be multiple levels.
In WFS 2.0 and FES 2.0 this is supported by the use of XPath expressions in value references, including for cases that require the traversal of a link to a related feature.
If the data includes explicit spatial relationships, these may be used for filtering, too.
- Requirement "query-logical-operators"
-
The capability to specify query expressions built from complex predicates consisting of predicate groups and combinations of logical operators.
This requires support for grouping as well as the standard logical operators specified in FES 2.0.
WFS 3.0 Core only requires support for spatial queries using 2D bounding boxes.
- Requirement "query-2D-geometries"
-
The capability to filter features based on their relationship to a point, curve or surface geometry in a 2D coordinate reference system.
Intersects is the most important relation, but in general the full set of
standard operators
should be supported.
- Requirement "query-buffers"
-
The capability to filter based on a geometry created from an existing geometry by buffering it.
DWithin and Beyond are the
standard operators
in FES 2.0.
- Requirement "query-3D-geometries"
-
The capability to filter features in 3D coordinate reference systems and using solid geometries.
Using the time parameter, WFS 3.0 Core already supports access to features at
a certain moment or period in time, but currently the default is always
"no temporal filter".
For datasets where the features are versions of a real-world entity, valid for a given time period, the default response would return all versions. It would be more helpful, to change the default behavior for such datasets.
- Requirement "query-current-data"
-
The capability to select by default only features that are valid "now" (for datasets where the features are versions of a real-world entity, valid for a given time period).
This has two aspects: being able to specify a different default value for time
("now" instead of "no filter") and to be able to explicitly state values for
the indefinite past and future. The latter issue is already
under discussion
by the WFS 3.0 community.
If a time period is used in time the response for such datasets could include
multiple versions of the same real-world entity.
This is a requirement that would need to be supported in the Core.
Some of the use cases benefit from post-processing the feature or feature collection that has been selected.
In some use cases this will avoid repeated, additional requests to the server to access the related features as their information is needed by the client application.
The related feature may either be embedded inside the property representing the relationship or - in particular where that relationship is always represented by a hyperlink - elsewhere in the document, referenced by a local link.
WFS 2.0 supports this capability using a set of resolve parameters.
- Requirement "return-subset"
-
Support for returning only a subset of a feature properties.
This could be any combination, for example (links go to existing discussion in the WFS 3.0 development):
-
or any subset of the feature properties, including a single property.
WFS 2.0 supports this capability using a so-called projection clauses as well as using the GetPropertyValue operation.
WFS 3.0 Core only supports queries on a single feature collection (feature type
in WFS 2.0, layers in WMS/WMTS). In practice, it is often useful to query features
from multiple collections at once, even if the query is restricted to simple
filtering, e.g. bbox or time.
- Requirement "query-multiple-collections"
-
The capability to select by default features from multiple collections in the dataset in a single request.
WFS 3.0 Core specifies the path /collections/{collectionId}/items to provide
access to features on a by-feature basis.
For visualizing data in a map/scene viewer in a web browser, other approaches to organizing the feature data and other encodings are often better suited for the task.
- Requirement "query-additional-resource-types"
-
The capability to make feature data, including complex data, available in bundles that are optimized for specific applications, for example, for streaming and visualization in a web browser.
The key example in the context of our use cases is the partitioning of space (2D or 3D). Typically, partitions are organized in some hierarchical order to support display of the features in each partition at different levels of detail (or "zoom level" in a 2D map view).
API extensions that support this requirement are likely not to be "WFS 3.0 extensions" as they are not about features as the main resources.
They would be API building blocks for other resource types, outside of the WFS 3.0 series, but based on a common API approach and a NextGen service architecture.
- Requirement "query-additional-encodings"
-
The capability to make the data available in additional encodings.
Support for this is straightforward in the WFS 3.0 architecture (due to the use of HTTP and the architecture of the Web). Each encoding needs a media type, which should be registered with IANA.