[postgis-devel] Distance operator in presence of M

[Greg Troxel]

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.

> 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.

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.)

> Now, when it comes to the <<->> operator, for geometry or geography, we
> have to pick a distance semantic in case of M presence. Right now this
> semantic is just discarding M, compute in 2d or 3d space (whatever is
> available in both operands) and then "add" the M difference to the euclidean
> distance.
>
>  https://trac.osgeo.org/postgis/ticket/3133
>
> But I'm wondering, is current approach any useful ?

I don't see how it makes sense to add distance and time, unless you
scale by c and compute pseudoranges as in GPS :-) But seriously, adding
distance and time assumes a speed, and I don't see where you are going
to get a speed; if you take it from the trajectory that feels bizarre
and likely to lead to triangle inequality violations, and otherwise you
have to assume it somehow.   1 m/s is a sane speed for a wide range of
actual experiences, though, semi-interestingly, althought it's quite off
for tectonic plate motion.

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

That sounds sensible to me, but I had a different thought that may help
resolve this.

Choosing a distance metric really relates to some desire for problem
solving, and people might want different metrics for different purposes
(for complicated data; for simple data it's obvious what distance
means).  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.  So a straw position is that people who want that
can project the trajectory to a line first.

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.

> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 180 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20150604/1ca4a587/attachment.sig>