This OGC® Standard specifies standard encoding representations of movement of geographic features. The primary use case is information exchange.
Ogcdoc, moving features, CSV
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|
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 CSV
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, a comma-separated values (CSV) style encoding for Moving Features is standardized. The defined encoding standard should be ISO 19141:2008 Geographic Information – Schema for moving Features compliant implementation standard applicable for massive data handling.
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).
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.
- [IETF RFC 4180] Y. Shafranovich, “Common Format and MIME Type for Comma-Separated Values (CSV) Files”, IETF RFC 4180, October 2005, available at < http://www.ietf.org/rfc/rfc4180.txt>
- [IETF RFC 3629] F. Yergeau, “UTF-8, a transformation format of ISO 10646”, IETF RFC 3629, November 2003, available at <http://tools.ietf.org/html/rfc3629>
- [IETF RFC 2396] IETF RFC 2396, Uniform Resource Identifiers (URI): Generic Syntax. (August 1998)
- [ISO 19141:2008] ISO 19141:2008, Geographic information – Schema for moving features
- [ISO 19107:2003] ISO 19107:2003, Geographic information – Spatial schema
- [ISO 19123:2005] ISO 19123:2005, Geographic information – Schema for coverage geometry and functions
- [XMLSchema-2] W3C XMLSchema-2, XML Schema Part 2: Datatypes. W3C Recommendation (28 Oct 2004)
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
- 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
The following symbols and abbreviated are used in this standard;
- International Organization for Standardization
- Open Geospatial Consortium
- One Dimensional
- Two Dimensional
- Three Dimensional
- Comma Separated Values
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 OGC® Moving Features Simple Binary Encoding define most 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 pointgeometries.
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. Two squares drawn with broken lines in Fig. 1 correspond to these packages. The square labelled as “<<Prism Geometry>>” is an implementation of “Prism Geometry”; the square labelled as “<<Geometry Types>>” is an implementation of “Geometry Types.”
The data model used by the CSV encoding is equivalent to that used by [Moving Features Core XML]. Figure 2 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.
OGC Moving Features Simple CSV is based on [IETF RFC4180] (Common Format and MIME Type for Comma-Separated Values (CSV) Files) except the meta-information like definition of each column. Basic encoding-rules are listed in Table 1.
Requirement 7.1 (req/simplecsv/csv_valid):
The encoding restrictions of Moving Features Simple CSV are following.
- Any line shall be encoded by UTF-8 with LF or CR+LF as the new line character.
- The separators shall be comma (,).
- Columns shall start and end with double quotations (”) if the column include double quotations (”).
- Any double quotation (”) in a column shall be replaced with two double quotations (””) except the first letter and the final letter of the column.
|#||property title||property setting|
|1||Character encoding||UTF-8 [IETF RFC 3629]|
|2||New line character||either LF or CR+LF|
|3||Separators||comma (, ) [0x2C]|
|4||Columns||Each column starts with a double quotation (“)  and ends with a double quotation. The double quotations can be omitted if the content does not include any double quotation.|
|5||Escape sequence||A double quotation included by the column content must be replaced to two double quotations (“”).|
The meta-information is described by “header lines,” which start with “@”[0x40], shown at the top of the moving features data. “Trajectory lines,” which describe trajectories of the moving features, follow the header lines. The structure is illustrated in Figure 3. Several header lines are shown at first. Following the header lines, trajectory lines are written.
Requirement 7.2 (req/simplecsv/overall_structure):
Header lines shall be shown before Trajectory lines.
Some types of columns defined by the Moving Features Simple CSV Encoding are omissible. The omitted column is written as an empty column, for example,
@stboundedby,urn:x-ogc:def:crs:EPSG:6.6:4326,2D,50.23 9.23,50.31 9.27,2012-01-17T12:33:41Z,2012-01-17T12:37:00Z,,
The last column of the above line is omitted. The omitted column is interpreted as the default value.
@[metadata name],[value 1], [value 2]...
A header line contains a metadata-name-column and several value-columns. The metadata-name-column, which starts with “@”, specifies type of the meta-information which this line defines. The value-columns set values of the meta-information. For example, if “@stboundedby” is shown, the line defines the spatio-temporal bounding-box of the moving features. The value-columns following “@stboundedby” explicit the geometry of the spatial bounding-box and the time period of the moving features.
Requirement 8.1 (req/simplecsv/headerline):
Any header lines shall start with “@”.
@stboundedby,[srid],[dim],[upper_left],[lower_right],[start time],[end time],[time encode]
The @stboundedby line determines the spatio-temporal boundary of moving features. This line is equivalent to mf:STBoundedBy defined by [OGC Moving Features Core].
Requirement 8.2 (req/simplecsv/stboundedby):
One “@stboundedby” line consistent with the trajectory lines shall be included by the header lines.
The spatial reference system used in the moving feature is specified.
This column specifies the dimension of geometries.
- “2D”(default): 2D data are included
- “3D”: 3D data are included
The upper-left corner of the spatial boundary is stated here. x-coordinate and y-coordinate are sequentially written with a separator “ “(white-space).
The lower-right corner of the spatial boundary is stated here. x-coordinate and y-coordinate are sequentially written with a separator “ “(white-space).
The time before starting of all movements is written in xsd:dateTime style.
The time after ending of all movements is written in xsd:dateTime style
time encode (omissible)
The column shows the unit of time used in the Trajectory lines. “start time” and “end time” are described the offset from the “start time” specified by the @stboundedby line.
- “sec”(default): the offset described in seconds is encoded in xsd:decimal style.
- “minute”: the offset described in minutes is encoded in xsd:decimal style.
- “absolute”: an absolute date time is encoded by xsd:dateTime style.
@columns,”mfidref”,”trajectory”,[VaryingAttrDef(1) Name], [VaryingAttrDef(1) Type],…, [VaryingAttrDef(n) Name], [VaryingAttrDef(n) Type]
Requirement 8.3 (req/simplecsv/column):
Only one “@columns” line shall be included by the header lines.
“mfidref”, which is the first row of each datum, is used in order to identify the moving feature. Thus the first column of the header is always fixed as “mfidref”.
The second column defines the spatio-temporal geometry of moving features.
The column which defines an attribute used in the foliation is equivalent to mf:VaryingAttrDef [Moving Features Core]. If the moving features do not have any variable attributes, these columns can be omitted.
A pair of the “VaryingAttrDef(n) Name” column and “VaryingAttrDef(n) Type” column defines one varying attribute. “VaryingAttrDef(n) Name” defines the name of the attribute with a xsd:token style text. The “VaryingAttrDef(n) Type” column following the “VaryingAttrDef(n) Name”, which the XSD data type (defined in [XMLSchema-2] as built-in data types)is used to specify, defines the type of the attribute value. The supported data types used in Moving Features Encoding Simple CSV are listed in the following table.
|#||XSD data type|
Multiple VaryingAttrDef column-pairs can be included by the @columns line in order to define multiple attributes.
A @foliation line defines properties of the foliation described in the CSV data. The @foliation line is omissible if all values are set default values.
Order column defines appearing order of trajectories. The possible values are enumerated in the following code table.
|Time||mf:Trajectory elements ordered by time strictly||Yes|
|Sequential||mf:Trajectory elements which are parts of one track are ordered by time|
Trajectory lines (Data body)
[mfidref],[start time], [end time],[points of linestring],[attr]
Trajectory lines contain the spatio-temporal geometries for moving features. The data model of the trajectory lines is equivalent to that of mf:LinearTrajectory defined in [Moving Features Core XML]. mf:LinearTrajectory element is the spatio-temporal line-string, which is similar to gml:LineString. The mf:LinearTrack is a special trajectory that consists of a single segment with linear interpolation.
Requirement 9.1 (req/simplecsv/trajectoryline):
The trajectory lines shall statisfy the following restrictions.
- The number of columns and the datatype of the columns are consistent with the definition in the header line part.
- The order of the trajectory lines is consistent with the restriction stated by the @foliation line in the header line part.
- Any pair of trajectory lines having common ‘mfid’ satisfies the following condition: start time of one trajectory line is later than or equal to end time of another trajectory line otherwise end time of one trajectory line is earlier than or equal to start time of another trajectory line.
The texts specifying the moving feature (i.e. person ID, vehicle ID, etc.)
The column specifies the start time of the movement. The encoding style is determined in the @stboundedby line.
The column specifies the end time of the movement. The encoding style is determined in the @stboundedby line.
points of linestring
The positions of the trajectory are specified. The x-coordinate value (or longitude), the y-coordinate value (or latitude) and the z-coordinate value (or elevation) are separated by whitespace characters. A separator between points is similarly a whitespace. If SRS specifies the 2D space, the following encoding style is applied.
[x-coordinate (1)] [y-coordinate (1)] [x-coordinate (2)] [y-coordinate (2)] …
Otherwise, if SRS specifies 3D space, the following encoding style is applied.
[x-coordinate (1)] [y-coordinate (1)] [z-coordinate (1)] [x-coordinate (2)] [y-coordinate (2)] [z-coordinate (2)]…
Attr consists of multiple columns which describe the attribute values. An example is 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.
Example 1: people movements
@stboundedby,urn:x-ogc:def:crs:EPSG:6.6:4326,2D,50.23 9.23,50.31 9.27,2012-01-17T12:33:41Z,2012-01-17T12:37:00Z,sec @columns,mfidref,trajectory,state,xsd:token,”type code”,xsd:integer a,10,150,11.0 2.0 12.0 3.0,walking,1 b,10,190,10.0 2.0 11.0 3.0,walking,2 a,150,190,12.0 3.0 10.0 3.0,walking,2 c,10,190,12.0 1.0 10.0 2.0 11.0 3.0,vechicle,1
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 CSV Validity|
|Test Purpose||Verify that any line of the document is well-formed as CSV .|
|Test Method||Validate the document conformant with IETF RFC4180.|
|A.1.2 Overall structure|
|Test Purpose||Verify that the document consists of header lines and trajectory lines .|
|Test Method||Validate the document has two part. The first part consists of header lines which start with “@” and the second part consists of trajectory lines which do not start with “@”.|
|A.1.3 Spatio-temporal boundary|
|Test Purpose||Verify the spatio-temporal boundary is defined.|
|Test Method||Validate that a line starting with @stboundedby is included in the headerlines.|
|A.1.4 Column definition|
|Test Purpose||Verify the spatio-temporal boundary is defined.|
|Test Method||Validate that a line starting with @columns is included in the headerlines.|
|A.1.5 Trajectory definition|
|Test Purpose||Verify that all trajectory lines are valid and consistent with attribute definition at the header line part. In addition, verify the uniqueness of “mfid” at a temporal snapshot.|
Validate that the following conditions are satisfied.
|2014/11/13||OGC 14-084r2||Akinori Asahara||3||W3C XMLSchema-2 was added|
|2014/11/13||OGC 14-084r2||Akinori Asahara||220.127.116.11||A reference to xsd data types were added|