Encourage implementation and get feedback on the proposals for OGC Features and Geometries JSON (JSON-FG)
Should the relationship between OGC API – Routes, OGC API – EDR, and Moving Features be formally documented to ensure a common understanding?
Gobe: was discussed at a high level in the Architecture DWG, but we need more detail
A REM route is a data structure that consists of multiple features in a feature collection. Each segment along the route is a feature with attribute information derived from the underlying transportation network(s). Segments may have many intermediate positions. Time is often not important and will typically be rough estimates only. There is no need or option for temporal information on intermediate positions.
In EDR a trajectory is not a feature, it is simply a 2d/3d/4d line string geometry in space/space-time with no other information.
In MF a trajectory is a single feature with a 3d/4d line string in space-time (height is optional). If there are additional properties, they are provided for each intermediate position along the trajectory or for the whole trajectory.
Scott: route is intended to be followed by a moving feature; route can be used as a query parameter of an EDR request
Chuck: 3 different things here. Route temporal axis is discrete, Moving Features temporal axis is continuous (albeit interoplated by a method between observer spatio-temporal positions)
A sort of hierarchy of things (describes an abstract model):
Routes Trajectory (X,Y, perhaps T, + Features) -> travel plan
Geopose Chain of nested reference frames, we may need nested BBOXes - both CRS Axis Aligned and Object Orientated (well understood from CGI)
Dean Hintz: does geopose trajectory include vectored or rotational velocity, or is that typically determined through interpolation?
Josh Lieberman: Core geopose does not include velocity, but it's a considered extension.
Dean Hintz: does the extension include rotational velocity? JL - has been discussed.
Lance Marrou: if you want dead reckoning parameters, geopose isn't the right protocol. Look at some of the M&S stuff like DIS
Dean Hintz: Is there a way to indicate a gap in a trajectory - if the assumption is a continuous route but there is a gap in the telemetry? Perhaps just by and end tag - start / end of trajectory mark / status?
Dean Hintz: Are the coordinates assumed to be cartesian, geocentric or are arbitrary geographic coordinate systems supported? Perhaps the CRS and datum is defined for each dataset.
If arbitrary CRS are supported for each standard, are each designed to support space and other planetary environments?
Gobe: Chris Kemp (Astra) spoke about getting satellites to avoid debris out in orbit. In UxS, there is also a concept of 'Sense and Avoid'. So there may be a role for representing and exchanging trajectories of airborne or space-borne objects (i.e. a role for the Moving Features standard).
Josh: Three perspectives: 1) 4D "route / trajectory" line, 2) moving feature traversing the line, 3) sequential observations of the feature position +/- persistence along the line.
Josh: REM includes route trajectory, route segments, waypoints as components of the route.
From December 2021 Closing Plenary
Encourage implementation and get feedback on the proposals for OGC Features and Geometries JSON (JSON-FG)
Should the relationship between OGC API – Routes, OGC API – EDR, and Moving Features be formally documented to ensure a common understanding?
Gobe: was discussed at a high level in the Architecture DWG, but we need more detail
Scott: route is intended to be followed by a moving feature; route can be used as a query parameter of an EDR request
Chuck: 3 different things here. Route temporal axis is discrete, Moving Features temporal axis is continuous (albeit interoplated by a method between observer spatio-temporal positions)
A sort of hierarchy of things (describes an abstract model):
Corridor (X,Y,Z,T + Height+Width) <- EDR Trajectory (X,Y,Z,T) -> GeoPose Trajectory (X,Y,Z,T, roll, yaw, pitch) -> Moving features trajectory (X,Y,Z,T, roll, yaw, etc + Geometry)
Routes Trajectory (X,Y, perhaps T, + Features) -> travel plan
Geopose Chain of nested reference frames, we may need nested BBOXes - both CRS Axis Aligned and Object Orientated (well understood from CGI)
Dean Hintz: does geopose trajectory include vectored or rotational velocity, or is that typically determined through interpolation? Josh Lieberman: Core geopose does not include velocity, but it's a considered extension. Dean Hintz: does the extension include rotational velocity? JL - has been discussed. Lance Marrou: if you want dead reckoning parameters, geopose isn't the right protocol. Look at some of the M&S stuff like DIS
Dean Hintz: Is there a way to indicate a gap in a trajectory - if the assumption is a continuous route but there is a gap in the telemetry? Perhaps just by and end tag - start / end of trajectory mark / status?
Dean Hintz: Are the coordinates assumed to be cartesian, geocentric or are arbitrary geographic coordinate systems supported? Perhaps the CRS and datum is defined for each dataset. If arbitrary CRS are supported for each standard, are each designed to support space and other planetary environments?
Gobe: Chris Kemp (Astra) spoke about getting satellites to avoid debris out in orbit. In UxS, there is also a concept of 'Sense and Avoid'. So there may be a role for representing and exchanging trajectories of airborne or space-borne objects (i.e. a role for the Moving Features standard).
Josh: Three perspectives: 1) 4D "route / trajectory" line, 2) moving feature traversing the line, 3) sequential observations of the feature position +/- persistence along the line. Josh: REM includes route trajectory, route segments, waypoints as components of the route.
Ryan: Upcoming OGC Discussion Paper work on the interoperability of magnitude and direction (essentially mathematical vectors) might be relevant for this discussion. Presentation describing the nature of the work is at https://docs.google.com/presentation/d/1DhIhnZmPoMCYi_l6fe3JREHbNoz_YPjB/edit?usp=sharing&ouid=104935094879066637233&rtpof=true&sd=true Josh: Vector interoperability connects to velocity observations of moving objects.
Scott: future (some exsting) routing experiences are Augmented Reality with the need to link reality, routes, moving feature info