Supported GML Versions¶
GML 3.1.1¶
- GML 3.1.1 application schemas are supported for WFS 1.1.0.
- Clients must specify WFS 1.1.0 in requests because the GeoServer default is WFS 2.0.0.
- GET URLs must contain
version=1.1.0
to set the WFS version to 1.1.0.
GML 3.2.1¶
- GML 3.2.1 application schemas are supported for WFS 1.1.0 and (incomplete) WFS 2.0.0.
- Some WFS 2.0.0 features not in WFS 1.1.0 such as GetFeatureById are not yet supported.
- Clients using WFS 1.1.0 must specify WFS 1.1.0 in requests and select the
gml32
output format for GML 3.2.1. - To use WFS 1.1.0 for GML 3.2.1, GET URLs must contain
version=1.1.0
to set the WFS version to 1.1.0 andoutputFormat=gml32
to set the output format to GML 3.2.1. - The default WFS version is 2.0.0, for which the default output format is GML 3.2.1.
- All GML 3.2.1 responses are contained in a WFS 2.0.0
FeatureCollection
element, even for WFS 1.1.0 requests, because a WFS 1.1.0FeatureCollection
cannot contain GML 3.2.1 features.
Secondary namespace for GML 3.2.1 required¶
GML 3.2.1 WFS responses are delivered in a WFS 2.0.0 FeatureCollection
. Unlike WFS 1.1.0, WFS 2.0.0 does not depend explicitly on any GML version. As a consequence, the GML namespace is secondary and must be defined explicitly as a secondary namespace. See Secondary Namespaces for details.
For example, to use the prefix gml
for GML 3.2, create workspaces/gml/namespace.xml
containing:
<namespace>
<id>gml_namespace</id>
<prefix>gml</prefix>
<uri>http://www.opengis.net/gml/3.2</uri>
</namespace>
and workspaces/gml/workspace.xml
containing:
<workspace>
<id>gml_workspace</id>
<name>gml</name>
</workspace>
Failure to define the gml
namespace prefix with a secondary namespace will result in errors like:
java.io.IOException: The prefix "null" for element "null:name" is not bound.
while encoding a response (in this case one containing gml:name
), even if the namespace prefix is defined in the mapping file.
GML 3.2.1 geometries require gml:id¶
GML 3.2.1 requires that all geometries have a gml:id
. While GeoServer will happily encode WFS responses without gml:id
on geometries, these will be schema-invalid. Encoding a gml:id
on a geometry can be achieved by setting an idExpression
in the mapping for the geometry property. For example, gsml:shape
is a geometry property and its gml:id
might be generated with:
<AttributeMapping>
<targetAttribute>gsml:shape</targetAttribute>
<idExpression>
<OCQL>strConcat('shape.', getId())</OCQL>
</idExpression>
<sourceExpression>
<OCQL>SHAPE</OCQL>
</sourceExpression>
</AttributeMapping>
In this example, getId()
returns the gml:id
of the containing feature, so each geometry will have a unique gml:id
formed by appending the gml:id
of the containing feature to the string "shape."
.
If a multigeometry (such as a MultiPoint
or MultiSurface
) is assigned a gml:id
of (for example) parentid
, to permit GML 3.2.1 schema-validity, each geometry that the multigeometry contains will be automatically assigned a gml:id
of the form parentid.1
, parentid.2
, ... in order.
GML 3.3¶
The proposed GML 3.3 is itself a GML 3.2.1 application schema; preliminary testing with drafts of GML 3.3 indicates that it works with app-schema as expected.