This OGC® Standard specifies standard encoding representations of movement of geographic features. The primary use case is information exchange.
ogcdoc, ogc document, moving features, gml
iii. Submitting organizations
The following organizations submitted this Document to the Open Geospatial Consortium (OGC):
- Central Research Laboratory, Hitachi Ltd.
- Center for Spatial Information Science, The University of Tokyo
- Defense Systems Company, Hitachi, Ltd.
All questions regarding this submission should be directed to the editor or the submitters:
|Akinori Asahara||Central Research Laboratory, Hitachi Ltd.||Yes|
|Ryosuke Shibasaki||Center for Spatial Information Science, The University of Tokyo||Yes|
|Nobuhiro Ishimaru||Defense Systems Company, Hitachi Ltd.||Yes|
|Hiroshi Kanasugi||Center for Spatial Information Science, The University of Tokyo||Yes|
|Gianluca Luraschi||EMSA (European Maritime Safety Agency)||Yes|
|Chris Little||UK Met Office||Yes|
|Nadeem Anjum||Google Summer of Code representative through Apache||No|
|Ki-Joune Li||Pusan National University||Yes|
v. Changes to the OGC® Abstract Specification
The OGC® Abstract Specification does not require changes to accommodate this OGC® standard.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. Open Geospatial Consortium shall not be held responsible for identifying any or all such patent rights. However, to date, no such rights have been claimed or identified.
Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.
OGC Moving Features consists of the following parts under the general title Moving Features Encoding:
- Part I:XML Core
- Part II:Simple CSVand the following specification:
- Moving Features Access
Applications using moving feature data, typically representing vehicles or pedestrians, are rapidly increasing. Innovative applications are expected to require the overlay and integration of moving feature data from different sources to create greater social and business value. Examples of applications that require integrated simulation are disaster risk management, traffic information services, security services, navigation for robots, aviation or maritime traffic monitoring, and wildlife tracking and conservation. Moreover, systems relying on single-source moving feature data are now evolving into more integrated systems. Integration of moving feature data from different sources is a key to developing more innovative and advanced applications.
Efforts in this direction therefore should be encouraged by ensuring smoother data exchange because handling and integrating moving feature data will broaden the market for geo-spatial information such as Geospatial Big Data Analysis. ISO 19141:2008 is an existing abstract standard to model moving features; however encoding method is not provided.
Therefore, an XML (and GML) style encoding for Moving Features is standardized. The defined encoding standard is ISO 19141:2008 Geographic Information – Schema for Moving Features compliant implementation standard applicable for massive data handling. ISO 19141:2008 defines a method to describe the geometry of a feature that moves as a rigid body.
This OGC® Standard specifies an encoding format to describe the geometries of many features that move as rigid bodies. This OGC Standard is applicable to features having the following characteristics.
- Each moving feature can be described with Schema for Moving Features (ISO19141: 2008).
- The number of features simultaneously encoded with this format can be massive (many thousands of features).
- All features can be described using common space-time coordinates.
This standard does not address all types of moving features. Examples of features that are out of scope include the following:
- Deforming features, such as flood water.
- Feature’s geometric representation should not be encoded inline in a geometric complex that contains the geometric representations of other features, since this would require the other features’ representations to be updated as the feature moves.
This standard is focused on the encoding format, thus Web interface and inertial data models are out of scope also.
Conformance with this specification shall be checked using all the relevant tests specified in Annex A (normative).
3. Normative References
The following normative documents contain provisions which, through reference in this text, constitute provisions of this part of OGC Moving Features. For dated references, subsequent amendments to, or revisions of, any of these publications do not apply. However, parties to agreements based on this part of OGC Moving Features are encouraged to investigate the possibility of applying the most recent editions of the normative documents indicated below. For undated references, the latest edition of the normative document referred to applies.
- [OGC 07‑036] OGC 07‑036, OpenGIS® Geography Markup Language (GML) Encoding Standard
- [ISO 19141:2008] ISO 19141:2008, Geographic information – Schema for moving features
- [ISO 19101:2014] ISO 19101:2014, Geographic information -- Reference model -- Part 1: Fundamentals
- [IETF RFC 2396] IETF RFC 2396, Uniform Resource Identifiers (URI): Generic Syntax. (August 1998)
- [W3C XML] W3C XML, Extensible Markup Language (XML) 1.0 (Third Edition), W3C Recommendation (4 February 2004)
- [W3C XML Namespaces] W3C XML Namespaces, Namespaces in XML, W3C Recommendation (14 January 1999)
- [W3C XML Schema Part 1] W3C XML Schema Part 1, XML Schema Part 1: Structures, W3C Recommendation (2 May 2001)
- [W3C XML Schema Part 2] W3C XML Schema Part 2, XML Schema Part 2: Datatypes, W3C Recommendation (2 May 2001)
4. Terms and Definitions
For the purposes of this document, the following terms and definitions apply.
- 4.1 Moving feature
representation, using a local origin and local ordinate vectors, of a geometric objectat a given reference time
dt class="term">4.2 Foliation
one parameter set of geometries such that each point in the prism of the set is in one and only one trajectory and in one and only one leaf
- 4.3 geometric object
spatial object representing a geometric set
- 4.4 leaf
<one parameter set of geometries>
geometry at a particular value of the parameter
- 4.5 trajectory
path of a moving point described by a one parameter set of points
- 4.6 one parameter set of geometries
function f from an interval t ∈ [a, b] such that f(t) is a geometry and for each point P ∈ f(a) there is a one parameter set of points (called the trajectory of P) P(t) : [a, b] →P(t) such that P(t) ∈ f(t)
- 4.7 prism
<one parameter set of geometries>
set of points in the union of the geometries (or the union of the trajectories) of a one parameter set of geometries
- 4.8 period
one-dimensional geometric primitiverepresenting extent in time
- 4.9 point
0-dimensional geometric primitive, representing a position
- 4.10 geometric primitive
geometric object representing a single, connected, homogeneous element of space
- 4.11 vector
quantity having direction as well as magnitude
5.1 Abbreviated terms
The following symbols and abbreviated are used in this standard;
- International Organization for Standardization
- Open Geospatial Consortium
- Unified Modeling Language
- Extensible Markup Language
- One Dimensional
- Two Dimensional
- Three Dimensional
- Comma Separated Values
5.2 UML Notation
The diagrams that appear in this standard are presented using the Unified Modeling Language (UML) static structure diagram. The UML notations used in this standard are described in the diagram below.
In this standard, the following three stereotypes of UML classes are used:
- <<Interface>> A definition of a set of operations that is supported by objects having this interface. An Interface class cannot contain any attributes.
- <<DataType>> A descriptor of a set of values that lack identity (independent existence and the possibility of side effects). A DataType is a class with no operations whose primary purpose is to hold the information.
- <<CodeList>> is a flexible enumeration that uses string values for expressing a list of potential values.
In this standard, the following standard data types are used:
- CharacterString – A sequence of characters
- Integer – An integer number
- Double – A double precision floating point number
- Float – A single precision floating point number
5.3 XML Namespaces
All components of the Moving Feature XML schema are defined in the namespace with the identifier “http://www.opengis.net/movingfeatures/1.0”, for which the prefix mf or the default namespace is used within this Standard.
6. Data Model Overview
6.1 Concepts and standard modularity
Figure 1 illustrates the standard components for encoding and communicating Moving Features data. The four boxes drawn in the figure portray the four modules defined in the OGC® Moving Features standard.
OGC® Moving Features Simple CSV Encoding and Simple Binary Encoding are fundamental and are data formats to describe moving points and their trajectories. The formats are designed to encode trajectories of moving points compactly as application schemas of IETF RFC 4180 (CSV), NetCDF Discrete Sampling Geometry and so on.
OGC® Moving Features Core, defined in this document, is represented by an XML data encoding for moving points and their trajectories. The format is an extensible format to model and encode movement data for features encoded as point geometries .
OGC® Moving Features 1D/2D Geometry and OGC® Moving Features 3D Geometry are defined to encode moving features that have more complex geometries.
Two UML packages are defined in ISO 19141:2008 [ISO 19141:2008]: “Geometry Types” and “Prism Geometry”. “Geometry Types” defines the description model of movements including the paths. “Prism Geometry” defines the moving geometry. The two squares drawn with broken lines in Fig. 1 correspond to these packages. The square labeled as “<<Prism Geometry>>” is an implementation of “Prism Geometry”; the square labeled as “<<Geometry Types>>” is an implementation of “Geometry Types.”
6.2 Foliation and prisms
Figure 2 illustrates the concepts of foliation, prism, trajectory, and leaf, which are defined in ISO19141:2008[ISO 19141:2008]. In this illustration, a 2D rectangle moves and rotates. Each representation of the rectangle at a given time is a leaf. The path traced by each corner point of the rectangle is a trajectory. The set of points contained in all of the leaves, and in all of the trajectories, forms a prism. The set of leaves also forms a foliation.
The prism of the moving feature can be viewed as a bundle of trajectories of points on the local engineering representation of the feature’s geometry. If viewed in a 4 dimensional spatio-temporal coordinate system, the points on the feature at different times are different points.
Each moving feature has information to indicate the movement path, which is the trajectory shown in the prism model. MF_TemporalTrajectory is defined in ISO 19141:2008 [ISO 19141:2008] to describe the trajectory. OGC Moving Features supports the structure (mf:AbstractTrajectory shown in 9.2 corresponds to MF_TemporalTrajectory).
More generally, a moving feature is a feature which has dynamic attributes. The dynamic attributes indicate attributes changing dynamically. If the value type of a dynamic attribute is geometric point, it is a trajectory. Accordingly, the feature type models for the OGC Moving Features are defined as shown in Figure 3. MovingFeatureType inherits GF_FeatureType and aggregates a group of DynamicAttributeType.
6.3 XML Implementation
An XML data encoding is defined in this standard for implementing the foliation data model. Note that massive amounts of moving feature data may need to be described with this format. Therefore, the data encoding should be compact and easy to handle. Figure 4 illustrates an importing process for a document written in the XML data format. When dealing with massive numbers of moving features, the entire data set may not be able to be loaded into memory. Therefore, the XML data should be parsed on-the-fly. This means that all information needed for interpretation of the XML data should appear at the head of the document. Thus, the XML document written has two main parts: header part and body part. The header part, which is implemented as meta elements, includes meta information for the XML data. The body part, which is implemented as foliation elements, includes the movement information and dynamic properties for moving features.
6.4 Time ordered encoding
Figure 5 shows an example for trajectories of three moving points A, B and C. Each trajectory has the start time and the end time. At t=0 (start of all data), all points start moving. Then, at t =1, the movement of A is changed. In the case, the trajectory of A from t=0 to t=1, the trajectory of A from t=1 to t=2, the trajectory of B from t=0 to t=2, and the trajectory of C from t=0 to t=2 are encoded. This means that only changes of state, including moving-speed, direction, existence, and attributes, are encoded in the format. The encoded changes of state are ordered by time in order to determine the states of all features even if only the first half of data is loaded.
7. Root Element
<mf:MovingFeatures gml:id=”ID”> <mf:sTBoundedBy> ... </mf:sTBoundedBy> <mf:member> ... </mf:member>[0,..,n] <mf:Header> ... </mf:Header>[0,1] <mf:Foliation> ... </Foliation>[0,1] </mf:MovingFeatures>Superclass: gml:AbstractFeature [OGC 07‑036]
The root element is named mf:MovingFeatures. The mf:MovingFeatures element consists of mf:sTBoundedBy, mf:member(optional), mf:Header and mf:Foliation. The mf:sTBoundedBy states the spatio-temporal bound of the trajectories. The mf:Header element has meta-information about the moving features, for example, attribute definition. The mf:Foliation element, which is the main part of the moving feature data, contains moving geometries.
Requirement 7.1 (req/xmlcore/movingfeatures)
The root element shall be mf:MovingFeatures.
The class diagram of the mf:MovingFeatures is shown below.
This element regulates the spatio-temporal region where the trajectories described in the foliation exist. Times used in trajectories are described in offset time, that is, duration in seconds or minutes or hours from the time origin defined here is shown in the trajectory elements. The mf:STBoundedBy element inherits gml: BoundingShapeType, and include gml:EnvelopeWithTimePeriod [OGC 07‑036].
22.214.171.124 mf:member (optional)
mf:member elements give the properties of moving features.
mf:Header element describes the meta information of the XML document.
mf:Foliation includes movements of moving features. The movements are expressed as spatio-temporal curves, which are included in trajectory elements.
<mf:sTBoundedby offset=”time unit”> <gml:EnvelopeWithTimePeriod>...</gml:EnvelopeWithTimePeriod> </mf:sTBoundedBy>Superclass: gml: BoundingShapeType [OGC 07‑036]
The mf:sTBoundedBy element indicates the boundary of the moving features. All trajectories are contained in the spatio-temporal boundary specified at mf:sTBoundedBy.
The gml:EnvelopeWithTimePeriod [OGC 07‑036] specifies the envelope of the boundary. All moving features included in the foliation should be in the envelope. The used spatial reference system in the envelope (specified by srsName and srsDimension attributes) is default in the foliation. The coordinate system used for the trajectories should be specified by srsName
The offset attribute shows the unit of time used in the mf:Foliation. “start” attribute and “end” attribute of mf:AbstractTrajectory is described the offset from the gml:beginPosition. The unit of time is defined as the offset attribute.
|sec||the offset described in seconds is encoded in xsd:decimal style||yes|
|minute||the offset described in minutes is encoded in xsd:decimal style|
|absolute||an absolute time description used in the gml:beginPosition|
<mf:member> <gml:AbstractFeatureType gml:id=”ID”> ... </gml:AbstractFeatureType> </mf:member> <mf:member xlink:href=”URI” />
The contents of mf:member specifies properties of moving features.
The gml:AbstractFeature gives the properties of the moving feature. The gml:id can be referred to associate the element with mf:mfIdRef.
126.96.36.199 xlink:href (optional)
The attribute specifies an URI at which mf:AbstractFeature is given.
<mf:MovingFeature gml:id=”ID”> <gml:name>...</gml:name> </mf:MovingFeatue>Superclass: gml:AbstractFeature [OGC 07‑036]
The mf:MovingFeature specifies the property of moving features as a kind of gml:AbstractFeature. Normally, elements inheriting gml:AbstractFeature are defined in an application of Moving Feature XML Core, for example, app:Vehicle, app:Pedestrian, and so on. The mf:MovingFeature is predefined for ease to providing properties of features.
8. Header data
<mf:Header> <mf:VaryingAttrDefs> ... </mf:VaryingAttrDefs>[0,1] <mf:Hints> ... </mf:Hints> [0,1] </mf:Header>
The mf:Header element contains the meta-information for the XML data.
Requirement 8.1 (req/xmlcore/header/structure):
The contents of mf:Header shall be mf:VaryingAttrDefs or mf:Hints or both. If both are included, mf:VaryingAttrDefs shall appear earlier then mf:Hints.
This element defines attributes used in the foliation (see 8.3). If the moving features do not have any variable attributes, this element can be omitted.
Hints element shows the optional information which is helpful for data processing.
The mf:VaryingAttrDefs element specifies the available attributes in the XML document. The mf:VaryingAttrDefs element contains mf:AttrDef elements to enumerate the attribute name and the type of contents.
<VaryingAttrDefs> <AttrDef ... />[0...*] </VaryingAttrDefs>
mf:VaryingAttrDefs states the definition of attributes used in the foliation.
Requirement 8.2 (req/xmlcore/varyingattrdefs):
mf:VaryingAttrDefs shall include mf:AttrDef, otherwise the content is empty.
The element indicates a definition of an attribute used in the foliation.
<mf:AttrDef> <xsd:simpleType name=””> ... <xsd:annotation> ... </xsd:annotation> </xsd:simpleType> </mf:AttrDef> <mf:AttrDef name=”name of attribute” type=”type string”> <mf:AttrAnnotation> ... </mf:AttrAnnotation> </mf:AttrDef>
The AttrDef element defines the attribute name and the type of contents.
Requirement 8.3 (req/xmlcore/attrdef/attributes)
Any attributes of moving features appearing in mf:Foliation shallbe defined by mf:AttrDefs element.
Requirement 8.4 (req/xmlcore/attrdef/datatypes)
The types of the attributes shall be consistent with the data descriptions of the attributes.
The type of the attribute is defined in mf:AttrDef by xsd:simpleType. An example is following.
<mf:AttrDef> <xsd:simpleType name=”speed_meter_record”> <xsd:union> <xsd:simpleType name=”km_per_hour”> <xsd:restriction base="xsd:positiveInteger"> <xsd:minInclusive value="0"/> <xsd:maxInclusive value="100"/> </xsd:restriction> </xsd:simpleType> <xsd:simpleType name=”speed_rank”> <xsd:restriction base="xsd:NMTOKEN"> <xsd:enumeration value="slow"/> <xsd:enumeration value="medium"/> <xsd:enumeration value="fast"/> </xsd:restriction> </xsd:simpleType> </xsd:union> </xsd:simpleType> </mf:AttrDef>
The attributes name and type can be used instead of the content for ease of the description.
<mf:AttrDef name=”speed_meter_km_per_hour” type=”xsd: positiveInteger” />
Either of the two styles should be used to define the type of attributes.
Requirement 8.5 (req/xmlcore/attrdef/datatypes_definition)
A xsd:simpleType shall be contained by mf:AttrDef if the attributes name and type of mf:AttrDef are omitted.
188.8.131.52 name (optional)
The name attribute shows the name of the attribute defined in the mf:AttrDef element.
184.108.40.206 type (optional)
The type attribute shows the data type of the attribute defined in the mf:AttrDef element. The data type is specified by xsd data type. Examples of the data types are listed in the following table.
|1||xsd:boolean||“True” or “false”|
|4||xsd:string||Text data like “I am here.” with double quotation marks (“).|
|5||xsd:dateTime||Text specifying the date time like “1999-05-31T13:20:00.000-05:00”.|
|6||xsd:AnyURI||URI style text|
<mf:AttrAnnotation> Annotation Text </mf:AttrAnnotation>
The contents of mf:AttrAnnotation is the detailed text for describing the attribute.An example of the attnotaions is following.
<mf:AttrDef name=”speed_meter_record” type=”xsd:string”> <mf:AttrAnnotation> This attribute shows the speed meter records of the vehicles. Slow : less than 20km/h Medium: more than or equal to 20km/h, and less than 100km/h Fast: more than or equal to 100km/h </mf:AttrAnnotation> </mf:AttrDef>
Note that xsd:Annotation is also available if xsd:simpleType is used.
<mf:Hints> <mf:Hint> - </mf:Hint>[0...*] </mf:Hints>
The mf:Hints element includes the information helpful for processing. If the dataset is huge, special techniques to handle the dataset are needed. For such case, the mf:Hints element provides the additional information. For example, the size of dataset is helpful for determining whether the entire data are loadable on the DRAM.
Requirement 8.6 (req/xmlcore/hints):
Contents of the mf:Hints element shall be mf:Hint describing hints for interpretation processes.
mf:Hint gives predefined hints to process the dataset.
<mf:Hint name=”hintname”>value text</mf:Hint>
The mf:Hint element includes the information helpful for processing. Pair of name attribute and text describes one hint (this is a key-value-pair data).
Requirement 8.7 (req/xmlcore/hint):
Any hints specified by mf:Hint shall be consistent with the contents of mf:Foliation.
The mf:Hint element value provides the value of the “key-value-pair”.
The name attribute specifies the key of the key-value pair. The content shows the value related to the key. For example, if name is “TrajectoryAppearance” and content is “periodic” like
<mf:Hint name=” TrajectoryAppearance”>periodic</mf:Hint>,
the trajectory elements will appear periodically. The defined pairs of name and value are listed in the table 1.
|TrajectoryAppearance||periodic: rajectory elements appear periodically. random: trajectory elements appear randomly.|
|TrajecotryLifetime||The maximal time length of the trajectories is shown.|
<mf:foliation order=”...”> <mf:AbstractTrajectory> ... </mf: AbstractTrajectory>[0...*] </mf:foliation>
The foliation element, which contains the spatio-temporal geometries for moving features, supports a foliation structure.
Requirement 9.1 (req/xmlcore/foliation)
The foliation element shall include mf:STBoundedBy with a srsName attribute and elements inheriting mf:AbstractTrajectory using a coordinate system specified by the srsName of mf:sTBoundedBy.
Requirement 9.2 (req/xmlcore/foliation/order)
mf:sTBoundedBy shall be the first element in mf:Foliation. The following elements shall be ordered by the rule specified by order attribute of the mf:Foliation.
Trajectories of moving features are expressed as subclasses of the mf:AbstractTrajectory. Because the subclasses of mf:AbstractTrajectory will be defined in the later versions of OGC Moving Features XML Core, softwares supporting the current version should work correctly even if any subclasses of mf:AbstractTrajectory are used (i.e. the unsupported types might be ignored),
“order” defines appearing order of mf:AbstractTrajectory elements. The possible values are enumerated in the following code table.
|Time||mf:AbstractTrajectory elements ordered by time strictly||yes|
|Sequential||mf:AbstractTrajectory elements which are parts of one track are ordered by time|
<mf:AbstractTrajectory mfIdRef=”id” start=”t1” end=”t2” interpolation=”interpolation type”> <mf:Attr>Attributes text</mf:Attr> [0, 1] </mf:AbstractTrajectory>Superclass: gml:AbstractCurve [OGC 07‑036]
mf:AbstractTrajectory is an abstract class to implement the trajectory.
mf:AbstractTrajectory, of which superclass is gml:AbstractCurve [OGC 07‑036], has an attribute to specify the method for temporal interpolation.
Requirement 9.3 (req/xmlcore/abstracttrajectory):
All elements in mf:Foliation shall be inheritances of mf:AbstractTrajectory.
Each mf:AbstractTrajectory describes a segment consisting of a trajectory. If the mf:AbstractTrajectory elements with common “mfid” attribute are collected and sorted by time, the sequence of the segments constitutes the entire spatio-temporal trajectory of the moving feature identified by the “mfid” attribute.
Attributes variable by time are described in this element. The values of the attributes are constant while the feature moves along the mf:AbstractTrajectory.
The text specifying the moving feature (i.e. person ID, vehicle ID, etc.)
“start” attribute specifies the start time of the segment.
“end” attribute specifies the end time of the segment.
220.127.116.11 “interpolation” (optional)
The attribute specifies the interpolation method.
“linear” (default): The point during the movement is linearly interpolated. The linearly interpolated points between two end points P1 and P2 are derived by:
<mf:LinearTrajectory> <gml:PosList>...</gml:PosList>[0, 1] <mf:Attr>Attributes text</mf:Attr>[0, 1] </mf:LinearTrajectory>Superclass: mf:AbstractTrajectory
mf:LinearTrack element is the spatio-temporal line string, which is similar to gml:LineString [OGC 07‑036]. The mf:LinearTrack is a special trajectory that consists of a single segment with linear interpolation.
Requirement 9.4 (req/xmlcore/lineartrajectory):
mf:LinearTrajectory shall include gml:PosList having more than two points (their dimension is specified by gml:EnvelopeWithTimePeriod in mf:sTBoundedBy).
Two or more coordinate tuples are specified in gml:posList, with linear interpolation between them. The described line string is the trajectory of the moving featrure.
Attributes variable by time are described in this element. The values of the attributes are constant while the feature moves along the mf:LinearTrajectory.
The mf:Attr element contains the attribute information as a text.
Requirement 9.5 (req/xmlcore/attr):
mf:Attr shall include a CSV text line of which columns are consistent with mf:AttrDefs.
A CSV text which describes the attribute values is contained. An example is the following:
Some characters may need to be escaped here. < (less than), > (greater than), “ (double quotation), ‘ (single quotation), and & (ampersand) must be replaced with the entity references defined in XML. Space, tab, and comma are written in escape sequences \s, \t, and \b, respectively. If the value equals the previous value, the text for the value can be omitted.
Requirement 9.6 (req/xmlcore/attr/entity):
< (less than), > (greater than), “ (double quotation), ‘ (single quotation), and & (ampersand) contained by mf:Attr shall be replaced with the entity references.
10. Example instances
10.1 Example 1 Pedestrian’s tracks
<?xml version="1.0" encoding="UTF-8"?> <mf:MovingFeatures xmlns:mf="http://www.opengis.net/movingfeatures/1.0/mf-xmlcore" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:gml="http://www.opengis.net/gml/3.2" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.opengis.net/movingfeatures/1.0/mf-xmlcore http://schemas.opengis.net/movingfeatures/1.0/mf-xmlcore.xsd" gml:id="MFC_0001"> <mf:sTBoundedBy offset="sec"> <gml:EnvelopeWithTimePeriod srsName="urn:ogc:def:crs:EPSG:6.6:4326"> <gml:lowerCorner>50.23 9.23</gml:lowerorner> <gml:upperCorner>50.31 9.27</gml:upperCorner> <gml:beginPosition>2012-01-17T12:33:41Z </gml:beginPosition> <gml:endPosition>2012-01-17T12:37:00Z </gml:endPosition> </gml:EnvelopeWithTimePeriod> </mf:sTBoundedBy> <mf:member xlink:href="#pointerToGmlIdOfMovingFeature_a"/> <mf:member xlink:href="#pointerToGmlIdOfMovingFeature_b"/> <mf:member> <mf:MovingFeature gml:id="a"> <gml:name>Joe Blow</gml:name> </mf:MovingFeature> </mf:member> <mf:member> <mf:MovingFeature gml:id="b"> <gml:name>Jane Doe</gml:name> </mf:MovingFeature> </mf:member> <mf:header> <mf:VaryingAttrDefs> <mf:attrDef> <xsd:simpleType name="state"> <xsd:restriction base="xsd:NMTOKEN"> <xsd:enumeration value="walking"/> <xsd:enumeration value="staying"/> <xsd:enumeration value="running"/> </xsd:restriction> </xsd:simpleType> </mf:attrDef> <mf:attrDef> <xsd:simpleType name="typecode"> <xsd:restriction base="xsd:integer"> <xsd:enumeration value="1"/> <xsd:enumeration value="2"/> <xsd:enumeration value="97"/> </xsd:restriction> </xsd:simpleType> </mf:attrDef> </mf:VaryingAttrDefs> </mf:header> <mf:foliation> <mf:LinearTrajectory gml:id="LT0001" mfIdRef="a" start="10" end="150"> <gml:posList>11.0 2.0 12.0 3.0</gml:posList> <mf:Attr>walking,1</mf:Attr> </mf:LinearTrajectory> <mf:LinearTrajectory gml:id="LT0002" mfIdRef="b" start="10" end="190"> <gml:posList>10.0 2.0 11.0 3.0</gml:posList> <mf:Attr>walking,2</mf:Attr> </mf:LinearTrajectory> <mf:LinearTrajectory gml:id="LT0003" mfIdRef="a" start="150" end="190"> <gml:posList>12.0 3.0 10.0 3.0</gml:posList> <mf:Attr>walking,2</mf:Attr> </mf:LinearTrajectory> </mf:foliation> </mf:MovingFeatures>
10.2 Example 2 Vehicles
<?xml version="1.0" encoding="UTF-8"?> <mf:MovingFeatures xmlns:mf="http://www.opengis.net/movingfeatures/1.0/mf-xmlcore" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:gml="http://www.opengis.net/gml/3.2" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.opengis.net/movingfeatures/1.0/mf-xmlcore http://schemas.opengis.net/movingfeatures/1.0/mf-xmlcore.xsd" gml:id="MFC_0002"> <mf:sTBoundedBy offset="sec"> <gml:EnvelopeWithTimePeriod srsName="urn:ogc:def:crs:EPSG:6.6:4326"> <gml:lowerCorner>150 0</gml:lowerCorner> <gml:upperCorner>250 50</gml:upperCorner> <gml:beginPosition>2013-05-01T10:33:41Z </gml:beginPosition> <gml:endPosition>2013-05-01T10:37:41Z </gml:endPosition> </gml:EnvelopeWithTimePeriod> </mf:sTBoundedBy> <mf:member xlink:href="#pointerToGmlIdOfMovingFeature_a"/> <mf:member xlink:href="#pointerToGmlIdOfMovingFeature_b"/> <mf:member> <mf:MovingFeature gml:id="a"> <gml:description>Nissan Sentra - License plate ABC 123. Five passengers.</gml:description> <gml:name>NissanA</gml:name> </mf:MovingFeature> </mf:member> <mf:member> <mf:MovingFeature gml:id="b"> <gml:description>Nishiki 21 speed racer</gml:description> <gml:name>BicycleB</gml:name> </mf:MovingFeature> </mf:member> <mf:header> <mf:VaryingAttrDefs> <mf:attrDef name="direction" type="xsd:double"> <mf:AttrAnnotation> The direction of the vehicle: the attribute value is the angle between the north direction and the vehicle direction. Unit of angle is radian. For example, North is 0[rad], East is 1.57[rad] and West is -1.57[rad]. </mf:AttrAnnotation> </mf:attrDef> </mf:VaryingAttrDefs> </mf:header> <mf:foliation> <mf:LinearTrajectory gml:id="LT0001" mfIdRef="a" start="0" end="50"> <gml:posList>161 5 172 5</gml:posList> <mf:Attr>0.0</mf:Attr> </mf:LinearTrajectory> <mf:LinearTrajectory gml:id="LT0002" mfIdRef="b" start="0" end="50"> <gml:posList>158 20 158 50 159 60</gml:posList> <mf:Attr>1.57</mf:Attr> </mf:LinearTrajectory> <mf:LinearTrajectory gml:id="LT0003" mfIdRef="a" start="50" end="100"> <gml:posList>172 5 172 1</gml:posList> <mf:Attr>-1.57</mf:Attr> </mf:LinearTrajectory> <mf:LinearTrajectory gml:id="LT0004" mfIdRef="b" start="50" end="100"> <gml:posList>159 60 166 50</gml:posList> <mf:Attr>0</mf:Attr> </mf:LinearTrajectory> </mf:foliation> </mf:MovingFeatures>
Abstract Test Suite
This Annex specifies an Abstract Test Suite which shall be passed in completeness by any implementation claiming conformance with this Moving Features XML Core. Test identifiers below are relative to
A.1 Conformance Class:
The OGC URI Identifier of this conformance classes is
|A.1.1 XML Validity|
|Test Purpose||Verify that any XML element defined in namespace “mf” is well-formed and valid.|
|Test Method||Validate the XML document using the XML schema document http://schemas.opengis.net/movingfeatures/1.0/mf-xmlcore.xsd. Pass if no errors reported. Fail otherwise.|
|A.1.2 Root Element|
|Test Purpose||Verify that the root element is “mf:MovingFeatures”.|
|Test Method||Validate that the root element of the document is mf:MovingFeatures.|
|A.1.3 Attribute Definition|
|Test Purpose||Verify that attribute definitions are consistent with the attributes shown in the trajectories.|
At First, the contents of mf:AttrDef is checked. If it is empty, the attributes of mf:AttrDef are checked. If either the name attribute or the type attribute is empty, the test is failed.
After that mf:AttrDef is checked, the contents of mf:attr are parsed as a CSV data. Then the number of columns and the datatype of the columns are checked. If they are consistent with the definition in mf:attrdefs, the test is passed. If not, it is failed.
|A.1.4 Time order|
|Test Purpose||Verify that “order” attribute of mf: foliation is consistent with the contents of the foliation.|
|Test Method||The “start” attributes of mf:AbstractTrajectory (and the inheritances) are checked. If the order is consistent with the “order” attributes, the test passes.|
|Test Purpose||Verify that mf:Hints is consistent with the contents of the foliation.|
The contents of mf:Hint are checked.
- If TrajectoryAppearance is specified, the “start” and “end” attributes of mf:AbstractTrajectory (and the inheritances) are checked. If they are consistent, the test passes.
- If TrajectoryLifetime is specified, the difference between “start” and “end” attributes of mf:AbstractTrajectory (and the inheritances) are checked. If they are less than the specified life time, the test passes.
|Test Purpose||Verify that the mf:LinearTrajectory is vaild.|
|Test Method||If gml:PosList included by mf:LinearTrajectory has more than two points which are contained by the spatio-temporal envelope determined by mf:sTBoundedBy, the test passes.|
B.1 Transportation survey with smart phones
Traffic congestion is a serious problem in many cities. Basically, two types of solutions are applied to resolve congestion: road-construction and enhancement of public transportation systems. Both of the solutions require information on trip demands: the number of people’s movements between two places, because roads and public transportation systems should make connection between the pairs of places that have the highest trip demand. Therefore, the trip demands should be figured out by transportation survey.
Questionnaires are traditionally used to survey trip demands. However, because GPS enabled smart-phones are now available, GPS based research is applicable as a sampling alternative. The GPS tracks are encoded by Moving Features standard in order to be shared by many stakeholders like local governments, bus companies, and so on.
|Pedestrians||Walking people to go somewhere||Speed: 4km/h||State: Stay or Walking|
|Vehicles||People driving his/her vehicle||Speed: 60km/h|
|Data sources||Localization method||Sampling rate||Accuracy||Number of data|
|Smart phones||GPS/Wi-Fi positioning||1 point per 1s||100-10m||Over 100 tracks|
B.2 Maritime sector use case
Several devices have been used by vessels to track their positions. Some of these devices are mandatory as required by regional/international standardization initiatives (i.e. EU Directives, IMO conventions, etc …).
The scope to track the position of the vessels is twofold: increase the safety and security within the maritime sector.
In order to address maritime use cases the Moving Feature standard has to include at least the following information: (i) ship position, which can be provided by different data source (AIS, LRIT, etc …); and (ii) ship voyage, which describe the track of vessels. Additional information about the vessel incidents and the ship particulars has to be considered complementary, therefore as possible extensions to the Moving Feature standard. For example the following figure summarize the information collected by the Canonical Data Format produced by the European Maritime Safety Agency
The following picture reports the last position of vessels within a specific area (black triangle), and the track of a specific vessel (yellow triangles). In this case the yellow triangles report the position of a specific vessel every 6 minutes in the last 24 hours. Furthermore additional information as: heading, true heading and speed is recorded for enrich the description of the vessel track.
A vessel has a unique identification at a worldwide scale (IMO number, or MMSI), the position of a vessel (ship position) is a point feature over the time. The voyage feature of a vessel (ship voyage) is characterized by several attributes such as: speed over the ground, course over the ground, heading and true heading.
To build the trajectory of a vessel, two main abstract feature types are relevant for Moving Feature standard: ship position and ship voyage.
Possible uses of the information collected by maritime authorities are:
|Vessels||enter/leave/inside a particular area X||Speed 11 knots in/out a Feature of Interest|
|Vessels||Suspicious manoeuvres||Change the speed rapidly and/or varying|
|Vessels||Discrepancy between declared Next Port or arrival time and current position/course||Current position and voyager declared|
|Vessels||Approaching dangerous Feature Of Interest||Distance from a rocks less than 3 miles|
|Data sources||Localization method||Sampling rate||Accuracy||Number of data|
|Automatic Identification System (AIS) / Satellite AIS||GPS/Wi-Fi positioning||1 point every 6 minutes||100-10m||Over 10 tracks per hour|
B.3 Aviation sector use case
Aircraft and other airborne vehicles are obviously moving features as well. The aviation sector has a (large) number of methods to track aircraft and to represent their position.
The main sources of data include the following
- Primary surveillance radar: Radar equipment measuring position and heading of aircraft.
- Secondary surveillance radar: position detection is augmented with an active response from the aircraft’s transponder. It supplies additional information such as its identity.
- ADS-B: aircraft with on board GPS or other GNSS equipment may also provide position information based on the GPS measurement. This mode of position and information broadcasting is called ADS-B and is seen as an important future tool for increasing air traffic capacity and safety.
The position and related data of aircraft is encoded according to different standards. One standard is Eurocontrol ASTERIX (http://www.eurocontrol.int/asterix). ASTERIX defines different categories, most categories containing position data according to a different detection method.
For instance, category 48 defines the following fields (copied from the Cat 48 specification on http://www.eurocontrol.int/services/specifications-documents )
|Data Item||Description||Description System Units|
|I048/010||Data Source Identifier||N.A.|
|I048/020||Target Report Descriptor||N.A.|
|I048/040||Measured Position in Slant Polar Co-ordinates||RHO: 1/256 NM, THETA: 360°/(2 16)|
|I048/042||Calculated Position in Cartesian Co-ordinates||X, Y: 1/128 NM|
|I048/050||Mode-2 Code in Octal Representation||N.A.|
|I048/055||Mode-1 Code in Octal Representation||N.A.|
|I048/060||Mode-2 Code Confidence Indicator||N.A.|
|I048/065||Mode 1 Code Confidence Indicator||N.A.|
|I048/070||Mode-3/A Code in Octal Representation||N.A.|
|I048/080||Mode-3/A Code Confidence Indicator||N.A.|
|I048/090||Flight Level in Binary Representation||1/4 FL|
|I048/100||Mode-C Code and Confidence Indicator||N.A.|
|I048/110||Height Measured by a 3D Radar||25 ft|
|I048/120||Radial Doppler Speed||(2-14) NM/s|
|I048/130||Radar Plot Characteristics||N.A.|
|I048/140||Time of Day||1/128 s|
|I048/200||Calculated Track Velocity in Polar Representation||Speed: (2-14) NM/s, Heading:360°/(2 16)|
|I048/230||Communications / ACAS Capability and Flight Status||N.A.|
|I048/250||Mode S MB Data||N.A.|
|I048/260||ACAS Resolution Advisory Report||N.A.|
The items in bold relate to the position, heading, time, and identity of the aircraft. Other information fields provide metadata on quality, data source, etc.
Other ASTERIX categories provide different sets of information where position and other information may also be encoded in different ways. Some interesting aspects to ASTERIX:
- The positions may be expressed in relation to the radar equipment position. A (separately available) position of the radar is thus needed to correctly geo-reference the aircraft.
- The data has a binary encoding optimized to obtain a small message size. Verbose GML/XML encoding may be a barrier for adoption of the Moving Feature standard for large data sets in the aviation world.
- Many data sets do not include all fields. Optional elements in the Moving Features may accommodate representing such data sets.
- Some categories or data sets do not include an identification of the moving features. Such data is often referred to as ‘plots’. Since multiple plots cannot be related to a single aircraft, the data set basically is a bag of time-stamped points.
FAA has an Aircraft Situation Display to Industry (ASDI) feed, which provides aircraft position reports as a convenient data feed to industry. The feed also includes information on flight plans (the planned route of the aircraft). See http://www.fly.faa.gov/ASDI/asdi.html for more information.
In order to address aviation use cases at least this information must be managed in the moving feature standards. Other information is important as well and may be encoded as use-case specific metadata.
Possible uses of the information collected by aviation authorities are:
|Aircraft||Performing a flight||Speed: 300-1000km/h||Many|
|Aircraft||Taxiing on a airport||Speed: 0-300km/h||Many|
|Data sources||Localization method||Sampling rate||Accuracy||Number of data|
|Primary/Secondary Surv. Radar||Radar detection||1 to several seconds per position||Depends on radar & distance to radar||Thousands of concurrent flights world-wide|
|ADS-B||GNSS/GPS||1 to several seconds per position||100-10m||Thousands of concurrent flights world-wide|
Use cases can also involve analysis afterwards (incident analysis, statistics, etc.) or simulated air traffic. The moving features standard may be useful to convert raw feeds into a standard moving features representation for use in generic analysis and processing tools.
B.4 A Use case for Hurricanes
Tropical storms, hurricanes and typhoons are extremely energetic and dangerous weather phenomena with a pronounced centre of rotation, the ‘eye’. However, their position can be forecast, with increasing accuracy, several days in advance, and even more accurately only a day in advance. These forecasts are normally presented to the general public and emergency services as a simple graphical map, often using PNG or JPEG formats.
Hurricanes and typhoons are the same phenomenon, but traditionally the names in the western Pacific and western Atlantic are different. A tropical storm is a weaker version, causing less damage, but can become more energetic. Currently a wind speed threshold of 65 knots (120Km/hour, 75 miles/hour) is the only distinguishing attribute.
Typically a deterministic chart will show a single forecast storm trajectory as a single track with the location of the storm centre or ‘eye’ indicated at regular intervals, say every 6 or 12 hours. The location at a specific time is usually marked by specific symbols, standardised across all countries for both meteorology and aviation.
Sometimes a probabilistic chart is preferred, and a range of possible trajectories, or an envelope of these trajectories is used. The set of trajectories may come from a single forecast centre using an ensemble of possible forecasts, or the set may be from several forecast centres which all produce slightly different forecasts. Generally, if the spatial, and temporal, spread of the set of trajectories is small, then more confidence is attached to them than if the spread is great.
Expert users, such as forecasters, may also use a chart that displays ranges of trajectories from successive forecast times, and the actual trajectory so far. Again, similarity in these successive forecasts gives increased confidence in the accuracy of the forecasts.
If graphical output is inappropriate, there is a standardised simple text message used to transmit the current and forecast locations across emergency communications channels. These messages also include the actual and forecast wind speeds at various distances and directions from the ‘eye’. The atmospheric pressure near the eye may also be included.
The central pressure is an important indicator of damage, like the wind speed, as the reduced pressure causes the local sea surface to rise by a few metres causing flooding and destructive waves.
The sea surface temperature in the path of the storm is also important, as this determines whether the storm will increase or decrease in strength.
So there are a number of changing attributes need to be associated with the storm and its trajectory.