GML Implementation of Features and Properties

Contents

Related pages



Overview

Geography Markup Language (GML) (also known as ISO 19136) is a set of encoding patterns and utility components to be used in the definition of an XML document format for feature types, for an application domain. GML is provided as an XML Schema that is intended to be imported into an application schema implementation.

Note: GML cannot be used "out of the box" - it is a framework for the development of an application language.

Note: the purpose of GML-encoding is to transfer data for re-use. Cartographic portrayal requires additional styling.
GML supplies standard components for geometry, coordinate reference systems, time, measures and some other cross-domain elements. The GML specification also includes rules for construction of the application schema by extending certain base classes, in particular gml:AbstractFeatureType. The patterns and rules are discussed here: GmlImplementation.

The OGC Web Feature Service is the primary fine-grained GML data access interface.

A Wikipedia page provides links to a number of GML Application Schemas.

GML is information, not presentation

GML is not a presentation format. GML is used to serialise data, not maps.

GML is XML, which is a text format, and thus may be inspected directly. Note, however, this is primarily of use when debugging software. General users (particularly project managers!) should not look at the XML.

A user-friendly visualisation of data transported in GML requires an additional transformation or portrayal step, to convert it into (for example) HTML or PDF or JPG or KML or another convenient format. Since GML is XML, standard processing tools are available, such as using XSLT for transformations.

The corresponding UML class diagram provides a user-friendly visualisation of the information model .

GML implementation pattern

The rules for implementation of feature-types in GML are described in Annex E of ISO 19136:2007 (also known as GML 3.2.1). These provide a very regular pattern in instances of feature types modeled following the ISO UML profile.

Detailed illustrations of the XML Schema implementation of the patterns are provided by the UmlGmlTestModels.

Example

Consider this extract from the GeoSciML Borehole model, which is described further in FeatureModel#Formalizing_a_feature_type:
GFMBorehole.png

Encoded following the GML rules, an XML instance of the GeoSciML Borehole might look like this:

    <gsml:Borehole gml:id="gcDD0214">
      <gml:name codeSpace="urn:cgi:authority:CGI:GSV">gcDD0214</gml:name>
      <sa:length uom="m">48.3</sa:length>
      <sa:shape>
        <gml:LineString gml:id="gcDD0214survey">
           ...
        </gml:LineString>
      </sa:shape>
      <gsml:collarLocation>
        <gsml:BoreholeCollar gml:id="gcDD0214c">
          <gsml:location>
            <gml:Point gml:id="gcDD0214p">
              <gml:pos srsName="urn:ogc:crs:EPSG:4326">-31.939 115.832</gml:pos>
            </gml:Point>
          </gsml:location>
        </gsml:BoreholeCollar>
      </gsml:collarLocation>
      <gsml:indexData>
         <gsml:BoreholeDetails> ... </gsml:BoreholeDetails>
      </gsml:indexData>
      ...
   </gsml:Borehole>

Explanation

The data model is explicitly shown by the markup in the data instance. Thus, it is not necessary to inspect a schema to see the basic data model (though not including substitutability).

Each feature instance is represented by an XML element. The name of the XML element indicates the Feature-type, and is conventionally given in UpperCamelCase such as gsml:BoreHole.

Each element in the content represents one property of the Feature, and is conventionally given in lowerCamelCase such as sa:shape or gml:name. i.e. Both Features and Properties are realised as XML elements. The name of the respective XML element indicates the feature-type and property semantics.

There are elements from three XML namespaces in this example:
  1. generic geometry from GML using the prefix gml
  2. elements which apply to all sampling curves from the Sampling Features schema using the prefix sa
  3. elements for boreholes from the GeoSciML schema using the prefix gsml.

See InteroperabilityConsiderations for more discussion on mapping from XML/GML to traditional schema notations (e.g. table schemas).

Implementation of properties

Property names and property values

Each property of a Feature is represented as an XML element in the content of the Feature that it belongs to. The name of the XML element for a property indicates the property-type, and is given in lowerCamelCase such as sa:length or gsml:collarLocation. The content of this XML element provides the value of the property. The value may itself be structured using XML elements, and may be another Feature.

The example above has five properties with values as follows:

  1. a name with the value "gcDD0214"
  2. a length with the value being a scaled number
  3. its shape with the value being a gml:LineString (which is substitutable for Curve)
  4. its collarLocation with the value being a BoreholeCollar which is another feature
  5. the indexData, packaged in a data structure called BoreholeDetails

Implementing properties by-reference

As an alternative to values nested in-line, links to other resources may be used. GML uses xlinks on the property element for linking, so the same example could be expressed:

    <gsml:Borehole gml:id="gcDD0214">
      <gml:name codeSpace="urn:cgi:authority:CGI:GSV">gcDD0214</gml:name>
      <gsml:length uom="m">48.3</gsml:length>
      <gsml:shape xlink:href="#gcDD0214survey"/>
      <gsml:collarLocation xlink:href="http://wfs.example.org/collars?gcDD0214c"/>
      <gsml:indexData>
         <gsml:BoreholeDetails> ... </gsml:BoreholeDetails>
      </gsml:indexData>
      ...
   </gsml:Borehole>

  1. the target of the link on the shape identifies an XML fragment denoted "gcDD0214survey" in the same context (document) as the reference.
  2. the target of the link on the collarLocation identifies a resource available from the service called http://wfs.example.org/collars.

Note
  1. the role of the gml:id in creating an identifier for a document fragment, which allows a node corresponding to GML Features or GML Objects to be referred to easily - it is functionally equivalent to a "primary key", and
  2. the role of xlink:href in allowing nodes corresponding to GML properties to carry the reference - it is functionally equivalent to a "foreign key".
See LabelsAndHandles for more discussion.

XML Schema details

GML applications are formalized using the W3C XML Schema language, which may be used to validate data instances. The standard implementation of a feature type uses the following pattern:

  1. A named XML Schema type (e.g. SamplingCurveType) is defined, and
    • used as the content-model in the declaration of a global XML element to be used for instances of the feature-type
    • used as the parent type in the definition of an XML Schema type representing the content model of a more specialized feature-type
  2. A global element (e.g. SamplingCurve) is declared, which
    • is used to instantiate instances of this feature type.
  3. A named XML Schema type (e.g. SamplingCurvePropertyType) is defined, which
    • has the element representing feature instances as content
    • may then be used to build other content models which refer to this feature type.

e.g. the model above is implemented as
<!-- in a schema document whose targetNamespace is assigned the prefix "sa" -->

<complexType name="SamplingCurveType">
   <complexContent>
      <extension base="gml:AbstractFeatureType"> ... details omitted ... </extension>
   </complexContent>
</complexType>
<complexType name="SamplingCurvePropertyType">
    <sequence minOccurs="0">
        <element ref="sa:SamplingCurve"/>
    </sequence>
    <attributeGroup ref="gml:AssociationAttributeGroup"/>
</complexType>
<element name="SamplingCurve" type="sa:SamplingCurveType"/>

<!-- in a different schema document whose targetNamespace is assigned the prefix "gsml" -->

<complexType name="BoreholeType">
   <complexContent>
      <extension base="sa:SamplingCurveType">
         <sequence>
            <element name="collarLocation" type="gsml:BoreholeCollarPropertyType"/>
            <element minOccurs="0" name="indexData" type="gsml:BoreholeDetailsPropertyType"/>
         </sequence>
      </extension>
   </complexContent>
</complexType>
<complexType name="BoreholePropertyType">
    <sequence minOccurs="0">
        <element ref="gsml:Borehole"/>
    </sequence>
    <attributeGroup ref="gml:AssociationAttributeGroup"/>
</complexType>
<element name="Borehole" type="gsml:BoreholeType" substitutionGroup="sa:SamplingCurve"/>

Note:
  • The content-model for a class is specified as a complex type.
    • this XML Schema use of the term "type" is subtly different to "feature-type" used in ISO 19109
  • The class itself is implemented by the set of instances of XML elements with the name of the class
  • The class hierarchy is implemented by the substitutionGroup affiliations
    • e.g. an instance of Borehole may appear any place that a SamplingCurve is allowed
    • N.B. XML Schema rules require that the type derivation relationships support the substitution group affiliation, but the type definitions are only background mechanics. The implementation of the model is through the element declarations

Variations of this pattern apply
  • when an inline or by-representation instantiation of the property valued is required
  • for classes with other stereotypes
Detailed illustrations of all the XML Schema implementation patterns are provided by the UmlGmlTestModels.


Discussion

Rep or ref?

In GML applications, the standard pattern is for properties to permit their values to be indicated either in-line ("by value"/"by representation") or using xlink attributes ("by reference"). This flexibility allows normalisation of descriptions, i.e. objects are fully described in the most convenient place, and then used "by-reference" many times in many places. On the other hand, for some properties it is required that the values are given inline, and for others it may be required that the value is given by-ref. The GML by-ref and by-rep associations are sometimes compared with UML aggregation and composition associations, respectively, with the "either/or" case corresponding to an general or un-typed association. However, this comparison is not exact.

Note that in GML the semantics of the by-reference method are "retrieve the node identified by this reference, and process this as if it were the content of the property element". Optimally, the remote value will be expressed in a compatible GML syntax. But this cannot be enforced, and processing applications must either be prepared for other results, or must behave gracefully if unable to process the value. This behaviour is a characteristic feature of the "open-world" assumption behind the REST architecture that underlies the World Wide Web.

Note also that the standard gml:AssociationAttributeGroup that is used to build the by-ref structures includes all the xlink attributes from the "simple" xlink group for optional use. The xlink:role attribute may be used to point to a definition (e.g. schema) that describes the nature of the link target.

The value of a property is given in-line by the content of the property element, or by-reference as the value of a resource identified in a link carried as an XML attribute of the property element. If the in-line form is used, then the content may be a literal (a number, text, etc), or may be structured using XML elements, but no assumptions can be made about the structure of the value of a property.

Missing values and "optional" properties

The "by-ref" method also supports a convenient pattern for recording missing values. If the standard GML pattern for properties is followed, then the (typed) content may be omitted (minOccurs="0"), provided a value is indicated using a xlink:href attribute. Its value is a URI. This may be used to indicate a NULL value, such as

   <gsml:collarLocation xlink:href="urn:ogc:def:nil:OGC::unknown" xlink:role="urn:cgi:objectType:CGI:GeoSciML:2.0:BoreholeCollar"/>

Note: the example uses a URN from the scheme described in OGC 06-023r1.

Note: the xlink:role attribute indicates the "nature" of the target object.

This pattern provides an alternative to making the property "optional", for properties that are usually present but for which values may sometimes not be available. This leads to stronger models, and is usually preferable to processing applications.

Other uses of xlinks

See PropertyMetadata.

Processing xlinks

The meaning of xlink:href on a GML property is that it is a pointer to the value of the property. It plays a similar role to the rdf:resource property in RDF. Parsing the value of the xlink:href (a URI) in XML is again handled by the parser. The value of the URI may be an arbitrary URI that is a URL and points to the resource just like in HTML. It may be a URN (Uniform Resource Name) that you can use as if it were well known (i.e. do a table look up in your own software) or it may be passed to a URN resolver that does the look up for you and provides the resource or a handle to the resource (perhaps a URL) that use to get the resource. So for simple xlinks (most of the usage in GML) you don't meet much in terms of special software.

You may also want to make use of some of the other properties in the gml Association Attribute Group - in particular gml:remoteSchema. Parsing is just as above - but you need to use the referenced resource (a schema fragment pointer) you will need to fetch the resource as above, apply the likely XPointer filter contained in the URI value, and then pass the schema fragment to an XML Schema validating parser. Again no really special tools involved.

Where life could get more complex is if the xlink:href or xlink:role attributes contain XPointer expressions - especially ones that use string operators etc. Here there are a number of libraries around that can be used as starting points. Including:

I hope that helps! BTW there are also some libraries and XLink processing engines (see http://skew.org/~mike/4suite-docs/html/modules/Ft.Xml.XLink.html)

-- RonLake - 18 Aug 2006
Topic attachments
I Attachment Action Size Date Who Comment
GFMBorehole.pngpng GFMBorehole.png manage 10.4 K 30 Oct 2007 - 15:08 SimonCox Extract from GeoSciML Borehole model
Topic revision: r29 - 28 Oct 2013, SimonCox
 

Current license: All material on this collaboration platform is licensed under a Creative Commons Attribution 3.0 Australia Licence (CC BY 3.0).