"Seegrid will be due for a migration to confluence on the 1st of August. Any update on or after the 1st of August will NOT be migrated"

Records in GML

Contents

Related pages



Based on a short presentation made in the GML WG meeting at the 57th OGC TC in Edinburgh, June 2006.

Requirement

Soft-typed or dynamically-typed properties are required in certain "generic" feature types, e.g.:
  • Observation/result
  • Coverage/range

Generic feature types are "pattern" feature types, with weakly typed properties so that they can adopt the semantics of many applications. For example, scientific/observation applications share a common methodology which is implemented in common patterns, but which varies at a deeper level. In the Observation and Coverage applications, the semantics are encoded in the observedProperty and rangeDescription, respectively.

The encoding must be dynamic in order to support the variety of potential applications.

What options and patterns are available?

Standard XML for wildcards

Schema instance
Named element with type="xs:anyType" element carries type-designator attribute xsi:type="myns:MyType"
Generic content model indicated <xs:any> replaced with namespace-qualified concrete element <myns:MyElement>

The Record structure is defined using XML Schema. This provides the maximum flexibility achievable in an XML context. However, a generic client for such an approach would have to be completely schema-aware, and would have to be capable of resolving and interpreting the myns:MyType definition or myns:MyElement declaration.

ISO Harmonized model

Wildcards

Two wildcard classes are provided in the ISO 19100 Harmonized Model:
  • Any "Root of all classes ... used where target class is ... not known"
  • Record "indexed set of objects"

Record and RecordType

The "record" class is modelled in the ISO/IEC 11404 record datatype 'whose values are heterogeneous aggregations of values of component datatypes, each aggregation having one value for each component datatype, keyed by a fixed “field-identifier”.' This essentially describes a schema-instance relationship that could simply be implemented by the XML Schema mechanism, or the single index could be interpreted as implying a more flattened structure (a tuple?).

There is a UML model provided in ISO 19103 which locates the mapping from MemberName to TypeName in a RecordType class which sits alongside the Record class. Thus an instance of the RecordType class may be implemented using another mechanism, and packaged in the instance alongside the Record instance.

ISO 19103 Record model

Use of Record in CV_DiscreteCoverage

The Record class is used as the type of the value attribute of CV_GeometryValuePair, being the elements of CV_DiscreteCoverage.

ISO 19123 Discrete Coverage model

XML Implementation of Record and RecordType in ISO 19139

The XML implementation of ISO metadata contains implementations of Record and RecordType in the gco:basicTypes.xsd schema document as follows:

   <xs:element name="Record"/>
i.e. implicitly type="xs:anyType"

   <xs:complexType name="RecordType_Type">
      <xs:simpleContent>
         <xs:extension base="xs:string">
            <xs:attributeGroup ref="xlink:simpleLink"/>
         </xs:extension>
      </xs:simpleContent>
   </xs:complexType>
   <!-- ........................................................................ -->
   <xs:element name="RecordType" type="gco:RecordType_Type"/>
i.e. record structure described in text (cop-out!) or using a link to an external resource

GML implementations

Built-ins

GML uses soft-typed records in a couple of places:

  • <gml:pos> implements GM_DirectPosition, which is a space-separated sequence of numbers with a reference system
  • <gml:tupleList> has type="gml:CoordinatesType" which is a space-separate list of homogeneously structured records composed of comma-separated items, no local reference system indicator
  • valueObjects.xsd schema defines a nested XML structure

These can all be thought of as implementations of Record, the first two relying on an external reference-system definition, and the latter "interleaved" with its record-type definition.

Examples

<gml:pos srsName="urn:ogc:def:crs:EPSG:6.5:4326">-32. 140.</gml:pos>

<gml:tupleList>3,101.2  5,101.3  7,101.4  11,101.5</gml:tupleList>
  • no link to a “RecordType” - semantics provided by context
  • embedded list with variable item-separators “,”, “ ”, requires special writers and readers

<gml:CompositeValue>
  <gml:valueComponents>
    <gml:Point><gml:pos>-67.563 -13.834</gml:pos></gml:Point>
    <gml:Quantity uom="#km">632.</gml:Quantity>
    <gml:TimeInstant>
        <gml:timePosition>1994-06-09T00:33:16.4</gml:timePosition>
    </gml:TimeInstant>
    <gml:Quantity uom="#mom">-1.00</gml:Quantity>
  </gml:valueComponents>
</gml:CompositeValue>

  • nested, verbose
  • component type explicit, but GML types only
  • no link to semantics

Implementations in SWE-Common Application Schema

3 variants developed in OWS-3
  • DataComponent/DataBlockDefinition - from SensorML
  • CompactRecord/RecordSchema - from O&M (removed in OWS-4)
  • Record/RecordSchema - from O&M (RecordSchema replaced by DataBlockDefinition in OWS-4)

+ 2 different recordType encodings

Examples

<om:result>
      2005-01-11T17:30:15.00 17.0
      2005-01-11T17:43:10.00 30.1
      2005-01-11T17:54:35.00 45.0
      2005-01-11T18:07:25.00 70.0
      2005-01-11T18:11:05.00 65.0
      2005-01-11T18:22:25.00 60.3
</om:result>

  • XML string, with specified record and tuple item separator
    • Essentially same as gml:tupleList
  • Requires special writer/reader

<om:resultDefinition xlink:href="timeSeries3.xml#ts3g"/>
<om:result xsi:type="swe:SWE_CompactRecordType" RS="#ts3g">
  2005-01-11T17:22:25.00 15.5
   2005-01-11T17:30:15.00 17.0
   2005-01-11T17:43:10.00 30.1
   2005-01-11T17:54:35.00 45.0
   2005-01-11T18:07:25.00 70.0
   2005-01-11T18:11:05.00 65.0
   2005-01-11T18:22:25.00 60.3
</om:result>

  • XML list-of-strings
    • space-separated items
  • local link to “reference system”
  • Requires special writer, XPointer-enabled reader

   <om:resultDefinition xlink:href="timeSeries3.xml#ts3g"/>
   <om:result>
      <swe:Array>
         <swe:Record><swe:item>2005-01-11T17:22:25.00</swe:item><swe:item>15.5</swe:item></swe:Record>
         <swe:Record><swe:item>2005-01-11T17:30:15.00</swe:item><swe:item>17.0</swe:item></swe:Record>
         <swe:Record><swe:item>2005-01-11T17:43:10.00</swe:item><swe:item>30.1</swe:item></swe:Record>
         <swe:Record><swe:item>2005-01-11T17:54:35.00</swe:item><swe:item>45.0</swe:item></swe:Record>
         <swe:Record><swe:item>2005-01-11T18:07:25.00</swe:item><swe:item>70.0</swe:item></swe:Record>
         <swe:Record><swe:item>2005-01-11T18:11:05.00</swe:item><swe:item>65.0</swe:item></swe:Record>
         <swe:Record><swe:item>2005-01-11T18:22:25.00</swe:item><swe:item>60.3</swe:item></swe:Record>
      </swe:Array>
   </om:result>

  • XML tagged items, nested in Records, nested in an Array
  • untyped items (strings)
  • local link to “reference system”
  • standard XML processing for both reading and writing

Summary

Various options in use
  • remains uncertainty on this topic
  • no explicit basis in datatypes from ISO abstract model

Standard “GML” encodings required for
  • soft-typed Record (and RecordType)
  • Geometry-Value (Record) pair
  • sets

perhaps in both “compact” and XML-tagged variants

N.B. Set of geometry-value pairs is required to implement CV_DiscreteCoverage, esp. time-series

-- SimonCox - 22 Nov 2006

 
Topic attachments
I Attachment Action Size Date Who Comment
IsoCV_DC.PNGPNG IsoCV_DC.PNG manage 5.4 K 22 Nov 2006 - 16:14 SimonCox ISO 19123 Discrete Coverage model
IsoRecord.PNGPNG IsoRecord.PNG manage 5.6 K 22 Nov 2006 - 16:14 SimonCox ISO 19103 Record model
Topic revision: r3 - 15 Oct 2010, UnknownUser
 

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