[postgis-devel] Distance operator in presence of M

[Sandro Santilli]

On Thu, Jun 04, 2015 at 09:15:07AM -0400, Greg Troxel wrote:
> 
> Sandro Santilli <strk at keybit.net> writes:
> 
> > As you may have noticed, I'm working on adding some functions to work
> > with "trajectories". These are linestrings in which each point corresponds
> > to the location of an object at a given time. Location uses XYZ, time uses M.
> 
> I hadn't noticed, but I have long been pondering how to represent
> tracklogs from GPS, because eventually I'd like to put all my logs into
> postgis to be able to then have them show up in viking and/or do
> analysis somehow, including geotagging photos.  I haven't said anything
> on the list because I hadn't done my homework, but had been converging
> on a table with an id for the segment, a point, and a time.  Using a
> line seemed unhelpful.  So if there's a new trajectory data type, that
> seems to fit, as I was basically trying to get that from primitives.

There isn't a new data type, it's still a plain old geometry.
Only, there's a "standard way to encode" a trajectory, which you
can check via ST_IsValidTrajectory.

Having a new "trajectory" datatype might be a solution to allow using
trajectory-specific operators.
It'd be like "geography", but then would we need geography_trajectory
and geometry_trajectory?

> > The "closest points" between two trajectories are those in which the two
> > moving objects are spatially closest at the same point in time.
> >
> > The ST_ClosestPointOfApproach function, which I committed in r13569,
> > returns such point in time.
> 
> It seems that someone would want to know the two points as well.

You can get them using ST_LocateAlong against the two geometries.

The internal function does indeed know about those two points, as
it used them to compute the distance, so it wouldn't be too hard to also
return them. What would the return be, then ?
I could think of a LINESTRING with first point from first trajectory
and second point from second trajectory, and same M value in both (so
it won't be a "trajectory" on itself). The existing "ST_ClosestPoint"
function only returns a point on the first operand (for comparison):
http://www.postgis.org/docs/ST_ClosestPoint.html

> I would expect ST_ClosestPointOfApproach to interpolate, so that it
> really finds the closest approach of the object, assuming that it moves
> linearly between observed points.  (This seems difficult to compute if
> the times aren't uniform or matching.)

It does, and for "trajectories" it is indeed assumed that the object moves
linearly (at constant speed) between observed points.

> > Would using the ClosestPointOfApproach semantic, in presence of M,
> > ruin any other valid use case for <<->> ?

> In the case of a trajectory (sequence of (P,t)), I'd argue that
> the natural distance is the delta-P at closest approach.  If one wants
> instead to ask how close the two paths are, ignoring time, that's a
> different question, and could be answered by projecting the trajectory
> to get rid of time, leading to sequence of P, which is probably exactly
> the line object type.

This is exactly what we could obtain by having a separate datatype
for "trajectory". If there isn't a new datatype you're still left to
decide if a LINESTRINGM has to be considered a trajectory or not.

We could decide that operators on XYZM lines always assumes trajectories,
thus my question above, would it be destruptive of other legit use cases ?
The possibility to drop M is always an option (to get back to spatial only
semantic). The question is, would you ever want to keep M and still get
it used in some other way ?

> The next layer of complexity is matching a line segment that's part of a
> path to a larger object that is perhaps larger than the path, or to
> multiple objects.   Basically the question of taking a GPS trace and
> find the roads it corresponds to from a map database.   But that's
> definitely not just a distance metric or operator.

This one sounds purely spatial.

> > While we can encode semantic in the function name for functions, with
> > operators we have a limited expressibility, so if <<->> has to be
> > used for pure euclidean distance we'd need another operator name for
> > the CPA semantic, and, I suppose, another operator class to make use
> > of KNN with that semantic.
> 
> It strikes me that the KNN stuff should be passed in a distance function
> rather than forcing us to define the one true distance function, but
> that may be enthusiasm for object orientation more than is useful.

I don't get you here.

--strk;

  ()   Free GIS & Flash consultant/developer
  /\   http://strk.keybit.net/services.html