The basic conceptual model / capabilities seems to overlap between OGC API - Moving Features (overview / draft) and GeoPose:
GET /collections/{collectionId}/items/{mFeatureId}/tgeometriesRetrieve the movement data of the single moving feature with id mFeatureId.
MF coordinates / GP position (or parameterslatitude / 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? (related to #73 )
A related question:
Since OGC API - Moving Features is an extension of OGC API - Features where GeoJSON is the widely supported representation, I think there would be an expectation that OGC API - Moving Features focuses on that representation.
What would be the advantage(s) or use case(s) for OGC API - Moving Features to also support a GeoPose encoding representation?
The basic conceptual model / capabilities seems to overlap between OGC API - Moving Features (overview / draft) and GeoPose:
GET /collections/{collectionId}/items/{mFeatureId}/tgeometriesRetrieve the movement data of the single moving feature with id mFeatureId.coordinates/ GPposition(orparameterslatitude / longitude in Advanced encoding)datetimes/ GPvalidTime(in advanced encoding only? -- see #70)orientations .angles/ GPangles/quaternionCould a GeoPose sequence possibly be supported as a representation for the OGC API - Moving Features temporal geometries response? (related to #73 )
A related question:
Since OGC API - Moving Features is an extension of OGC API - Features where GeoJSON is the widely supported representation, I think there would be an expectation that OGC API - Moving Features focuses on that representation.
What would be the advantage(s) or use case(s) for OGC API - Moving Features to also support a GeoPose encoding representation?