In a perfect world API-Moving Features would be an extension of API-Features. However, this may be an unacceptable constraint on the API-Moving Features standard. Is there a balance we can strike between conformance with API-Features and going our own way?

Moving Features are often the result of sensor observations. As we build out the Moving Features API we should also look at SensorThing and Sensor Observation Service for guidance.

It seems odd that an orientations property contains a scales property, as well as an angles property.
Possibly they could be separated into scales and angles directly, each with a second array level?

Is there any mechanism to retrieve the temporal geometry for multiple features in a single API call?

I believe this is an important use case to efficiently stream the position of a large number of rapidly moving objects e.g., a satellite constellation or drone swarms.

At the beginning step of the OGC MovingFeautres API (shortly MF-API) design, we would like to collect as many different use cases as possible to extract the basic resources and necessary functionality of the MF-API.

For examples,

• OGC Moving Features Access (http://docs.opengeospatial.org/is/16-120r3/16-120r3.html)
• Case study of the Uber Movement (https://medium.com/uber-movement).

Dear contributors, please share your knowledge about features or use cases you think are necessary to the MF-API in the below comments.

We create this issue to collect and reflect opinions on the current work to finalize the draft work of OGC-API Moving Features (MF-API) Part 1: Features extension.

This issue is especially about Collection resources.
The contents of this document are mainly based on OpenAPI specifications for MF-API Part 1.
Please feel free to comment if you have any questions, ideas, or problems about this resource.

Would there be any mechanism with which one could request both temporal geometries and properties through the same API calls, like both static geometry and properties are retrieved with OGC API - Features at /items?

The orientations (angles / scales) could be considered a special type of properties already returned with the feature geometry (points).

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.

Clause 3 of the draft version of OGC API - Moving Features - Part 1: Core 1.0.0 currently normatively references OpenAPI 3.1.0, however it is also designed to be an extension of OGC API - Features - Part 1: Core 1.0.1 which references OpenAPI 3.0.3.

For consistency, OGC API - Moving Features - Part 1: Core should also reference OpenAPI 3.0.3.

I am wondering how OGC API - Moving Features can enable streaming the current position of a moving object, as well as its past actual trajectory and predicted future trajectory.
Am I correct in understanding (from the overview page), that the relevant resource would be:

GET /collections/{collectionId}/items/{mFeatureId}/tgeometries

Retrieve the movement data of the single moving feature with id mFeatureId.

Is there a mechanism (e.g., a property) that could be used to distinguish between actual historic temporal geometry/properties, current geometry/properties, and predicted geometry/properties?

As a related use case, consider the following ISS tracking positions (not including orientation, but i this case it is easy to deduct the orientation based on the direction of movement):

{
    "sat": 25544,
    "tRef": 1674280079,
    "orbitData": [
        { "t": 1674280020, "ln": 143.511, "lt": 17.213, "h": 419, "v": 7.662, "s": true },
        { "t": 1674280080, "ln": 145.941, "lt": 20.143, "h": 419, "v": 7.662, "s": true }
    ]
}

(from https://www.astroviewer.net/iss/ws/orbit.php?sat=25544)

We create this issue to collect and reflect opinions on the current work to finalize the draft work of OGC-API Moving Features (MF-API) Part 1: Features extension.

This issue is especially about TemporalPropertyCollection resources.
The contents of this document are mainly based on OpenAPI specifications for MF-API Part 1.
Please feel free to comment if you have any questions, ideas, or problems about this resource.

We create this issue to collect and reflect opinions on the current work to finalize the draft work of OGC-API Moving Features (MF-API) Part 1: Features extension.

This issue is especially about TemporalGeometry resources.
The contents of this document are mainly based on OpenAPI specifications for MF-API Part 1.
Please feel free to comment if you have any questions, ideas, or problems about this resource.

We create this issue to collect and reflect opinions on the current work to finalize the draft work of OGC-API Moving Features (MF-API) Part 1: Features extension.

This issue is especially about MovingFeatures resources.
The contents of this document are mainly based on OpenAPI specifications for MF-API Part 1.
Please feel free to comment if you have any questions, ideas, or problems about this resource.

There is a request from the OAB for clearer use of terminology regarding OGC API Standards.

The detail of the Issue is documented at opengeospatial/ogcapi-common#336

This GitHub Issue may be closed once the relevant edits have been made to relevant OGC API Standards documents.

Could the datetime parameter be supported for the temporal geometry and temporal properties requests?

• GET /collections/{collectionId}/items/{mFeatureId}/tgeometries
• GET /collections/{collectionId}/items/{mFeatureId}/tproperties

This would allow to request these for a time interval of interest.

A related use case would be to request these for only the past or predicted future (related to #25).

I think Enterprise Architect allows the font size to be adjusted. Please consider increasing the font size of the class diagram shown in Figure 1.

Requirement class http://www.opengis.net/spec/ogcapi-movingfeatures-1/1.0/req/movingfeatures is fairly large, and potentially involves data types and functionality that not all implementations will need.

For example, where the OGC API for Moving Features is a facade over an existing system, it may not be desirable to allow anything other than "query" (i.e. GET). The create/replace/update/delete operations are required by the conformance class, but may not be desired (or implementable) on the system.

Even if there is support for making changes, the underlying data model may not be suited to DELETE of a single geometry on the MF.

(I'm still trying to get all of the operations clear, but it looks like support for MF Prism is also required, even though the underlying data might only be easily represented in Trajectory).

Suggest breaking out at least the simple "GET me a moving point" functionality, and ideally each logical block of functionality that can be meaningfully implemented on top of that.

We create this issue to collect and reflect opinions on the current work to finalize the draft work of OGC-API Moving Features (MF-API) Part 1: Features extension.

This issue is especially about Collections resources.
The contents of this document are mainly based on OpenAPI specifications for MF-API Part 1.
Please feel free to comment if you have any questions, ideas, or problems about this resource.

We create this issue to collect and reflect opinions on the current work to finalize the draft work of OGC-API Moving Features (MF-API) Part 1: Features extension.

This issue is especially about TemporalGeometryCollection resources.
The contents of this document are mainly based on OpenAPI specifications for MF-API Part 1.
Please feel free to comment if you have any questions, ideas, or problems about this resource.

This is the checklist for converting the document to metanorma asciidoc. The changes will be made in a feature branch called metanorma, and then merged once all of the steps have been completed.

• Modify index document
• Convert the abstract
• Convert the keywords
• Convert the security considerations
• Convert the submitting organizations
• Convert the submitters list
• Convert body of document
• Convert the bibliography
• Convert the references
• Convert the terms and definitions
• Convert all tables
• Convert all figures
• Convert all requirements classes
• Convert all requirements
• Convert all conformance classes
• Convert all conformance tests
• Check all captions
• Check all cross-references

The basic conceptual model / capabilities seems to overlap between OGC API - Moving Features (overview / draft) and GeoPose:

• MF coordinates / GP position (or parameters latitude / longitude in Advanced encoding)
• MF datetimes / GP validTime (in advanced encoding only? -- see #70)
• MF orientations .angles / GP angles / quaternion

Could a GeoPose sequence possibly be supported as a representation for the OGC API - Moving Features temporal geometries response, providing the position, time and orientation along a sequence (see also opengeospatial/GeoPose#73)?

(also asked in GeoPose: opengeospatial/GeoPose#71)

The base property is oddly named as a reference to a 3D model. Could that be something like model?

However, it is not clear how referencing a 3D model is within scope of this Moving Features API.
Could a separate API or conformance class perhaps add this capability?

The ability to reference 3D models from point geometry is also something being considered for OGC API - 3D GeoVolumes, with a /models/{modelId} end-point, where the content-type can be negotiated using an Accept: header, rather than being available in a single format (OGC API Web Guideline Principle 9).

We create this issue to collect and reflect opinions on the current work to finalize the draft work of OGC-API Moving Features (MF-API) Part 1: Features extension.

This issue is especially about MovingFeature resources.
The contents of this document are mainly based on OpenAPI specifications for MF-API Part 1.
Please feel free to comment if you have any questions, ideas, or problems about this resource.

We create this issue to collect and reflect opinions on the current work to finalize the draft work of OGC-API Moving Features (MF-API) Part 1: Features extension.

This issue is especially about TemporalProperty resources.
The contents of this document are mainly based on OpenAPI specifications for MF-API Part 1.
Please feel free to comment if you have any questions, ideas, or problems about this resource.

This issue provides a forum to evaluate and discuss MobilityDB for potential relevance to this API.