Moving Features

This page discusses work under investigation for the Moving Features working group. This group publishes specifications built on top of ISO 19141:2008 — Schema for moving features. Existing publications are:

• OGC^® Moving Features Encoding Part I: XML Core v1.0 (14-083r2)
• OGC^® Moving Features Encoding Extension: Simple Comma Separated Values (CSV) v1.0 (14-084r2)
• OGC^® Moving Features Encoding Extension - JSON v1.0 (16-140r1)
• OGC^® Moving Features Access v1.0 (16-120r3)
• OGC^® Moving Features Encoding Extension: netCDF (16-114r3)

Review of specifications used as abstract model

Moving Features encoding specifications (XML, CSV, JSON, netCDF) and the Moving Feature Access specification can been seen as implementations of a conceptual model defined by the following ISO specifications:

• ISO 19107:2003 – Spatial schema
  This standard defines geometric objects. Example: GM_Curve.
• ISO 19125:2004 – Simple feature access
  This standard uses a subset of ISO 19107:2003 geometric objects and discusses their relationship with features. The geometric objects are defined with an UML, but no UML is provided for the feature concept.
• ISO 19141:2008 – Schema for moving features
  This standard defines trajectory, prism, foliation, leaf, etc. It extends ISO 19107 geometric objects, for example MF_Trajectory extends GM_Curve. UML are provided for those geometric extensions, but still no UML are provided for features. However the discussion explain that since MF_Trajectory is a special kind of GM_Curve, the discussion in ISO 19125 about the relationship between geometries and features still apply.
• ISO 19109:2015 – Rules for application schema
  This standard defines FeatureType and related objects (PropertyType, AttributeType, etc.) with a UML schema. The UML provided in this standards are the basis for Java interfaces proposed in GeoAPI 3.1. However this standard does not said anything about moving features.
• ISO 19125:(in progress) – Features and geometries
  The draft standard contains UML for features, apparently as a subset of ISO 19109:2015.

The following UML is extracted from ISO 19141. It shows how some Moving Features classes (prefixed by MF_) extends spatial geometries classes (prefixed by GM_). Note also that the Moving Features specifications use multi-inheritance. For example MF_Trajectory extends both GM_Curve and MF_OneParamGeometry.

The following UML is extracted from ISO 19109. It shows FeatureType and its components (AttributeType, etc.). It shows (among other) that a FeatureType contains an arbitrary amount of PropertyType, which are often (but not necessarily) AttributeType (other kind of properties can be associations to other features, and operations computing values on-the-fly). An AttributeType can be seen as a key-value pair. This UML does not show explicitly the relationship with geometric objects (GM_Curve, MF_Trajectory, etc.), but the specification said that geometries can be specified in attributes like any other kind of values.

The model implemented by XML, CSV, JSON and netCDF encoding specifications focus on a subset of the conceptual model defined by ISO. For example the CSV encoding stores trajectories as sequences of line segments defined at each time step. The netCDF encoding further restricts the trajectory to a single line segment per time step. Because of this focus, those encoding specifications do not need all the complexity of ISO 19107, 19109 and 19141 conceptual models.

Possible future work: defining an API from abstract model

API defined in an object-oriented programming language (Java, C/C++, etc.) do not need to restrict itself to trajectories for instance. Those API have the flexibility to represent a model closer to the original ISO specifications, allowing the use of complex geometric objects like solids. In order to define a programmatic API for moving features, we need to:

1. Derives an API from ISO 19107 or 19125 (preferably the revision which is under way) for geometric objects.
2. Derives an API from ISO 19141 for trajectories and other extension of spatial geometric objects.
3. Derives an API from ISO 19109 for features (the general concept of features, not the geometric objects).
4. Resolve the following open questions:
   1. How to represent ISO 19141 trajectories into ISO 19109 features? Probably answer is that we do not need to do anything special, since MF_Trajectory is a specialization of GM_Curve and ISO 19109 already has a discussion about the relationship between features and GM_Object.
   2. How to represent dynamic attributes into ISO 19109 features? We are not aware of something specifically for that in ISO specifications. The Moving Features core specification (XML encoding) defines a <VaryingAttrDefs> element, while MF-JSON encoding defines a "temporalProperties" element.
5. Once we have an API for representing features geometries and attributes, complete the features API with methods from Moving Features Access specification.

For encoding dynamic properties in an ISO 19109 features, one possible approach would be to define a new type - DynamicAttributeType - as a sub-type of AttributeType. This would be an extension to ISO models done by the Moving Features working group. Another, more conservative, approach would be to keep the current ISO model unchanged, and instead use the AttributeOfAttribute association defined by ISO 19109 (see above UML, lower left corner). It would be possible for example to attach a "datetimes" characteristic on any attribute. This would be similar to the approach currently done in MF-JSON encoding.

An API in Java derived from ISO 19109 is proposed for GeoAPI 3.1. This API does not yet address the Moving Features needs, unless the group chooses the "datetimes" characteristic approach. Geometric objects derived from ISO 19107, and trajectory objects derived from ISO 19141, still need to be done. Defining an equivalent API in Python is planed but not yet started.

Relationship with Moving Feature Access API

The Moving Feature Access API (OGC 16-120) defines an API for performing action like disjoint, intersects, distance within, nearest approach and more. Many of those operations are also defined in ISO 19141. Moving Feature Access can probably be implemented now using a RESTful API because data would be sent and received in a format described by one of existings standards (XML, CSV or JSON encoding). However an API in an object-oriented programming language do not transfer data as XML, CSV or JSON files (except in import/export operations), but rather as data structures that need to be defined. Those data structures and API are target for GeoAPI, but before to reach this point we need to complete:

1. An API for describing geometric objects derived from ISO 19107. A proposal existed years ago, but will need review for alignment with ongoing ISO 19107 revision.
2. Extending above geometry API with trajectory objects as described in ISO 19141.
3. An API for describing "static" features derived from ISO 19109 or other relevant standard. A proposal is available in GeoAPI master code repository.
4. Verifies that above "static" features can also describe moving features, for example by the use of trajectories as geometric objects.
5. Then, we can provide Moving Feature Access API.

-- MartinDesruisseaux - 1 Sep 2017