Clarify the relationship with OGC API - Connected Systems

[jerstlouis]

https://github.com/opengeospatial/connected-systems/tree/master/api/part1/standard

From @alexrobin :

The API is an extension of OGC API - Features for handling dynamic data and will be presented in detail at the next TC.
The Connected Systems SWG will meet for the first time in Frascati. (4:10 PM on Monday, February 20)

There will also be presentations in the Autonomy, Sensors, Things, Robots and Observations DWG (ASTRO DWG, previously SWE DWG) dealing with spacecraft and UxS telemetry which includes pose information. (10:20 AM on Monday, February 20)

We have been dealing with dynamic pose information for years with the SWE standards (we have worked with spaceborne and UxS use cases all along) and this new API is a modern approach to it. GeoPose now formalizes the pose data model and we'll be able to encode and stream the corresponding data using various encodings (json, xml, binary). In general, Pose is a specific type of observation about a feature so IMHO it should be recognized as such.

[ghobona]

The use cases are very different. OGC API - Connected Systems supports creation, update, and access to:

• systems
• procedures
• deployments
• sampling features
• properties of resources accessed by the API
• datastreams
• observations
• control channels
• commands
• system events
• system history

In contrast, OGC API - Moving Features supports creation, update, and access to:

• moving features that conform to the OGC Moving Features standard
• collections of moving features that conform to the OGC Moving Features standard

[jerstlouis]

@ghobona

Conceptually, I believe that the conform to the OGC Moving Features standard part is only one specific representation of the collection of data. e.g., we have discussed in Testbed 18 and 19 about a potential alternative GeoPose sequence representation that the API could possibly return (negotiating another response), in line with the "multiple possible representations" approach of OGC API standards.

With that in mind, perhaps OGC API - Moving Features overlaps with a (simpler) subset of OGC API - Connected Systems?

If I understand correctly, both could be used for example to keep track of and visualize in a client the positions and orientations of a drone fleet, along with associated properties varying with time.

If that is the case, it would be good if there was some kind of alignment for that subset of functionality, or at least some clear guidance explaining the use case distinction.