supported-gml-versions.rst 3.6 KB

1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677
  1. .. _app-schema.gml32:
  2. Supported GML Versions
  3. ======================
  4. GML 3.1.1
  5. ---------
  6. * GML 3.1.1 application schemas are supported for WFS 1.1.0.
  7. * Clients must specify WFS 1.1.0 in requests because the GeoServer default is WFS 2.0.0.
  8. * GET URLs must contain ``version=1.1.0`` to set the WFS version to 1.1.0.
  9. GML 3.2.1
  10. ---------
  11. * GML 3.2.1 application schemas are supported for WFS 1.1.0 and (incomplete) WFS 2.0.0.
  12. * Some WFS 2.0.0 features not in WFS 1.1.0 such as GetFeatureById are not yet supported.
  13. * 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.
  14. * 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 and ``outputFormat=gml32`` to set the output format to GML 3.2.1.
  15. * The default WFS version is 2.0.0, for which the default output format is GML 3.2.1.
  16. * 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.0 ``FeatureCollection`` cannot contain GML 3.2.1 features.
  17. Secondary namespace for GML 3.2.1 required
  18. ``````````````````````````````````````````
  19. 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 :ref:`app-schema.secondary-namespaces` for details.
  20. For example, to use the prefix ``gml`` for GML 3.2, create ``workspaces/gml/namespace.xml`` containing::
  21. <namespace>
  22. <id>gml_namespace</id>
  23. <prefix>gml</prefix>
  24. <uri>http://www.opengis.net/gml/3.2</uri>
  25. </namespace>
  26. and ``workspaces/gml/workspace.xml`` containing::
  27. <workspace>
  28. <id>gml_workspace</id>
  29. <name>gml</name>
  30. </workspace>
  31. Failure to define the ``gml`` namespace prefix with a secondary namespace will result in errors like::
  32. java.io.IOException: The prefix "null" for element "null:name" is not bound.
  33. while encoding a response (in this case one containing ``gml:name``), even if the namespace prefix is defined in the mapping file.
  34. GML 3.2.1 geometries require gml:id
  35. ```````````````````````````````````
  36. 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::
  37. <AttributeMapping>
  38. <targetAttribute>gsml:shape</targetAttribute>
  39. <idExpression>
  40. <OCQL>strConcat('shape.', getId())</OCQL>
  41. </idExpression>
  42. <sourceExpression>
  43. <OCQL>SHAPE</OCQL>
  44. </sourceExpression>
  45. </AttributeMapping>
  46. 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."``.
  47. 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.
  48. GML 3.3
  49. -------
  50. 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.