Time specification for trajectories having a constant time

[pnovotny-ibl]

According to the specification, there are 4 types of trajectories. The first type is as follows:

A 2D trajectory, on the surface of earth, at the same time: coords=LINESTRING(51.14 -2.98, 51.36 -2.87, 51.03 -3.15, 50.74 -3.48, 50.9 -3.36)

The third type is as follows:

A 3D trajectory, through a 3D volume with height or depth, for the same time: coords=LINESTRINGZ(51.14 -2.98 0.1, 51.36 -2.87 0.2, 51.03 -3.15 0.3, 50.74 -3.48 0.4, 50.9 -3.36 0.5)

I wonder how the time is specified in these cases. @m-burgoyne Perhaps, there should be an extra time parameter to be used for this purpose? Note that the same question is related the /trajectory as well as to the /corridor data query.

[m-burgoyne]

@pavol-novotny To specify time LINESTRINGZM would be used, where the M value would be time in epoc seconds i.e. coords=LINESTRINGZM(51.14 -2.98 0.1 1560507000,51.36 -2.87 0.2 1560507600, 51.03 -3.15 0.3 1560508200, 50.74 -3.48 0.4 1560508500, 50.9 -3.36 0.5 1560510240).

If a trajectory or corridor has no height requirement LINESTRINGM would be used i.e. coords=LINESTRINGM(51.14 -2.98 1560507000,51.36 -2.87 1560507600, 51.03 -3.15 1560508200, 50.74 -3.48 1560508500, 50.9 -3.36 1560510240)

[pnovotny-ibl]

@m-burgoyne According to the specification, usage of LINESTRINGZM and LINESTRINGM is reserved for cases when the trajectory runs over a time range. I am asking about cases when the trajectory is for a constant time, i.e. defined by LINESTRING or LINESTRINGZ. How is this constant time specified in the query?

[m-burgoyne]

@pavol-novotny I suspect the specification specifies that for efficiency (i.e. to avoid repetition of the same value), I would rather that there were not two approaches to defining the same input parameter, although putting the same time value in for each point would make the input longer it will simplify the API description and the same applies to Z values.

[chris-little]

@pavol-novotny @m-burgoyne So, to summarise the different approaches:

1. A 2D trajectory, on the surface of earth, at the same time:
   PN approach: LINESTRING(51.14 -2.98, 51.36 -2.87, 51.03 -3.15, 50.74 -3.48, 50.9 -3.36) +time. Easiest for user to construct, but not the same pattern for software, needs a time spec.
   MB approach: LINESTRINGM(51.14 -2.98 1560507000,51.36 -2.87 1560507000, 51.03 -3.15 1560507000, 50.74 -3.48 1560507000, 50.9 -3.36 1560507000). User has to repeat time for every coordinate, simpler consistent implementation but may miss optimisation opportunity.

2. A 2D trajectory, on the surface of earth, with changing times:
   PN&MB agree: LINESTRINGM(51.14 -2.98 1560507000,51.36 -2.87 1560507600, 51.03 -3.15 1560508200, 50.74 -3.48 1560508500, 50.9 -3.36 1560510240)

3. A 3D trajectory, through a 3D volume with height or depth, for the same time:
   PN approach: LINESTRINGZ(51.14 -2.98 0.1, 51.36 -2.87 0.2, 51.03 -3.15 0.3, 50.74 -3.48 0.4, 50.9 -3.36 0.5) +time. Easiest for user to construct, but not the same pattern for software., needs a time spec.
   MB approach: LINESTRINGZM(51.14 -2.98 0.1 1560507000,51.36 -2.87 0.2 1560507000 51.03 -3.15 0.3 11560507000, 50.74 -3.48 0.4 1560507000, 50.9 -3.36 0.5 11560507000). User has to repeat time for every coordinate, simpler consistent implementation, but may miss optimisation opportunity.

4. A 3D trajectory, through a 3D volume with height or depth, with changing times:
   PN&MB agree: LINESTRINGZM(51.14 -2.98 0.1 1560507000,51.36 -2.87 0.2 1560507600, 51.03 -3.15 0.3 1560508200, 50.74 -3.48 0.4 1560508500, 50.9 -3.36 0.5 1560510240).

[pnovotny-ibl]

Summary from the today's EDR API SWG teleconference:

Additional optional parameters time and z will be added to the /trajectory and /corridor data queries. Use cases:

1. A 2D trajectory at the same time: coords=LINESTRING(...) + time=... + z=...
2. A 2D trajectory with changing times: coords=LINESTRINGM(...) + z=...
3. A 3D trajectory at the same time: coords=LINESTRINGZ(...) + time=...
4. A 3D trajectory with changing times: coords=LINESTRINGZM(...)

If usage of the time or z parameters conflicts with the type of the trajectory (e.g. coords=LINESTRINGZM(...) + time=...), then the server will return an error.